Summary:
In the top js errors there are 2 mids related to segment fetching:
- requireForFacebook.js:unknownModuleError (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/ba11461526aff8a6842401b35b02f5a4), 11.64 K vs. 524
- asyncRequire.js:verifySegment (https://www.internalfb.com/logview/details/facebook_android_javascripterrors/5452ba893b8d9ba8e97e070cf6976b65) 5.39 K vs. 180
Both errors will result in surface not loading.
A lot of traces have logs similar with the following:
```11-01 19:57:51.166 27735 7626 W fb4a.BridgelessReact: registerSegment(segmentId = "1090", path = "/data/data/com.facebook.katana/app_overtheair/resources/412137089/414433453/hbc-seg-1090__DELIM__main.jsbundle")
11-01 19:57:51.167 27735 7445 I ReactNativeJS: Module 39122 in segment 0 doesn not exist moduleDefiner
11-01 19:57:51.171 27735 7445 E ReactNativeJS: Error: Requiring unknown module "39122"., js build: 414433453
11-01 19:57:51.175 27735 7445 E ReactNativeJS: Error: Segment meta module is not setup properly. Details: segmentId = 1090, metaModule === undefined
11-01 19:57:51.175 27735 7445 E ReactNativeJS:
11-01 19:57:51.175 27735 7445 E ReactNativeJS: This error is located at:
```
RegisterSegment lives through 3 threads while in bridge there are only 2 threads involved (native & JS):
- Native thread, log printed (fb4a.BridgelessReact: registerSegment...)
- Background thread: no log, added in this diff (Finish registerSegment...)
- JS thread: logs not printed, should print logs here:
https://www.internalfb.com/code/fbsource/[60521987354ed1ef9a0d10bafc60db3c25302ab4]/xplat/ReactNative/venice/ReactInstance.cpp?lines=308-330
Since the JS thread logs aren't printed and there are segment errors right after calling registerSegemnt, I think registerSegment is not done. It could be caused by:
- ReactInstance being null, I added logs in background thread to verify (Finish registerSegment...) since dispatching to background thread relies on non-nullable ReactInstance.
- Work on JS thread hasn't been executed when trying to use/verify the segment. I added atomic method ```registerSegmentAtomic``` to make sure JS thread is blocked until segment is fully registered.
```registerSegmentAtomic``` will be tested behind gating added in D40917444.
Changelog:
[Android][Changed] - Add feature flag enableAtomicRegisterSegment
Reviewed By: RSNara
Differential Revision: D40921759
fbshipit-source-id: 84221aa81f0c549f931a4847b154187299639ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35181
As the title says, this unblocks `test_buck` by removign the lambdas used inside test.
Changelog:
[Internal] [Changed] - Fix test_buck by not using lambdas inside ReactImagePropertyTest
Reviewed By: cipolleschi
Differential Revision: D40958412
fbshipit-source-id: 60b8609a25985230dfd6c4dcdf983dc2a8cfaf64
Summary:
Saw in the logs an ever increasing number of warnings coming from WebSocketModule about requesting an instance that has already gone away.
On module invalidation we should close all outstanding websockets, as they will no longer be able to send events to JS.
Changelog: [Android][Fixed] On instance destroy, websockets are correctly closed
Reviewed By: mdvacca
Differential Revision: D40897255
fbshipit-source-id: 1578de8baa342479d14ee1070c3314d45c7fbd8d
Summary:
Changelog: [Internal]
Override logic for determining whether a dispatched `Event` triggers a native `EventAnimationDriver`.
Natively driven AnimatedEvents on bubbling events is not supported. `PointerEvents` requires this and this diff adds custom matching logic such that if a parent specifies an `AnimatedEvent` on `onPointerMove` and a child view dispatches it, the `AnimatedEvent` will still fire.
Reviewed By: javache
Differential Revision: D38722563
fbshipit-source-id: 7cde57eaff9584b33c6ab15f1fe85c0a9bac132e
Summary:
Changelog: [Internal] - Refactor match logic on determining whether to run an EventAnimationDriver (drivers for natively animated events) for an Event dispatched.
Previously, drivers were stored by key on the NativeAnimatedNodesManager (based on event handler and viewTag) and has been refactored to be stored in a list for easier matching.
This diff changes it so the match logic for running an EventAnimationDriver happens on the Event instance. This change is motivated by PointerEvents needing custom match logic (done on a following change).
Reviewed By: javache
Differential Revision: D40691002
fbshipit-source-id: e4f6742a2af3b751214aefa1fc069f65e8e71d77
Summary:
This is a follow up action item from S295231 and T136039462 where we want to make sure null uri in image source is handled properly. This diff adds an unit test to make sure we are using transparent image when uri is null.
Changelog:
[Android][Internal] - Add unit test to ImageView for null uri in source
Reviewed By: javache
Differential Revision: D40732791
fbshipit-source-id: fd468bfe7c33a4f3f8913ead3e84a1770d7c907f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35115
When looking at the new entry point I've realized we have the dynamicLibraryName as first parameter.
As this API is not released yet, let's move it as last.
So users on Java can easily call DefaultNewArchitectureEntryPoint.load(true, true, true)
while now they will have to call DefaultNewArchitectureEntryPoint.load("...", true, true, true)
Users in Kotlin won't be affected by this.
Changelog:
[Internal] [Changed] - Sort parameters in DefaultNewArchitectureEntryPoint
Reviewed By: cipolleschi
Differential Revision: D40793370
fbshipit-source-id: 9dc1569d76a1479a738f8e0f41a4183d7c04538f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35095
This change will make sure that we load the correct JS engine at runtime,
by using the BuildConfig flag that RNGP sets for us.
This will solve a lot of noise in adb logcat for users seeing
stacktraces mentioning failing to load `jscexecutor` library.
This is also a breaking change, but as the API was not widely used nor
advertised in the template, we should be fine by just mentioning this in the release notes.
Changelog:
[Android] [Changed] - Update the template to load the correct JS engine at runtime
Reviewed By: cipolleschi
Differential Revision: D40710597
fbshipit-source-id: d59a7a52b22a9bf273ea89094c6620c3ecf6eb00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35091
This diff refines the DefaultNewArchitectureEntryPoint to make it easier for user to
either turn on Fabric, TurboModules or both.
Changelog:
[Internal] [Changed] - Make it easier for user to toggle only Fabric or TurboModules in New Architecture
Reviewed By: cipolleschi
Differential Revision: D40710596
fbshipit-source-id: 236060b2ebccb1bf25e7f5c0fc15f54c5ce5f608
Summary:
* Add a DevToolsSettingsManager, which has android and iOS variants, which uses a new TM (Android) or takes advantage of the Settings TM (iOS) to get/set console patch settings
* This is backed by either the existing Settings module (iOS) or a new Java TM, which uses the SharedPreferences AP
## Testing
Manual testing
## Changelog
[General] [Added] - Add DevToolsSettingsManager
Pull Request resolved: https://github.com/facebook/react-native/pull/34964
Test Plan: * Extensive manual testing
Reviewed By: NickGerleman
Differential Revision: D40333083
Pulled By: rbalicki2
fbshipit-source-id: f3816e3bd7dea3086f6f2269c3a099af14aebb3b
Summary:
This PR adds React native binding for https://github.com/facebook/yoga/pull/1116
## Changelog
[General] [Added] - Flex gap yoga bindings
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/34974
Test Plan:
Run rn tester app and go to view example. You'll find a flex gap example. Example location - `packages/rn-tester/js/examples/View/ViewExample.js`
### Tested on
- [x] iOS Fabric
- [x] iOS non-fabric
- [x] Android Fabric
- [x] Android non-fabric
To test on non-fabric Android, I just switched these booleans. Let me know if there's anything else I might have missed.
<img width="674" alt="Screenshot 2022-10-14 at 3 30 48 AM" src="https://user-images.githubusercontent.com/23293248/195718971-7aee4e7e-dbf0-4452-9d47-7925919c61dc.png">
Reviewed By: mdvacca
Differential Revision: D40527474
Pulled By: NickGerleman
fbshipit-source-id: 81c2c97c76f58fad3bb40fb378aaf8b6ebd30d63
Summary:
checking for background == null to fix this error:
```java.lang.NullPointerException: Attempt to invoke virtual method 'android.graphics.drawable.Drawable$ConstantState android.graphics.drawable.Drawable.getConstantState()' on a null object reference
at com.facebook.react.views.textinput.ReactTextInputManager.setUnderlineColor(:4)
```
Changelog:
[Internal][Fixed] - check for null background in Android TextInput setUnderlineColor
Reviewed By: beatthat
Differential Revision: D40451369
fbshipit-source-id: 8618d5ff73f517f714c26a0b17af078493822244
Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This diff refactors the initialization of MapBuffer so
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348981
fbshipit-source-id: 88bbf4f2370373c20f805c3b23d0ecbe8a26bb86
Summary:
We found this feature crashing the app during hot reload, and as there is no user code dependent on it so far, we decided to disable it until we find the root cause.
changelog: [internal] internal
Reviewed By: mdvacca
Differential Revision: D40445312
fbshipit-source-id: fe28b58c5dca6c91389ad38675ca37669a4965a0
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34869
Changelog: [Internal]
This merges all instances of `enablePropIteratorSetter` into a single one.
Both `AccesibilityProps` and `BaseTextProps` had their own instances if it, which is now redundant.
Reviewed By: cipolleschi
Differential Revision: D40062555
fbshipit-source-id: b6ccf5a9538612dd731a6f9c4eaceeebcb6d95be
Summary:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
