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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35176
This commit extends the ReactNative-application.cmake logic so
that if the app is using codegen at the app level, the generate library
is properly built and linked.
It helps us simplify the RN Tester setup and makes it easier for app users
to use the codegen at the app level.
Changelog:
[Internal] [Changed] - [Android] Link against the app codegen if available
Reviewed By: cipolleschi
Differential Revision: D40936941
fbshipit-source-id: 26fa4d764fb369c987e94e0c3bce61841b982b27
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35075
This diff updates the New App template for Android to use the React Native Gradle Plugin.
With this we can:
1. Get rid of all the C++ code.
2. Remove a lot of New Architecture logic in the build.gradle
3. Reuse the prebuilts of React Native/Hermes via prefab
Changelog:
[Android] [Changed] - Update the template to use RNGP
Reviewed By: cipolleschi
Differential Revision: D40673732
fbshipit-source-id: 70935248993d1e24904c982e75f12ad580faa9d8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35066
This just bumps the NDK version used inside the template to be 23.
We can't merge this as it is but we have to wait for a bump of the Docker image for Android.
Changelog:
[Android] [Changed] - Bump NDK to 23
allow-large-files
Reviewed By: cipolleschi
Differential Revision: D40637103
fbshipit-source-id: e637140cbe6052e94a6efedf12f4b5b81b90a7eb
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:
This configuration was stale and has no effect on the Gradle Plugin, I'm removing it then 👍
## Changelog
[Internal] - Remove useJavaGenerator key from ReactAndroid/build.gradle file
Pull Request resolved: https://github.com/facebook/react-native/pull/35021
Test Plan: n/a
Reviewed By: cipolleschi
Differential Revision: D40506375
Pulled By: cortinico
fbshipit-source-id: 2bcdc67686b1ac9fc77091d9324f5ad585df8818
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:
It seems like CircleCI is not handling well env variables with \n in it.
I'm moving it over to a base64 encoded string and I'm extending the publish
scripts to base64 decode the key.
Changelog:
[Internal] [Changed] - Unbreak Nightly job by providing a GPG key as base64 encoded.
Reviewed By: cipolleschi
Differential Revision: D40426438
fbshipit-source-id: a60a7e7ad71580e81e675c84008d2712712e42a6
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/34970
I'm setting up `gradle-nexus` on our build to simplify the closing and releasing of staging repositories.
As of now, you'll have to go to Sonatype UI and manually click the release button.
With this plugin, we can instruct CircleCI to do the publishing automatically for us as
part of the nightly/stable release process.
Changelog:
[Internal] [Changed] - Setup gradle-nexus to automate closing and releasing staging repositories
Reviewed By: cipolleschi
Differential Revision: D40342759
fbshipit-source-id: 72e80f4bcc80058d5a6ea562ae136a91b2aeedbb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34967
This diff is a preparatory work for publishing artifacts on Maven Central.
What it does is:
1. It sets up all the 3 modules (react-native, hermes-engine, external-artifacts) for publishg
2. Adds coordinates to publish on the Snapshot repository
3. Adds support for appendign -SNAPSHOT version if invoked with `-PisNightly=true`
4. Configures GPG signing of artifacts.
I haven't touched the CircleCI and JS code yet. I'll do it in another diff.
Changelog:
[General] [Changed] - Setup publishing for Snapshot and Stable on Maven
Reviewed By: mdvacca, cipolleschi
Differential Revision: D40146212
fbshipit-source-id: 9321e16f6c18b35bc3ae785749d613085c56e7bc
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
Lulu Wu
Nicola Corti
Pieter De Baets
Ramanpreet Nara
Luna Wei
Xin Chen
Oleksandr Melnykov
Ruslan Lesiutin
Nick Gerleman
Robert Balicki
Riccardo Cipolleschi
Jonathan Keljo
Stanley Shi
Nishan
Nicola Corti
Sharon Zheng
David Vacca
Arthur Kushka
Samuel Susla
generatedunixname89002005287564
Nick Gerleman
Peter Abbondanzo
