Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43398
Implement onWindowFocusChange in Bridgeless by adding it to the ReactHostImpl
Changelog:
[Android][Breaking] Implement onWindowFocusChange in Bridgeless
Reviewed By: javache
Differential Revision: D54670119
fbshipit-source-id: 71f560e5a3bf0e853ac06955e67b8035f1ec0468
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43338
Reafactor JavaTimerManager so more code is shared between bridge and bridgeless.
Note that HeadlessJSTaskContext is not currently configured when using bridgeless.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D54496604
fbshipit-source-id: 2a61294267df372e69f8316dd8f8059625d0a2bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43367
Enable `ReactActivityDelegate` to be used outside of `ReactActivity` as well.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D54634339
fbshipit-source-id: 977e0da689d5a827feca89a5dcc9416ad5178334
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43350
Changelog: [internal]
Mount hooks have been shipped on iOS, so this removes the flag for them.
On Android, we're still testing them so it's worth moving them to the new system and scoping them to that platform.
Reviewed By: sammy-SC
Differential Revision: D54587740
fbshipit-source-id: d074927fee1a967bd3928970c31975d07cd393bb
Summary:
This adds support for 64 bit integer (long) values to the Android bridge. Per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738) Android encodes wide gamut colors as long values so we need to update the bridge to support 64 bit integers as well since these classes will soon receive those values from native.
## Changelog:
[ANDROID] [ADDED] - Update bridge to handle long values
Pull Request resolved: https://github.com/facebook/react-native/pull/43158
Test Plan: I added tests where I could for long types and truncation. I would like to add tests for ReadableNativeArray and ReadableNativeMap but I'm not sure how to go about mocking HybridData.
Reviewed By: cipolleschi
Differential Revision: D54276496
Pulled By: NickGerleman
fbshipit-source-id: 1e71b5283f662748beef1bdb34d9c86099baecb0
Summary:
In order to make the legacy APIs of Catalyst Instance backwards compatible, introducing a regular class that implements CatalystInstance so as to make these APIs available for folks in Bridgeless mode as well.
Changelog:
[Internal] internal
Reviewed By: RSNara
Differential Revision: D54093013
fbshipit-source-id: f494c05e79f570883f9b5374cd177862970304c0
Summary:
After discussing with mdvacca, we prefer to undo the change of `TurboModule` package to `.internal` as this is a quite aggressive breaking change for the ecosystem.
Moreover: users should not invoke `TurboModule.class.isAssignableFrom` because `TurboModule` is `.internal`. Therefore I'm exposing another API to check if a class is a TurboModule as a static field of `ReactModuleInfo`.
## Changelog:
[INTERNAL] - Do not use TurboModule.class.isAssignableFrom
Pull Request resolved: https://github.com/facebook/react-native/pull/43219
Test Plan: Tests are attached
Reviewed By: mdvacca, cipolleschi
Differential Revision: D54280882
Pulled By: cortinico
fbshipit-source-id: 9443c8aa23cf70dd5cfe574fe573d83313134358
Summary:
Changelog: [internal]
This adds a new type of executor in AndroidExecutors to execute runnables on the UI thread.
If the caller is already on the UI thread it'd call the runnable immediately. Otherwise it'd be scheduled in the UI thread to execute asynchronously.
Reviewed By: huntie
Differential Revision: D53941120
fbshipit-source-id: b68c7a4540be2a12df930e4e52eeb7b7a1aa91d8
Summary:
This adds support for 64 bit integer (long) values to MapBuffer. Per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738) Android encodes wide gamut colors as long values so we need to update MapBuffer to support 64 bit integers as well.
## Changelog:
[ANDROID] [ADDED] - Add 64 bit integer (long) value support to MapBuffer
Pull Request resolved: https://github.com/facebook/react-native/pull/43030
Test Plan: I've added a test to the MapBuffer test suite. This new API is otherwise currently unused but will be used in subsequent PRs as part of wide gamut color support changes.
Reviewed By: mdvacca
Differential Revision: D53881809
Pulled By: NickGerleman
fbshipit-source-id: 39c20b93493a2609db9f66426640ef5e97d6e1a8
Summary:
**History:** This component was originally introduced into React Native core in D52712758, to replace UIManagerModule.showPopupMenu().
**Problem:** But, React Native core should be lean. Adding this component to React Native bloats the core.
**Changes:** So, this diff pulls PopupMenuAndroid out into its own package in the react-native GitHub repository.
In the future, this will be migrated to a community package!
Changelog: [Android][Removed] Move PopupMenu out of React Native core
Reviewed By: NickGerleman
Differential Revision: D53328110
fbshipit-source-id: 469d8dc3e756c06040c72e08fa004aafa1bd6e18
Summary:
UIManagerListener interface is unstable and not recommended to be consumed externally, this API is likely to change in the future
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D54028407
fbshipit-source-id: c8601451f117226f9e5a4d291307f4a0ac04a10f
Summary:
This was introduced to support MapBuffer-based view managers (D33735245), but that experiment has been removed from the codebase (D53072714).
This indirection is preventing a proper fix for a crash we're seeing with RemoveDeleteTree (T178300877)
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D53586567
fbshipit-source-id: d391ca56b23fc3dd57429c5ad8a7a405e97a81f2
Summary:
The `.addUIBlock` and `.prependUIBlock` APIs on UiManagerModule are missing on Fabric.
Here I'm re-implementing them to make migration to Fabric easier.
Set of changes:
- Moved `NativeViewHierarchyManager` to `NativeViewHierarchyManagerImpl` and extracted an interface
- Moved `addUIBlock` and `prependUIBlock` to the shared `UIManager` interface
- Added a `InteropUIBlockListener` class that takes care of executing the UI Blocks, implemented as a `UIManagerListener`
Changelog:
[Android] [Changed] - Changed the API of addUIBlock and prependUIBlock to implement it also in Fabric.
Reviewed By: mdvacca
Differential Revision: D53612514
fbshipit-source-id: 1cddbc391477318064f15c733a380983c3737373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42432
Changelog: [internal]
This feature flag is accessed through `CoreFeatures` but it's initialized a few different ways:
* Android: assigned via `ReactFeatureFlags`, which is overridden by apps.
* iOS: `ReactNativeConfig` that's mapped to a dynamic configuration.
This migrates the flag to the new feature flag system.
Reviewed By: mdvacca, RSNara
Differential Revision: D52810065
fbshipit-source-id: d6fd1e819abbc4c3dee9e6221d8f99384f5197f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42927
This bumps Kotlin to 1.9.22 which is the latest in OSS and closer to the version we use inside fbsource.
Turns out that Explicit API mode was not enabled correctly, so I had to go over all the Kotlin classes
and correctly set them to `public` if they were intended to be for public consumption.
I updated some of them to `private` or `internal` but otherwise I've defaulted to `public` which is the default
we have right now.
Changelog:
[Android] [Changed] - Kotlin to 1.9.22
Reviewed By: cipolleschi
Differential Revision: D53576844
fbshipit-source-id: dd8b08ce9bf87f738159f60fd850e3e3bc490ebc
Summary:
In React Native 0.75, we will remove UIManager.showPopupMenu(), UIManager.dismissPopupMenu().
To replace that API, we are introducing this <PopupMenuAndroid> component. This component works in both Fabric and Paper!
For the usage, please see PopupMenuAndroidExample.js.
Changelog: [Android][Added] - Introduce PopupMenuAndroid to replace UIManager.showPopupMenu()
Reviewed By: mdvacca
Differential Revision: D52712758
fbshipit-source-id: a87628a168d64fabbcc4d0f7b694fa639a927448
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42716
Migrates this to the new flag system just added.
Made a quick change to the Android template, to mark Kotlin accessors as `JvmStatic` to make calling from Java more idiomatic.
Next diff will wire to MC.
Changelog: [Internal]
Reviewed By: rubennorte, mdvacca
Differential Revision: D53198874
fbshipit-source-id: 6ab5b279d9ac59733c6e820c25be72383ce0e54a
Summary:
Move all `ReactSpan` subclasses to a separate folder.
This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.
I'm adding a new span class later, which was the direct motivation for this change.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [CHANGE] - Move all `ReactSpan` subclasses to a separate folder
Pull Request resolved: https://github.com/facebook/react-native/pull/42594
Reviewed By: mdvacca
Differential Revision: D53123733
Pulled By: cortinico
fbshipit-source-id: 10db214a520d157c231e6f3b97948b4209a7ad4b
Summary:
We are making some decently large changes around here, to transition Fabric away from Yoga's private API, and add new units, and CSS properties. Even confined to Fabric, we have a large matrix of different paths for parsing.
This change consolidates layout props parsing to a single, tested path, used everywhere.
Concretely, this means removing:
1. MapBuffer for ViewProps
2. Iterator style props parsing (for layout props only)
MapBuffer for ViewProps to my understanding is not currently used at all, and has been live to edits, but untested, for quite some time. Iterator style props parsing is still enabled in some configurations, but we don't want to broadly ship its current form, and haven't been able to prioritize shipping it.
Both MapBuffer, and iterator style props parser, are performance wins. If we look at seriously shipping one of these again, we should look at swapping out the current path.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D53072714
fbshipit-source-id: 0a737c8c8f50b1f2c5c0b7ff0415e84a26a06abb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434
Changelog: [internal]
The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.
Reviewed By: RSNara
Differential Revision: D52819137
fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42655
This bug is caused by a caching issue: when the user enters a new character into the textInput: ReactTextInput 1) caches the Spannable entered by the user and 2) it updates internal Fabric state, which triggers the measurement of the TextInput component using the cached Spannable.
The problem is that the Spannable entered by the user has the wrong "styles" for the text input. Since measurement is using the cached Spannable, then the measurement of the TextInput ends up being is incorrect.
In this diff I'm fixing the bug by updating the styles (lineHeight) of the cached spannable that is cached when the user updates the TextInput.
The styles weren't updated correctly because mTextAttributes didn't have the proper style props set
Changelog:
[Android][Fixed] - Fix incorrect measurement of TextInput when new architecture is enabled
Reviewed By: javache, sammy-SC
Differential Revision: D52924982
fbshipit-source-id: ced9f2c348bdb9bf706028b1063858cebd5a071a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42600
Disentangled the logic for emitting touches to JS on Android. `receiveTouches` should never be used as a public API, as TouchEvents can be dispatched just like any other event, and receiveTouches is an internal helper for `TouchEvent`.
Changelog: [Android][Removed] Updated migrated guidance for EventEmitter and reduced visibility of internal TouchesHelper methods
Reviewed By: cortinico
Differential Revision: D52907393
fbshipit-source-id: a8207039c863ab23a1d93dd2d2f28e8a274c8ecf
Summary:
With the current ways metro location is determined, when we want to use a different metro port this requires app to be rebuild as the port and location are stored in resource file that gets compiled to R.class. The only way to avoid app rebuild due to a port change is to use shared preferences that can be accessed from dev menu, where metro URL can be specified. However, due to a separate code-paths for retrieving bundle location and for `/inspector/device` calls, the setting only applies to the former. As a consequence, you can change metro URL in the shared preferences, but debugging would only work if you use the default port or you rebuild the app with the correct port number.
This PR removes the separate code-path for retrieving inspector URL including all the dependencies scattered across different files including the gradle plugin. We then replace calls to `PackagerConnectionSettings.getInspectorServerHost` with `PackagerConnectionSettings.getDebugServerHost` which respects the shared preferences and other possible ways of configuring the port.
I decided to remove the separate inspector URL code path, as the resource value for inspector port added in https://github.com/facebook/react-native/issues/23616 was never functioning properly due to a bug. In the said PR introduced a bug in [AndroidInfoHelpers.java](https://github.com/facebook/react-native/blob/a13d51ff1c38ea85e59f4215563c0dd05452f670/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/systeminfo/AndroidInfoHelpers.java#L77) where `react_native_dev_server_port` was used instead `react_native_inspector_proxy_port`. As a result the added resource value was never read.
This can be potentially a breaking change as I'm removing some public methods. However I think it is unlikely anyone relied on said methods. As a part of this PR I'm also changing occurences of removed methods from ReactAndroid.api – I don't know how to test those changes since I don't understand how this file is used as it doesn't have any references in public code.
## Changelog:
[ANDROID] [FIXED] - Make Android respect metro location from shared preferences for the debugger workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/42617
Test Plan:
1. Run android app on emulator using default port
2. Check the debugger works when using "Open Debugger" option from dev menu
3. Restart metro with custom port (`--port 9090`) while keeping the app running
4. Open dev menu, click "Settings" then "Debug server host & port", put "10.0.2.2:9090" there
5. Reload the app
6. Before this change things like hot reload would continue to work while "Open Debugger" option would do nothing
7. After this change both reloading and debugging will work
Important: I haven't tested changes made to ReactAndroid.api as I don't know what this files is used for with no references in the codebase.
Reviewed By: cortinico
Differential Revision: D53010023
Pulled By: huntie
fbshipit-source-id: cc8b9c5c7e834ec9ea02b1ed5acf94f04f7b7116
Summary:
A first step in my work on https://github.com/react-native-community/discussions-and-proposals/issues/695
De-duplicate the code for creating `Spannable` on Android. I'm planning to add quite serious new features to this module. This would be really hard with the current level of code duplication.
## Changelog:
[INTERNAL] [CHANGED] - De-duplicate building `Spannable` on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/39630
Test Plan: I tried to ensure that the refactored code is relatively easy to prove to be equivalent to the original duplicated one, but there's always a risk of a human mistake in this process. So far, I have been testing this by ensuring that nothing broke in the `Text` example section in RNTester.
Reviewed By: mdvacca
Differential Revision: D51016244
Pulled By: NickGerleman
fbshipit-source-id: e9f873c01b2af0685c7b0943aebea170c997d22e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42362
This undos a change of CallInvokerHolder bringing it back in the public package: https://github.com/facebook/react-native/commit/b7191cde4e36
The problem is that if a developer wants to use the C++ CallInvokerHolder to schedule work on the JS thread from C++, they're forced to import the `.internal`
Java/Kotlin class.
Plus this is going to be a massive breaking change for the ecosystem:
https://github.com/search?type=code&q=%2Fimport.*CallInvokerHolderImpl%2F
So unless we come with a clear deprecation/replacement path, I'm undoing this change for now.
Changelog:
[Internal] [Changed] - Undo move of CallInvokerHolder to `.internal`
Reviewed By: cipolleschi
Differential Revision: D52873256
fbshipit-source-id: 900c3170ed2100ec706b03112bc23a0ba0171bcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42355
`RemoveDeleteTreeUIFrameCallback` operated directly on the view to clean up its children, which does not correctly account for subviews which have been clipped because they're outside the visible frame.
Changelog: [Android][Added] Added `removeAllViews` to IViewGroupManager.
Reviewed By: jehartzog, sammy-SC
Differential Revision: D52834835
fbshipit-source-id: fb7f07a17d07467eecd3ce9721afc2f3abcc0caa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42327
This diff is the result of running
`buck2 run //xplat/js/scripts/rn-api:generate-rn-api-metadata`
After this lands, `react-native-android-breaking-change-detector` will actually be green again, after the previous diff fixed the infra setup.
Changelog: [General][Fix] Update stale ReactAndroid.api values after CI breakage
Reviewed By: cortinico, mdvacca
Differential Revision: D52800160
fbshipit-source-id: b96533baa1cb704ad43482d7a52db50e6dce9821
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41978
I'm revering the removal of ReactModule codegen.
We are postpoinging the removal of the codegen for the future, the reasons are:
- resources: the experiment that removes the codegen shows neutral metrics, but the codegen is shared between bridge and bridgeless, so we will need to implement and test the removal for bridge and we don't have the time to do this right now.
- reduce fragmentation: we don't want to fragment NativeModules configuration between bridge and bridgeless, doing so will bring a lot of confusion to developers
- we don't want to introduce a public APIs in 0.73 that we know they are not used in production for now, we better remove these "unstable" apis before 0.74 cut
Note: I'm updating ReactAndroid.api because this is an intended change of APIs which were not part of 0.73 and we don't want them to be part of 0.74.
changelog: [internal] internal
Reviewed By: RSNara
Differential Revision: D52223650
fbshipit-source-id: 681bf5e4aab776505f64b1972a6ace6340db4587
Arushi Kesarwani
Pieter De Baets
Rubén Norte
Ryan Linton
Nicola Corti
Ramanpreet Nara
David Vacca
Samuel Susla
Nick Gerleman
Wojciech Dróżdż
Jakub Trzebiatowski
Krzysztof Magiera
Xin Chen
Erica Klein
Gijs Weterings