When decoupling the community-cli-plugin from the
@react-native-community/cli-server-api (#45311), a middleware stub was
created to allow a runtime stub to be used in this case. This middleware
should be used so as not to break when the optional cli-server-api
dependency isn't present.
Changelog: [General][Fix] - Fix npm react-native start when
cli-server-api isn't installed
Testing: Forced a runtime exception simulating the package not being
dependent and was able to build rn-tester.
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47434
Migrate ReactVirtualTextShadowNode to kotlin and make it internal
changelog: [Android][Breaking] Reduce visibility of ReactVirtualTextShadowNode to internal
Reviewed By: shwanton
Differential Revision: D65493927
fbshipit-source-id: 2b5997d000b5dc489ba93edb226455ef0855b98b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47432
In this diff we are excluding the $$PropSetter classes from public API, we do this by adding the UnstableReactNativeAPI annotation on all $$PropSetter classes
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D65488026
fbshipit-source-id: 9f1bbe7b25fa69c0a40f6cb0ff38a8ae6ee8d97d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47350
Changelog: [Internal]
we don't need any of these now since no one is calling `contextContainer_->at<std::shared_ptr>("ReactNativeConfig")` anymore
Reviewed By: NickGerleman
Differential Revision: D65304976
fbshipit-source-id: 5f835ab9ac429aa1942cc8d9669812c1ac994238
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46868
jsBuild prasing was done at the js level.
But, for the c++ pipeline, we have to parse the js build in native.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63927093
fbshipit-source-id: ce7ee46714ee0e72e450003330dbca78acb264a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47428
This changes the messages that the bot is printing.
I've moved from using a table to using GitHub's admonitions that
renders nicely are are more informative.
Changelog:
[Internal] [Changed] - Update messages for react-native-bot
Reviewed By: mdvacca
Differential Revision: D65485633
fbshipit-source-id: f43f7bd75280bfd0aceab48b2517306c1057b778
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47427
I've noticed that react-native-bot posts twice once we can't find a reproducer.
(see here: https://github.com/facebook/react-native/issues/47421)
This fixes it by letting it post only once.
Changelog:
[Internal] [Changed] - Prevent react-native-bot from double posting on missing reproducer
Reviewed By: mdvacca
Differential Revision: D65485634
fbshipit-source-id: dbe9b1311aef246dead6d9b922c1256363e894f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47423
cipolleschi found out that we broke the `ReactViewGroup` constructor when making this class Nullsafe.
Specifically now users would need to pass a `Context` and not a `Context?` as libraries will break (and this will break a lot of them).
So I'm undoing this change by annotating this parameter as Nullable.
Changelog:
[Android] [Changed] - Undo a breaking change on ReactViewGroup constructor
Reviewed By: tdn120
Differential Revision: D65483379
fbshipit-source-id: 43f7bcab5f10b1b8b5601de1dab314d7bbb1eefe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47385
BridgelessCatalystInstance class is deprecated, please to migrate to new architecture using [com.facebook.react.defaults.DefaultReactHost] instead.
changelog: [Android][Changed] Deprecate BridgelessCatalystInstance class
Reviewed By: cortinico
Differential Revision: D65430789
fbshipit-source-id: 011b372c93c39862d5821713aa8f673084b52c2a
Summary:
X-link: https://github.com/facebook/yoga/pull/1736
Pull Request resolved: https://github.com/facebook/react-native/pull/47358
`LayoutableChildren<yoga::Node>::Iterator` showed up to a surprising extent on a recent trace. Part of this was during pixel grid rounding, which does full tree traversal (we should fix that...), where the iterator is the first thing to read from the node.
I ran Yoga microbenchmark with Yoga compiled with `-O2`, where we saw a regression of synthetic performance by ~10%, but it turns out this build also had ASAN and some other heavy bits enabled, so the real impact was quite lower (~6%).
I was able to make some optimizations in the meantime against that, which still show some minor wins, reducing that overhead to ~4% in the properly optimized build (and a bit more before that). This is still measurable on the beefy server, and the code is a bit cleaner, so let's commit these!
Note that, in real scenarios, measure functions may dominate layout time, so display: contents does not mean end-to-end 4% regression, even after this change.
This change makes a few different optimizations
1. Removes redundant copies
2. Removes redundant index keeping
3. Mark which branches are likely vs unlikely
4. Shrink iterator size from 6 pointers to 3 pointers
5. Avoid usage in pixel grid rounding (so we don't need to have cache read for style)
In "Huge nested layout" example
| Before display: contents support | After display: contents support | After optimizations |
| 9.77ms | 10.39ms | 10.17ms |
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D65336148
fbshipit-source-id: 01c592771ed7accf2d87dddd5a3a9e0225098b56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47417
Backing out this change as it was breaking an internal app. I'll reland this next week when I have more time.
## Changelog:
[iOS][Changed] - Revert fix that checks whether an image is present on disk.
## Facebook:
This is breaking twilight.
Differential Revision: D65479912
fbshipit-source-id: dcd5ac5f3d98ba2f10b9519f09d3eb1fd454da61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47368
This class should be internal and has no meaningful usages outside of React Native.
See https://github.com/search?type=code&q=%22DevLoadingModule%3A%3Aclass%22
So technically breaking but I expect no impact for OSS at all.
Changelog:
[Android] [Breaking] - Make `DevLoadingModule` internal
Reviewed By: javache
Differential Revision: D64725164
fbshipit-source-id: 5f39e609c611662c71cc08bffa195f7bea5db5bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47371
This interface should have not been exposed in the first place.
I'm converting it to Kotlin + making it `internal`.
I found no meaningful usage in OSS so I expect no breakages.
Changelog:
[Android] [Breaking] - Stable API - Convert to Kotlin and make internal `NotThreadSafeViewHierarchyUpdateDebugListener`
Reviewed By: javache
Differential Revision: D65420912
fbshipit-source-id: 5afdb013f588a5698b4e7467a7f1096c24d1733e
Summary:
Fixes https://github.com/facebook/react-native/issues/47352
This fixes a bug when the user is providing its own CMakeLists.txt file say because they want to compile more C++ code than we actually provide.
Previously the `*.cpp` will evalute file in the current directory, meaning that the app's default `OnLoad.cpp` file would be ignored.
## Changelog:
[ANDROID] [FIXED] - Use absolute path when compiling appmodules.so sources
Pull Request resolved: https://github.com/facebook/react-native/pull/47379
Test Plan:
Tested against the reproducer provided in:
- Use absolute path when compiling appmodules.so sources
Reviewed By: cipolleschi
Differential Revision: D65428676
Pulled By: cortinico
fbshipit-source-id: 7f3e4d470da0fffc5191c1a2c7e8fec517fee496
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47378
The RCTMD5Hash in RCTUtils is using CC_MD5 function which is deprecated. unfortunately we can't really change it or we will break many apps that use it in the AsyncStorage.
Those app wlll have to do a migration to use a different function. Meanwhile we are suppressing the warning
## Changelog
[Internal] - Suppress CC_MD5 warning
Reviewed By: cortinico
Differential Revision: D65424309
fbshipit-source-id: e0258ae68482f6c4a3a865bb52920f87bc5ada21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47391
React Native can preload before the activity is available.
Preloading will execute the js bundle. If the js bundle throws an error, it'll try to render a redbox.
If the activity isn't available, and hasn't been set on the react instance yet, the redbox will just render nothing.
## Changes
In this diff, just re-try displaying the redbox after the application sets the activity on the react instance (i.e: calls onHostResume(activity)).
Changelog: [Android][Breaking] - Rename DevSupportManagerBase.getCurrentContext() -> getCurrentReactContext()
Reviewed By: mdvacca
Differential Revision: D65352596
fbshipit-source-id: 7750f6ca493fc50405119958e0f2908fc24f1cb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47396
Migrate ReactUnimplementedViewManager to internal visibility
verified and there are usages on OSS
changelog: [Android][Breaking] Reduce visibility of ReactUnimplementedViewManager to internal
Reviewed By: cortinico
Differential Revision: D65444514
fbshipit-source-id: 11ff2acc96098bc4e53be7ef3059e4a5c112c43e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46939
X-link: https://github.com/facebook/yoga/pull/1722
tsia! opted for one function for each keyword just like auto. This is kinda annoying and not the most sustainable, so maybe it makes more sense to make a new enum here and just add one function
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D64002837
fbshipit-source-id: f15fae9fc0103175e1d85850fc9aa68579989fd3
Summary:
X-link: https://github.com/facebook/yoga/pull/1721
Pull Request resolved: https://github.com/facebook/react-native/pull/46938
The private internals of how we store styles needed to change a bit to support 3 new keyword values. Right now the only other keyword that can be stored is `auto`. As a result there isn't much fancy logic to support storing this and its just stored as a specific type inside of `StyleValueHandle`. There are only 3 bits for types (8 values), so it is not sustainable to just stuff every keyword in there. So the change writes the keyword as a value with a new `keyword` `Type`.
I chose not to put `auto` in there even though it is a keyword since it is a hot path, I did not want to regress perf when I did not need to.
I also make a new `StyleSizeValue` class to store size values - so values for `width`, `height`, etc. This way these new keywords are kept specific to sizes and we will not be able to create, for example, a margin: `max-content`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63927512
fbshipit-source-id: 7285469d37ac4b05226183b56275c77f0c06996c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47324
I need to reference this type somewhere else, but not an array of the type.
Generally we prefer that all exported types are the object itself, and it used as a member type of arrays when used.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65259014
fbshipit-source-id: 35fb5fe03a44bed61ad87337d0fc5c198744c0e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47323
This change adds support for number literals as a type.
The codegen already has parsing support for these types
```
+passNumber: (arg: number) => void;
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
```
This change now also supports
```
+passNumberLiteral: (arg: 4) => void;
```
On the native side this is treated the same as `number`. It could be strengthened in the future.
This is a pre-requisite for number literal unions and enums.
Changelog: [Added] Codegen: Added support for Number literals in native module specs
Reviewed By: makovkastar
Differential Revision: D65249334
fbshipit-source-id: 98b051d2a6bd1ad5cc6473ac88acfcbe82bd5c7d
Summary:
Those 2 classes are not supposed to be exposed externally, so I'm making them internal.
The were never part of the public API so I'm not marking this commit as [BREAKING]
Changelog:
[Android] [Changed] - Make ReactDebugOverlayTags, DebugOverlayTags, Printer, PrinterHolder, NoopPrinter internal
Reviewed By: fabriziocucci
Differential Revision: D65420257
fbshipit-source-id: b870274e84d9c3202b9f21360c29eeb995a8d52b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47374
I've converted this class to Kotlin + made it `internal` as it should not be exposed publicly.
This class is part of the iterop layer for the New Architecture.
Marked as breaking but I expect no meaningful breakages here.
Changelog:
[Android] [Breaking] - Stable API - Make InteropModuleRegistry internal
Reviewed By: javache
Differential Revision: D65421965
fbshipit-source-id: 207be5379ebe3a31530cfea75b4623787f5ae7cf
Summary:
This PR provides a fix for the long existing issue of missing check for invert color in accessibility options on Android.
Reference Issue : https://github.com/facebook/react-native/issues/30870
## Changelog:
- Added native module code to check for invert color settings value
- Updated js module to return a proper promise instead of default false for isInvertColorsEnabled()
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Missing isInvertColorsEnabled implementation for Android
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/47341
Test Plan: Tested on OnePlus 12 with Android 14 and Pixel 6 with Android 15. The try catch exists because in some cases if the switch hasn't been toggled before the android system raises the missing settings exception.
Reviewed By: cortinico, fabriziocucci
Differential Revision: D65419632
Pulled By: javache
fbshipit-source-id: ddb103445a9d0f318e52ba9d23750140ce5a7ed0
Summary:
Following up from https://github.com/facebook/react-native/issues/47182, as basic caching control is already in place in Android, it can be extended to include the `only-if-cached` option.
We check whether the image is in the cache. If it is, we proceed to load it. Otherwise, we do nothing.
## Changelog:
[ANDROID] [ADDED] - Image `only-if-cached` cache control option
Pull Request resolved: https://github.com/facebook/react-native/pull/47348
Test Plan:
In the `rn-tester`, I added a third example for Android where the third image will never be loaded as the cache policy is set to `only-if-cached` and the image has not been loaded before.
<details>
<summary>Video demonstrating how the `only-if-cached` options behaves</summary>
https://github.com/user-attachments/assets/45669e81-5414-4103-8931-138bffa81447
</details>
<details>
<summary>Error from image not found in cache example</summary>
<img width="807" alt="image" src="https://github.com/user-attachments/assets/6b79d811-1809-437c-b2fe-c86d3da7c58d">
</details>
Reviewed By: rshest
Differential Revision: D65384639
Pulled By: Abbondanzo
fbshipit-source-id: f4a72694f45eb3d7097c350f4a4008a0abf0a1ab
Summary:
I believe these two were the last items under `com.facebook.debug` that were still Java.
I thought about making DebugOverlayTag a Data class, but i will leave it up to the reviewer to decide if it would be needed or not.
## Changelog:
[INTERNAL] [FIXED] - Migrate DebugOverlayTag and ReactDebugOverlayTag to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/47362
Test Plan:
`./gradlew test`:
<img width="1265" alt="Screenshot 2024-11-02 at 18 45 45" src="https://github.com/user-attachments/assets/405e77bc-1287-4329-b230-9f46eadb3580">
Reviewed By: javache
Differential Revision: D65417984
Pulled By: cortinico
fbshipit-source-id: e39224e40bde281498fdbed1609a03b264967396
Summary:
While we (Margelo) were developing a new C++ 3D library for react-native, we noticed that Java often keeps a lot of dead instances in memory, making it hard to debug memory allocations (or actually _de_-allocations), especially since we use `jsi::HostObject` and `jni::HybridClass` in conjunction. Having two garbage-collected languages retain an object is a bit tricky, and making sure that we aren't doing anything wrong with our allocations and references was not easy - but manually calling `System.gc()` on app reloads helped us see that much better.
Before this, we needed to wait multiple minutes until some Java objects are actually freed from the GC. Our use-case was a `facebook::jni::HybridClass`, which was held strong in a `facebook::jsi::HostObject` (so again, two GC'd languages).
There _should_ be no change in behaviour with this PR, just two things to note:
1. Memory might be free'd more eagerly in full reloads (dev builds) - makes sense for library developers, especially when working with C++ modules.
2. `System.gc()` only _suggests_ garbage collection, it does not _force_ it. But when it runs, it might impact performance, although we haven't noticed any impact of that at all. The garbage collector runs anyways - better during a reload than later when exceuting the app normally.
## 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
-->
[ANDROID] [ADDED] - Trigger Java GC on app reload
Pull Request resolved: https://github.com/facebook/react-native/pull/43813
Test Plan:
Open an app, create a Java module that holds a few objects, add `finalize()` methods to those objects and log their deletion.
Reload the app to see the logs, compare before vs after.
Reviewed By: rshest
Differential Revision: D65418163
Pulled By: javache
fbshipit-source-id: 7597548790577dfc542b57f59578ae48df543b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47369
This just bumps the AGP patch version to the latest stable.
Changelog:
[Android] [Changed] - AGP to 8.7.2
Reviewed By: tdn120
Differential Revision: D65336357
fbshipit-source-id: 9a7464304ba29f6b752f41b252bde9cb0eca0e9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47357
`MultiSourceHelper` should not yield an `ImageSource` that has its cache control policy set to `RELOAD`. This change skips such sources when computing the bestCached item (but not best item)
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D65337414
fbshipit-source-id: bdd0d55f4a65128b141a1c7a132dba085232fa11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47356
Add utf16 method to JSI. This change will add the default implementation
for all VMs by calling UTF8 and manually convert it to UTF16. A later
change will be added for Hermes to use internal VM information to get
the UTF16 string.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D64918244
fbshipit-source-id: 6fc0c44fc397c2f8bb40a4262596b178ee4f1f29
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47333
Motivated by https://github.com/facebook/hermes/issues/1549. This was originally changed in https://github.com/facebook/react-native/pull/46696, as our internal Flow support had diverged from `babel/eslint-parser` (https://github.com/facebook/react-native/issues/46601).
We effectively have three flavours of JavaScript in support:
- Flow@latest for the `react-native` package, shipped as source — uses `hermes-parser`.
- TypeScript for product code (community template, Expo) — uses `babel/plugin-syntax-typescript`.
- Plain JavaScript or Flow in product code, *which may be extended with additional user Babel plugins and needs lenient parsing* — uses `babel/plugin-syntax-flow` via `babel/eslint-parser` (**this change**).
I'd love to simplify this 😅.
Switching to `hermes-eslint` for the RN monorepo codebase (D63541483) is unchanged.
Changelog: [Internal]
Reviewed By: robhogan, cipolleschi
Differential Revision: D65272156
fbshipit-source-id: 3a2bbe3fcf8ed6057f6d994a0be4985e6bf46fa9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47339
Fixing issue raised in https://github.com/facebook/react-native/issues/47307
This is a follow up from D62286026.
It appears there was a line that went missing while trying to refactor the code.
`fitsSystemWindows = true` is needeod for < API 30 to avoid content rendering under the system bars when Modal is shown with Activity that is edge-to-edge.
Changelog:
[Android][Fixed] Fix Regression - Modal content rendering below system bar on < API 30 when activity is edge-to-edge
Reviewed By: cortinico
Differential Revision: D65280014
fbshipit-source-id: 616ff739be55635f1295ef3bf8b997a27ef769ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47342
There are things we can do to modernize `FBHashKit` to make it ready for prime time, aka Layer Zero.
* Consolidate down to a singular `meta_hash(...)` generic macro (supports all primitives for hashing)
* Eliminate the unnecessary C++
* Deprecate legacy FB APIs
* Make logic (and interfaces) explicit for 32 vs 64 bit inputs and 32 vs 64 bit outputs
* Introduce robust unit tests
* Have unit tests actually testable for 32-bit hashes
## Changelog
[Internal][Change] Prep to move `FBXXHashUtils`
Reviewed By: cipolleschi
Differential Revision: D65245787
fbshipit-source-id: 311404068fd9df2a77d1ae4850b8a785466e73f0
Summary:
Depracated usage of scrollInsets + an unused param.
## Changelog:
[INTERNAL] [FIXED] - Switch to verticalScrollIndicatorInsets and mark unused value as __unused in test file
Pull Request resolved: https://github.com/facebook/react-native/pull/47314
Test Plan:
Running the specific test itself, it passes:
<img width="1092" alt="Screenshot 2024-10-30 at 18 02 08" src="https://github.com/user-attachments/assets/e3ed27c6-9f00-4777-a72c-92f0da93a79f">
Reviewed By: NickGerleman
Differential Revision: D65231365
Pulled By: philIip
fbshipit-source-id: eed795ad65bd837fb9f38175081d961245ff3932
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47320
I've solved all the warnings on ReactAndroid/hermes-engine.
This enables warningsAsErrors for that part of the codebase so we can make sure
no further warnings get introduced.
Changelog:
[Internal] [Changed] - Enable warningAsErrors for hermes-engine
Reviewed By: NickGerleman
Differential Revision: D65243753
fbshipit-source-id: 17c22d1a7a32d2c684d7f236f7554f6e26469e99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47340
This diff cleans up some problematic `React.ElementRef<T>` when T is generic type.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D65280467
fbshipit-source-id: 71172b16320a10cbc7a8b46dae5d3dd0eb00ba0c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47337
We call `onSurfaceStart` after calling `surfaceHandler.start()`. In theory it's possible for the React surface to start generating commits before we've informed the mounting manager of the surface having started, which could cause us to not accurately track views allocated for that surface so far.
Changelog: [Android][Fixed] Addressed race condition in surface start.
Reviewed By: rshest
Differential Revision: D65269674
fbshipit-source-id: 2927220bc17e61125dabcdd75f5325a0ca77e60b
Summary:
Fixes https://github.com/facebook/react-native/issues/12606
Previously, `Image` cache control options were not functional on Android, even though they were being passed to the native component via the `source` prop. This PR addresses that by implementing logic to manage cache behaviour on Android.
When the `reload` option is explicitly set, the image is now evicted from both memory and disk caches before a new request is made. This ensures the image is always fetched from the source, aligning the caching behaviour between Android and iOS for the `default` and `reload` options.
## Changelog:
[ANDROID][ADDED] - Enabling basic `Image` cache control for Android
Pull Request resolved: https://github.com/facebook/react-native/pull/47182
Test Plan:
Added a new example to the `rn-tester`, where we can notice that the image on the right is reloaded if rendered or re-rendered as the cache policy is set to `reload`. The image on the left has the cache policy set to `default` and won't be re-rendered as the image is already in the cache. See the video below:
https://github.com/user-attachments/assets/88bc1d2d-0239-4deb-bcde-fe0ce521ff4d
Also tested on both old and new architecture.
Reviewed By: NickGerleman
Differential Revision: D64915440
Pulled By: Abbondanzo
fbshipit-source-id: 32e1c55dd20bf96ab0f69ef900d821c3c2552ef7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47231
changelog: [internal]
`EventEmitter::dispatchEvent` and `EventEmitter::dispatchUniqueEvent` that were accepting shared_ptr are not needed. Their functionality is covered by other methods. Let's get rid of them to keep the API of EventEmitter slim.
Reviewed By: rubennorte
Differential Revision: D65040505
fbshipit-source-id: cffdc3ef042418178c5e2e5714779dfd0b61455e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47329
Downgrading from fatal (introduced in D63148523). It's not yet clear why this is firing, and may point at deeper underlying issues, as the re-ordering we do in `disableMountItemReorderingAndroid` only occurs at a later point in `FabricMountingManager`.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D65267936
fbshipit-source-id: cb32b149a77c9e5a3ac6350baaeae9c7215df01b
Summary:
This pr is part of issue https://github.com/facebook/react-native/issues/46757 solving a task - [ME2E0008] [ME2E0009]
- Set up a test
- Starts the app
- Scrolls until flatlist is visilbe and clicks on flatlist
- Click basic button
- Scroll down until item 600 is visible
## Changelog:
[Internal] [Added] - Add e2e-test logic that click button & scroll down until specific item is visible
Pull Request resolved: https://github.com/facebook/react-native/pull/46804
Test Plan:
### Test Locally
- iOS
```bash
yarn install
cd packages/rn-tester
yarn e2e-build-ios
```
- Android
```bash
yarn install
cd packages/rn-tester
yarn e2e-build-android
```
### Start Maestro
- iOS
```bash
cd packages/rn-tester
yarn e2e-test-ios
```
- Android
```
cd packages/rn-tester
yarn e2e-test-android
```
### Test in CI
To test in CI, just add a comment on your PR with the text:
```
/test-e2e
```
Reviewed By: cortinico
Differential Revision: D63829274
Pulled By: cipolleschi
fbshipit-source-id: f7b4342ed353a48123f87dcfd8d503009f65637c
Summary:
This pull request fixes a style bug in the AnsiHighlight component when the application is in Right-To-Left (RTL) mode. The adjustments ensure that text highlighting is visually consistent and functions properly across all layout modes.
### Before
| Android RTL | iOS RTL | Android LTR | iOS LTR |
|----------|----------|----------|----------|
|  |  |  |  |
### After
| Android RTL | iOS RTL | Android LTR | iOS LTR |
|----------|----------|----------|----------|
|  |  |  |  |
## Changelog:
[GENERAL] [Fixed] - AnsiHighlight style in RTL layout
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/47230
Test Plan:
To test the changes, open LogBox while the app is in RTL mode. The modifications ensure that any error messages display correctly. I have verified that the changes function properly in both LTR and RTL modes, and all existing functionality remains unaffected.
This is an example component to throw an error to show LogBox.
```tsx
import React from 'react';
import {Alert, Button, I18nManager, StyleSheet, Text, View} from 'react-native';
function SampleError() {
return (
<View>
<Button
title="Change to RTL"
onPress={() => {
I18nManager.allowRTL(true);
I18nManager.forceRTL(true);
Alert.alert('Restart app to apply changes');
}}
/>
<Button
title="Change to LTR"
onPress={() => {
I18nManager.allowRTL(false);
I18nManager.forceRTL(false);
Alert.alert('Restart app to apply changes');
}}
/>
<Text style={styles.text}>
isRTL: {I18nManager.isRTL ? 'true' : 'false'}
</Text>
<Button
title="Show Error"
onPress={() => {
console.error('sample خطا');
}}
/>
</View>
);
}
const styles = StyleSheet.create({
text: {
fontSize: 24,
textAlign: 'center',
paddingVertical: 20,
},
});
export default SampleError;
```
Reviewed By: sammy-SC
Differential Revision: D65145991
Pulled By: NickGerleman
fbshipit-source-id: cbca106813e587ed223be48b75ee5279072c2da0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47322
Changelog: [Internal]
these callsites were causing crashes in new bridgeless integrations, it appears they are not used, so cleaning up. after this, we can remove all callsites that insert ReactNativeConfig to the contextContainer.
Reviewed By: javache
Differential Revision: D65191733
fbshipit-source-id: 94e694ef27249773c2a39bd77f316f8f5cc2b1fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47321
Changelog: [Internal]
this seems to be the last callsite where we read the ReactNativeConfig from the contextContainer. i don't think this killswitch should block cleanup of the ReactNativeConfig, so maybe we can just remove this?
Reviewed By: cortinico
Differential Revision: D65192744
fbshipit-source-id: d8b595edb6fecce05e67abc257d98805daa16a9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47313
We're going to fix up a bunch of designated initializers. `RCTSurfaceHostingProxyRootView` is particularly problematic because different initializers will do different things even though reading the code it looks like they should be equivalent. Remove the encapsulated "start" to the provided "surface", and require it to be explicit at the callsite.
## Changelog:
[iOS][Changed] - `RCTSurfaceHostingProxyRootView` no longer has different behavior (whether it calls `start` on the provided *surface*) depending on which initializer is used. Call `start` yourself on the *surface* instead.
Reviewed By: cipolleschi
Differential Revision: D65214656
fbshipit-source-id: 179d5220d4f866b4452561e1bb6e2051020c8a11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47297
In this diff I'm proposing to remove configuration for RCTConstants.RCTGetMemoryPressureUnloadLevel API in iOS
changelog: [iOS][Breaking] Delete experimental API RCTConstants.RCTGetMemoryPressureUnloadLevel
Reviewed By: rubennorte, philIip
Differential Revision: D65181556
fbshipit-source-id: c435bec6ed03562b53f1924add7b69ab517b190b
Summary:
This PR introduces `RCTArchConfiguratorProtocol` for better separation of concerns inside of RCTAppDelegate.
It's also a prerequisite for https://github.com/facebook/react-native/issues/46298
Discussed with cipolleschi
## Changelog:
[IOS] [ADDED] - introduce RCTArchConfiguratorProtocol
Pull Request resolved: https://github.com/facebook/react-native/pull/47306
Test Plan:
- CI Green
- Test if methods can be overriden
Reviewed By: realsoelynn
Differential Revision: D65212703
Pulled By: cipolleschi
fbshipit-source-id: 9850fec31c421f0c6230e7e23d7a208d823d828f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47302
changelog: [internal]
The original cancellation logic cancelled image request when RCTImageComponentView was recycled but the image request was never resumed.
So in case the request was cancelled and later the same shadow node representing the image view was showed, the image request was never fulfilled and it stayed blank. It entered invalid state from where it would never recover. The image would go from state: Loading -> Cancelled and Cancelled is terminal state.
This diff adds a "resume" mechanism. If image goes from Loading -> Cancelled and something subscribes to the image state, the image request will be started again.
So we can go from Loading -> Cancelled -> Loading -> Completed.
This diff also moves the resume/cancel mechanism to ImageResponseObserverCoordinator. Where we can observe if anything is observing result of the image response.
Even though this case was highly unlikely, with <Activity /> component in React Native, it may occur.
Reviewed By: lyahdav
Differential Revision: D65149804
fbshipit-source-id: d59c1793785a367bb92602f6438666fa53db4ceb
Summary:
in the `image component`, add the ts definition with the `resizeMethod` attribute value as `none`.
## Changelog:
[Android][Fixed] - the definition of ts of resizeMethod attribute is none.
Pull Request resolved: https://github.com/facebook/react-native/pull/47227
Test Plan: <img width="579" alt="image" src="https://github.com/user-attachments/assets/e91dc47a-22c4-4d47-a4c2-6497d47cb842">
Reviewed By: javache
Differential Revision: D65058737
Pulled By: Abbondanzo
fbshipit-source-id: a077e4e4786a72ebffaf0698217809b1e7fde226
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47241
Changelog: [internal]
The options for the internal constructor of `PerformanceMeasure` shouldn't be optional. This just cleans that up.
Reviewed By: rshest
Differential Revision: D64480048
fbshipit-source-id: d0275276b11bd329aa2e4667646c67608d562299
Summary:
This PR introduces `RCTUIConfiguratorProtocol` for better separation of concerns inside of RCTAppDelegate.
It's also a prerequisite for https://github.com/facebook/react-native/issues/46298
Discussed with cipolleschi
## Changelog:
[IOS] [ADDED] - introduce RCTUIConfiguratorProtocol
Pull Request resolved: https://github.com/facebook/react-native/pull/47139
Test Plan:
- CI Green
- Test if methods can be overriden
Reviewed By: blakef
Differential Revision: D65063839
Pulled By: cipolleschi
fbshipit-source-id: b63766e245d57f369ab94bd8047d5de9a3447b3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47271
Let's keep the recent goals of centering (instead of arbitrary prioritizing ascent), ala spec, and make some changes to allow overlapping interior line-boxes, and make the implementation a lot simpler, instead of the cruft it has been accumulating.
The new simple versions is implemented as the only `CustomLineHeightSpan`. This replaces the code used when `enableAndroidLineHeightCentering` is enabled (which is now the default).
Legacy path is renamed to `LegacyLineHeightSpan`, slated to be deleted if rollout goes well.
We cannot yet cause text to overflow the bounds of the underlying TextView until potentially large later work related to ReactTextView reimplementation.
There's a somewhat arbitrary choice here, when rounding, to whether we ceil ascent vs descent when pixels don't evenly split. This does result in a visual difference, and for sake of avoiding breakage of screenshots, I left the same choice as before.
Changelog:
[Android][Fixed] - Reimplement Android lineHeight positioning/determination
Reviewed By: javache
Differential Revision: D64716557
fbshipit-source-id: 5a947377df7cfee9dff4484c840939f527caf94b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47270
Lets add some screenshot tests, along with one more example, and fixing some silly typos in test IDs.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65094482
fbshipit-source-id: a5f3e06c4737158bf6419364d05668c3feb1bd5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47282
D63318754 fixed a class of issues with RTL horizontal scrollviews by moving logic from native Android view layer to Fabric ShadowNode layer.
I realized quite a bit later this is problematic for legacy arch, since it now never runs RTL translation code, and all our RTL screenshot tests are against new arch.
It's tricky to port Fabric ShadowNode related code to Paper since its shadownodes are more coupled to Yoga nodes, and the existing solution for contextual layout direction didn't quite work, so I went with the original logic we had for this, where we use global layout direction to determine whether to offset, and disable removeClippedSubviews, and this is applied via onLayout. This is wrong in several ways, but not a regression compared to previous legacy arch behavior. The fully correct behavior will require new arch.
Changelog:
[Android][Fixed] - Fix legacy arch RTL horizontal ScrollView regression
Reviewed By: rshest
Differential Revision: D65139747
fbshipit-source-id: 5662c0744c3c402efe583e602b2272662b4d5476
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47280
Noticed in the screenshots of https://github.com/facebook/react-native/pull/47230 that Android's logic of setting scroll content origin to zero, then right aligning scroll offset, won't correctly handle case where content is smaller than scrolling container. We can fix that by only resetting the origin when content overflows container, since we otherwise are not scrollable, and scroll adjustment will not translate.
Changelog:
[Android][Fixed] - Fix RTL ScrollView position when content smaller than container
Reviewed By: rshest
Differential Revision: D65136654
fbshipit-source-id: 2818ff6360cbfac64d7e57bdcbbe8c0a9b4bbb97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47284
If the surface hasn't been set up yet, attempting to fetch the ReactRootView will throw a null reference exception. Since the result is already nullable, it's perhaps better to just return null when the surface has not yet been initialized.
## Changelog
[Android][Fixed] Avoid null reference exception in bridgeless ReactDelegate
Reviewed By: javache
Differential Revision: D65141137
fbshipit-source-id: 9b002b0520a7eeea61767cb8934e9bb8d049fc6a
Summary:
## Changes
If the c++ pipeline is active:
If someone calls console.error:
- The c++ pipeline will report it as a soft error
If someone reports an error:
- The c++ pipeline will log it via console.error
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64506069
fbshipit-source-id: 293cd1774f19ee03d7eb61572b7b1f03a47a4756
Summary:
Now, all ios apps will just be integrated with the c++ error reporting pipeline, with zero configuration.
Changelog: [Internal]
Reviewed By: javache, philIip
Differential Revision: D64615457
fbshipit-source-id: db9d98115238d9a42563e39a4780234a9bc3c034
Summary:
Fixes https://github.com/facebook/react-native/issues/46908
The `justificationMode` is not set for multiline text without unicode characters with known width on both architectures. This caused the issue of drawing additional empty line at the end of `TextView` because Yoga thought that text takes 5 lines and falsely calculated it's height.
Currently, on the old architecture, the `justificationMode` is set only on text that is not boring (contains unicode characters) with unknown width. I am not sure why is that, so I am opening this as a draft for now as I am still checking if it doesn't break anything.
## 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
-->
[ANDROID] [FIXED] - fix generating empty line at the end of multiline text view when `textAlign` is set to `justify`
Pull Request resolved: https://github.com/facebook/react-native/pull/47122
Test Plan: I've tested on both architectures on repro provided in the issue.
Reviewed By: javache
Differential Revision: D65002386
Pulled By: NickGerleman
fbshipit-source-id: 0187956c88e6eb1e637c24e82b3052cc82581a64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47232
changelog: [internal]
TouchEventEmitter APIs take ownership of TouchEvent and PointerEvent, the use of const & qualifiers is misleading and may lead it unnecessary copy.
Reviewed By: rubennorte
Differential Revision: D65040506
fbshipit-source-id: 941e2eab6a057e31066751e26387604858f03e51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47265
Changelog: [iOS][Breaking]
This was originally landed before as part of the effort to coalesce configurations with the feature flag infra, but got reverted due to a build issue. I'm pretty sure it was just because the legacy configuration methods were not cleaned up from the header (RCTConstants.h). I fixed that here.
Reviewed By: javache
Differential Revision: D65092536
fbshipit-source-id: 5012ba54b0314c487f2ef488c2eb30a3c4133cb5
Summary:
This PR adds an example showcasing a TextInput whose width gets resized dynamically based on the text content width.
This example was added for this PR, which tries to address a flickering bug with dynamic sized TextInputs:
- https://github.com/facebook/react-native/pull/46973
## 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] [ADDED] Added dynamic content width TextInput example
Pull Request resolved: https://github.com/facebook/react-native/pull/46976
Test Plan:
Test in RNTester app:
https://github.com/user-attachments/assets/7571b80b-7035-47df-b840-4218ab0802b5
Reviewed By: NickGerleman
Differential Revision: D64271454
Pulled By: arushikesarwani94
fbshipit-source-id: 28fe7bd93891ffe5284340d73e9ee947654f1788
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47291
Changelog: [internal]
Small devx improvement to distinguish problems caused by calling `IntersectionObserver.observe` with null or undefined, vs. other values not supported by the API (like legacy refs).
Differential Revision: D65150750
fbshipit-source-id: b9452ff19d35ccd0dc2d47ee2d5a0e933e0ae180
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47249
- It is likely that Dialog is being dismissed from an invalid state causing an exception
- apply similar changes from D63712422 which is to add try/catch around and ignore the exception as we are dismissing the dialog anyway
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D65066186
fbshipit-source-id: 03ebbc3fec3adf6100e36ea38b43f410d98a5297
Summary:
The `XMLHttpRequest` example with a single file download doesn't seem to be working anymore. The test case is quite old so it seems like something changed in between with the example URLs.
- Changing the URL for the example. Using another file from `filesamples.com` as it's already being used in the chunk file download example as well.
- Adding an `onerror` callback as it was loading infinitely when something went wrong.
## Changelog:
[INTERNAL] [FIXED] - fixing `XMLHttpRequest` file download example
Pull Request resolved: https://github.com/facebook/react-native/pull/47152
Test Plan:
Using the `rn-tester`, see the before and after for comparison
<details>
<summary>Before and after videos</summary>
**Before**:
https://github.com/user-attachments/assets/01f89cd9-0f5e-4ddb-9ff2-c3e053be5413
**After**:
https://github.com/user-attachments/assets/59ef161c-d5ba-43e3-827e-e250cc663276
</details>
Reviewed By: cipolleschi
Differential Revision: D65126952
Pulled By: NickGerleman
fbshipit-source-id: 7a4b2187570fd85d4444bfe63ae7bc77b09af261
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47276
This dates back all the way to D4021502 and is unused by any of our modern debugger tools.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D65134285
fbshipit-source-id: 44d8bf2553b28558755e9a603b8ddc8f7dd79b20
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47279
This file is used by BUCK only and should have not been exposed in the first place.
Fixes https://github.com/facebook/react-native/issues/47223
Changelog:
[Internal] [Changed] - Move `com/facebook/react/devsupport/AndroidManifest` to Internal
Reviewed By: NickGerleman
Differential Revision: D65136247
fbshipit-source-id: 01f1e3aed55e932e842132312166b786fd39e7ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47240
Changelog: [internal]
Adding a new option for the feature flags script to print the current definitions of feature flags.
```
yarn featureflags --print
```
```
┌────────────────────────────────────────────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────┬─────────┬──────────────┐
│ (index) │ Description │ Purpose │ Date added │
├────────────────────────────────────────────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────┼─────────┼──────────────┤
│ commonTestFlag │ 'Common flag for testing. Do NOT modify.' │ '🔨' │ undefined │
│ commonTestFlagWithoutNativeImplementation │ 'Common flag for testing (without native implementation). Do NOT modify.' │ '🔨' │ undefined │
│ enableFabricLogs │ 'This feature flag enables logs for Fabric.' │ '🔨' │ undefined │
│ jsOnlyTestFlag │ 'JS-only flag for testing. Do NOT modify.' │ '🔨' │ undefined │
│ traceTurboModulePromiseRejectionsOnAndroid │ 'Enables storing js caller stack when creating promise in native module. This is useful in case of Pr...' │ '🔨' │ undefined │
│ batchRenderingUpdatesInEventLoop │ 'When enabled, the RuntimeScheduler processing the event loop will batch all rendering updates and di...' │ '🚀' │ undefined │
│ disableEventLoopOnBridgeless │ 'The bridgeless architecture enables the event loop by default. This feature flag allows us to force ...' │ '🚀' │ undefined │
│ enableAccessToHostTreeInFabric │ 'Enables access to the host tree in Fabric using DOM-compatible APIs.' │ '🚀' │ undefined │
│ enableBridgelessArchitecture │ 'Feature flag to enable the new bridgeless architecture. Note: Enabling this will force enable the fo...' │ '🚀' │ undefined │
│ enableFabricRenderer │ 'Enables the use of the Fabric renderer in the whole app.' │ '🚀' │ undefined │
│ enableFabricRendererExclusively │ 'When the app is completely migrated to Fabric, set this flag to true to disable parts of Paper infra...' │ '🚀' │ undefined │
│ enableLayoutAnimationsOnAndroid │ 'When enabled, LayoutAnimations API will animate state changes on Android.' │ '🚀' │ undefined │
│ enableLayoutAnimationsOnIOS │ 'When enabled, LayoutAnimations API will animate state changes on iOS.' │ '🚀' │ undefined │
│ enableLongTaskAPI │ 'Enables the reporting of long tasks through `PerformanceObserver`. Only works if the event loop is e...' │ '🚀' │ undefined │
│ enableMicrotasks │ 'Enables the use of microtasks in Hermes (scheduling) and RuntimeScheduler (execution).' │ '🚀' │ undefined │
│ enableReportEventPaintTime │ 'Report paint time inside the Event Timing API implementation (PerformanceObserver).' │ '🚀' │ undefined │
│ fuseboxEnabledDebug │ 'Flag determining if the React Native DevTools (Fusebox) CDP backend should be enabled in debug build...' │ '🚀' │ undefined │
│ fuseboxEnabledRelease │ 'Flag determining if the React Native DevTools (Fusebox) CDP backend should be enabled in release bui...' │ '🚀' │ undefined │
│ isLayoutAnimationEnabled │ 'Function used to enable / disabled Layout Animations in React Native.' │ '🚀' │ undefined │
│ useFabricInterop │ 'Should this application enable the Fabric Interop Layer for Android? If yes, the application will be...' │ '🚀' │ undefined │
│ useModernRuntimeScheduler │ 'When enabled, it uses the modern fork of RuntimeScheduler that allows scheduling tasks with prioriti...' │ '🚀' │ undefined │
│ useTurboModules │ 'When enabled, NativeModules will be executed by using the TurboModule system' │ '🚀' │ undefined │
│ allowRecursiveCommitsWithSynchronousMountOnAndroid │ 'Adds support for recursively processing commits that mount synchronously (Android only).' │ '🧪' │ '2024-05-30' │
│ animatedShouldDebounceQueueFlush │ 'Enables an experimental flush-queue debouncing in Animated.js.' │ '🧪' │ '2024-02-05' │
│ animatedShouldUseSingleOp │ 'Enables an experimental mega-operation for Animated.js that replaces many calls to native with a sin...' │ '🧪' │ '2024-02-05' │
│ completeReactInstanceCreationOnBgThreadOnAndroid │ 'Do not wait for a main-thread dispatch to complete init to start executing work on the JS thread on ...' │ '🧪' │ '2024-07-22' │
│ enableAlignItemsBaselineOnFabricIOS │ 'Kill-switch to turn off support for aling-items:baseline on Fabric iOS.' │ '🧪' │ '2024-07-10' │
│ enableAndroidLineHeightCentering │ 'When enabled, custom line height calculation will be centered from top to bottom.' │ '🧪' │ '2024-09-11' │
│ enableAnimatedAllowlist │ 'Enables Animated to skip non-allowlisted props and styles.' │ '🧪' │ '2024-09-10' │
│ enableAnimatedClearImmediateFix │ 'Enables an experimental to use the proper clearIntermediate instead of calling the wrong clearTimeou...' │ '🧪' │ '2024-09-17' │
│ enableAnimatedPropsMemo │ 'Enables Animated to analyze props to minimize invalidating `AnimatedProps`.' │ '🧪' │ '2024-09-11' │
│ enableCleanTextInputYogaNode │ 'Clean yoga node when <TextInput /> does not change.' │ '🧪' │ '2024-04-06' │
│ enableCppPropsIteratorSetter │ 'Enable prop iterator setter-style construction of Props in C++ (this flag is not used in Java).' │ '🧪' │ '2024-09-13' │
│ enableDeletionOfUnmountedViews │ 'Deletes views that were pre-allocated but never mounted on the screen.' │ '🧪' │ '2024-09-13' │
│ enableEagerRootViewAttachment │ 'Feature flag to configure eager attachment of the root view/initialisation of the JS code.' │ '🧪' │ '2024-07-28' │
│ enableEventEmitterRetentionDuringGesturesOnAndroid │ 'Enables the retention of EventEmitterWrapper on Android till the touch gesture is over to fix a bug ...' │ '🧪' │ '2024-08-08' │
│ enableGranularShadowTreeStateReconciliation │ 'When enabled, the renderer would only fail commits when they propagate state and the last commit tha...' │ '🧪' │ '2024-05-01' │
│ enableIOSViewClipToPaddingBox │ 'iOS Views will clip to their padding box vs border box' │ '🧪' │ '2024-08-30' │
│ enableNewBackgroundAndBorderDrawables │ 'Use BackgroundDrawable and BorderDrawable instead of CSSBackgroundDrawable' │ '🧪' │ '2024-09-24' │
│ enableOptimisedVirtualizedCells │ 'Removing unnecessary rerenders Virtualized cells after any rerenders of Virualized list. Works with ...' │ '🧪' │ '2024-08-21' │
│ enablePreciseSchedulingForPremountItemsOnAndroid │ 'Moves execution of pre-mount items to outside the choregrapher in the main thread, so we can estimat...' │ '🧪' │ '2024-09-19' │
│ enablePropsUpdateReconciliationAndroid │ 'When enabled, Android will receive prop updates based on the differences between the last rendered s...' │ '🧪' │ '2024-07-12' │
│ enableSynchronousStateUpdates │ 'Dispatches state updates synchronously in Fabric (e.g.: updates the scroll position in the shadow tr...' │ '🧪' │ '2024-04-25' │
│ enableTextPreallocationOptimisation │ 'Text preallocation optimisation where unnecessary work is removed.' │ '🧪' │ '2024-09-12' │
│ enableUIConsistency │ 'Ensures that JavaScript always has a consistent view of the state of the UI (e.g.: commits done in o...' │ '🧪' │ '2024-04-25' │
│ enableViewRecycling │ 'Enables View Recycling. When enabled, individual ViewManagers must still opt-in.' │ '🧪' │ '2024-07-31' │
│ excludeYogaFromRawProps │ 'When enabled, rawProps in Props will not include Yoga specific props.' │ '🧪' │ '2024-07-22' │
│ fixMappingOfEventPrioritiesBetweenFabricAndReact │ 'Uses the default event priority instead of the discreet event priority by default when dispatching e...' │ '🧪' │ '2024-06-18' │
│ fixMountingCoordinatorReportedPendingTransactionsOnAndroid │ 'Fixes a limitation on Android where the mounting coordinator would report there are no pending trans...' │ '🧪' │ '2024-08-27' │
│ forceBatchingMountItemsOnAndroid │ 'Forces the mounting layer on Android to always batch mount items instead of dispatching them immedia...' │ '🧪' │ '2024-04-10' │
│ initEagerTurboModulesOnNativeModulesQueueAndroid │ 'Construct modules that requires eager init on the dedicate native modules thread' │ '🧪' │ '2024-07-11' │
│ lazyAnimationCallbacks │ 'Only enqueue Choreographer calls if there is an ongoing animation, instead of enqueueing every frame...' │ '🧪' │ '2024-05-01' │
│ loadVectorDrawablesOnImages │ 'Adds support for loading vector drawable assets in the Image component (only on Android)' │ '🧪' │ '2024-07-12' │
│ scheduleAnimatedEndCallbackInMicrotask │ 'Changes the completion callback supplied via `Animation#start` to be scheduled in a microtask instea...' │ '🧪' │ '2024-09-27' │
│ setAndroidLayoutDirection │ 'Propagate layout direction to Android views.' │ '🧪' │ '2024-05-17' │
│ shouldSkipStateUpdatesForLoopingAnimations │ 'If the animation is within Animated.loop, we do not send state updates to React.' │ '🧪' │ '2024-07-25' │
│ shouldUseAnimatedObjectForTransform │ 'Enables use of AnimatedObject for animating transform values.' │ '🧪' │ '2024-02-05' │
│ shouldUseRemoveClippedSubviewsAsDefaultOnIOS │ 'removeClippedSubviews prop will be used as the default in FlatList on iOS to match Android' │ '🧪' │ '2024-02-05' │
│ shouldUseSetNativePropsInFabric │ 'Enables use of setNativeProps in JS driven animations.' │ '🧪' │ '2024-03-05' │
│ shouldUseSetNativePropsInNativeAnimationsInFabric │ 'Enables use of setNativeProps in Native driven animations in Fabric.' │ '🧪' │ '2024-03-05' │
│ useImmediateExecutorInAndroidBridgeless │ 'Invoke callbacks immediately on the ReactInstance rather than going through a background thread for ...' │ '🧪' │ '2024-06-06' │
│ useInsertionEffectsForAnimations │ 'Changes construction of the animation graph to `useInsertionEffect` instead of `useLayoutEffect`.' │ '🧪' │ '2024-09-12' │
│ useNativeViewConfigsInBridgelessMode │ 'When enabled, the native view configs are used in bridgeless mode.' │ '🧪' │ '2024-04-03' │
│ useOptimisedViewPreallocationOnAndroid │ 'Moves more of the work in view preallocation to the main thread to free up JS thread.' │ '🧪' │ '2024-07-23' │
│ useOptimizedEventBatchingOnAndroid │ 'Uses an optimized mechanism for event batching on Android that does not need to wait for a Choreogra...' │ '🧪' │ '2024-08-29' │
│ useRefsForTextInputState │ 'Enable a variant of TextInput that moves some state to refs to avoid unnecessary re-renders' │ '🧪' │ '2024-07-08' │
│ useRuntimeShadowNodeReferenceUpdate │ 'When enabled, cloning shadow nodes within react native will update the reference held by the current...' │ '🧪' │ '2024-06-03' │
│ useTurboModuleInterop │ 'In Bridgeless mode, should legacy NativeModules use the TurboModule system?' │ '🧪' │ '2024-07-28' │
└────────────────────────────────────────────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────┴─────────┴──────────────┘
Summary
┌─────────────────┬────────┐
│ (index) │ Values │
├─────────────────┼────────┤
│ Total │ 68 │
│ Common │ 51 │
│ JS Only │ 17 │
│ Operational │ 5 │
│ Release │ 17 │
│ Experimentation │ 46 │
└─────────────────┴────────┘
Done in 1.62s.
```
```
yarn featureflags --print --json
```
```
{"common":{"commonTestFlag":{"defaultValue":false,"metadata":{"description":"Common flag for testing. Do NOT modify.","purpose":"operational"}},"commonTestFlagWithoutNativeImplementation":{"defaultValue":false,"metadata":{"description":"Common flag for testing (without native implementation). Do NOT modify.","purpose":"operational"},"skipNativeAPI":true},"allowRecursiveCommitsWithSynchronousMountOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-05-30","description":"Adds support for recursively processing commits that mount synchronously (Android only).","purpose":"experimentation"}},"batchRenderingUpdatesInEventLoop":{"defaultValue":false,"metadata":{"description":"When enabled, the RuntimeScheduler processing the event loop will batch all rendering updates and dispatch them together at the end of each iteration of the loop.","purpose":"release"},"skipNativeAPI":true},"completeReactInstanceCreationOnBgThreadOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-22","description":"Do not wait for a main-thread dispatch to complete init to start executing work on the JS thread on Android","purpose":"experimentation"}},"disableEventLoopOnBridgeless":{"defaultValue":false,"metadata":{"description":"The bridgeless architecture enables the event loop by default. This feature flag allows us to force disabling it in specific instances.","purpose":"release"}},"enableAlignItemsBaselineOnFabricIOS":{"defaultValue":true,"metadata":{"dateAdded":"2024-07-10","description":"Kill-switch to turn off support for aling-items:baseline on Fabric iOS.","purpose":"experimentation"}},"enableAndroidLineHeightCentering":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-11","description":"When enabled, custom line height calculation will be centered from top to bottom.","purpose":"experimentation"}},"enableBridgelessArchitecture":{"defaultValue":false,"metadata":{"description":"Feature flag to enable the new bridgeless architecture. Note: Enabling this will force enable the following flags: `useTurboModules` & `enableFabricRenderer.","purpose":"release"}},"enableCleanTextInputYogaNode":{"defaultValue":false,"metadata":{"dateAdded":"2024-04-06","description":"Clean yoga node when <TextInput /> does not change.","purpose":"experimentation"}},"enableCppPropsIteratorSetter":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-13","description":"Enable prop iterator setter-style construction of Props in C++ (this flag is not used in Java).","purpose":"experimentation"}},"enableDeletionOfUnmountedViews":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-13","description":"Deletes views that were pre-allocated but never mounted on the screen.","purpose":"experimentation"}},"enableEagerRootViewAttachment":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-28","description":"Feature flag to configure eager attachment of the root view/initialisation of the JS code.","purpose":"experimentation"}},"enableEventEmitterRetentionDuringGesturesOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-08-08","description":"Enables the retention of EventEmitterWrapper on Android till the touch gesture is over to fix a bug on pressable (#44610)","purpose":"experimentation"}},"enableFabricLogs":{"defaultValue":false,"metadata":{"description":"This feature flag enables logs for Fabric.","purpose":"operational"}},"enableFabricRenderer":{"defaultValue":false,"metadata":{"description":"Enables the use of the Fabric renderer in the whole app.","purpose":"release"}},"enableFabricRendererExclusively":{"defaultValue":false,"metadata":{"description":"When the app is completely migrated to Fabric, set this flag to true to disable parts of Paper infrastructure that are not needed anymore but consume memory and CPU. Specifically, UIViewOperationQueue and EventDispatcherImpl will no longer work as they will not subscribe to ReactChoreographer for updates.","purpose":"release"}},"enableGranularShadowTreeStateReconciliation":{"defaultValue":false,"metadata":{"dateAdded":"2024-05-01","description":"When enabled, the renderer would only fail commits when they propagate state and the last commit that updated state changed before committing.","purpose":"experimentation"}},"enableIOSViewClipToPaddingBox":{"defaultValue":false,"metadata":{"dateAdded":"2024-08-30","description":"iOS Views will clip to their padding box vs border box","purpose":"experimentation"}},"enableLayoutAnimationsOnAndroid":{"defaultValue":false,"metadata":{"description":"When enabled, LayoutAnimations API will animate state changes on Android.","purpose":"release"}},"enableLayoutAnimationsOnIOS":{"defaultValue":true,"metadata":{"description":"When enabled, LayoutAnimations API will animate state changes on iOS.","purpose":"release"}},"enableLongTaskAPI":{"defaultValue":false,"metadata":{"description":"Enables the reporting of long tasks through `PerformanceObserver`. Only works if the event loop is enabled.","purpose":"release"}},"enableMicrotasks":{"defaultValue":false,"metadata":{"description":"Enables the use of microtasks in Hermes (scheduling) and RuntimeScheduler (execution).","purpose":"release"},"skipNativeAPI":true},"enableNewBackgroundAndBorderDrawables":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-24","description":"Use BackgroundDrawable and BorderDrawable instead of CSSBackgroundDrawable","purpose":"experimentation"}},"enablePreciseSchedulingForPremountItemsOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-19","description":"Moves execution of pre-mount items to outside the choregrapher in the main thread, so we can estimate idle time more precisely (Android only).","purpose":"experimentation"}},"enablePropsUpdateReconciliationAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-12","description":"When enabled, Android will receive prop updates based on the differences between the last rendered shadow node and the last committed shadow node.","purpose":"experimentation"}},"enableReportEventPaintTime":{"defaultValue":false,"metadata":{"description":"Report paint time inside the Event Timing API implementation (PerformanceObserver).","purpose":"release"}},"enableSynchronousStateUpdates":{"defaultValue":false,"metadata":{"dateAdded":"2024-04-25","description":"Dispatches state updates synchronously in Fabric (e.g.: updates the scroll position in the shadow tree synchronously from the main thread).","purpose":"experimentation"}},"enableTextPreallocationOptimisation":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-12","description":"Text preallocation optimisation where unnecessary work is removed.","purpose":"experimentation"}},"enableUIConsistency":{"defaultValue":false,"metadata":{"dateAdded":"2024-04-25","description":"Ensures that JavaScript always has a consistent view of the state of the UI (e.g.: commits done in other threads are not immediately propagated to JS during its execution).","purpose":"experimentation"}},"enableViewRecycling":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-31","description":"Enables View Recycling. When enabled, individual ViewManagers must still opt-in.","purpose":"experimentation"}},"excludeYogaFromRawProps":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-22","description":"When enabled, rawProps in Props will not include Yoga specific props.","purpose":"experimentation"}},"fixMappingOfEventPrioritiesBetweenFabricAndReact":{"defaultValue":false,"metadata":{"dateAdded":"2024-06-18","description":"Uses the default event priority instead of the discreet event priority by default when dispatching events from Fabric to React.","purpose":"experimentation"}},"fixMountingCoordinatorReportedPendingTransactionsOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-08-27","description":"Fixes a limitation on Android where the mounting coordinator would report there are no pending transactions but some of them were actually not processed due to the use of the push model.","purpose":"experimentation"}},"forceBatchingMountItemsOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-04-10","description":"Forces the mounting layer on Android to always batch mount items instead of dispatching them immediately. This might fix some crashes related to synchronous state updates, where some views dispatch state updates during mount.","purpose":"experimentation"}},"fuseboxEnabledDebug":{"defaultValue":true,"metadata":{"description":"Flag determining if the React Native DevTools (Fusebox) CDP backend should be enabled in debug builds. This flag is global and should not be changed across React Host lifetimes.","purpose":"release"}},"fuseboxEnabledRelease":{"defaultValue":false,"metadata":{"description":"Flag determining if the React Native DevTools (Fusebox) CDP backend should be enabled in release builds. This flag is global and should not be changed across React Host lifetimes.","purpose":"release"}},"initEagerTurboModulesOnNativeModulesQueueAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-11","description":"Construct modules that requires eager init on the dedicate native modules thread","purpose":"experimentation"}},"lazyAnimationCallbacks":{"defaultValue":false,"metadata":{"dateAdded":"2024-05-01","description":"Only enqueue Choreographer calls if there is an ongoing animation, instead of enqueueing every frame.","purpose":"experimentation"}},"loadVectorDrawablesOnImages":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-12","description":"Adds support for loading vector drawable assets in the Image component (only on Android)","purpose":"experimentation"}},"setAndroidLayoutDirection":{"defaultValue":true,"metadata":{"dateAdded":"2024-05-17","description":"Propagate layout direction to Android views.","purpose":"experimentation"}},"traceTurboModulePromiseRejectionsOnAndroid":{"defaultValue":false,"metadata":{"description":"Enables storing js caller stack when creating promise in native module. This is useful in case of Promise rejection and tracing the cause.","purpose":"operational"}},"useFabricInterop":{"defaultValue":false,"metadata":{"description":"Should this application enable the Fabric Interop Layer for Android? If yes, the application will behave so that it can accept non-Fabric components and render them on Fabric. This toggle is controlling extra logic such as custom event dispatching that are needed for the Fabric Interop Layer to work correctly.","purpose":"release"}},"useImmediateExecutorInAndroidBridgeless":{"defaultValue":false,"metadata":{"dateAdded":"2024-06-06","description":"Invoke callbacks immediately on the ReactInstance rather than going through a background thread for synchronization","purpose":"experimentation"}},"useModernRuntimeScheduler":{"defaultValue":false,"metadata":{"description":"When enabled, it uses the modern fork of RuntimeScheduler that allows scheduling tasks with priorities from any thread.","purpose":"release"},"skipNativeAPI":true},"useNativeViewConfigsInBridgelessMode":{"defaultValue":false,"metadata":{"dateAdded":"2024-04-03","description":"When enabled, the native view configs are used in bridgeless mode.","purpose":"experimentation"}},"useOptimisedViewPreallocationOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-23","description":"Moves more of the work in view preallocation to the main thread to free up JS thread.","purpose":"experimentation"}},"useOptimizedEventBatchingOnAndroid":{"defaultValue":false,"metadata":{"dateAdded":"2024-08-29","description":"Uses an optimized mechanism for event batching on Android that does not need to wait for a Choreographer frame callback.","purpose":"experimentation"}},"useRuntimeShadowNodeReferenceUpdate":{"defaultValue":false,"metadata":{"dateAdded":"2024-06-03","description":"When enabled, cloning shadow nodes within react native will update the reference held by the current JS fiber tree.","purpose":"experimentation"}},"useTurboModuleInterop":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-28","description":"In Bridgeless mode, should legacy NativeModules use the TurboModule system?","purpose":"experimentation"}},"useTurboModules":{"defaultValue":false,"metadata":{"description":"When enabled, NativeModules will be executed by using the TurboModule system","purpose":"release"}}},"jsOnly":{"jsOnlyTestFlag":{"defaultValue":false,"metadata":{"description":"JS-only flag for testing. Do NOT modify.","purpose":"operational"}},"animatedShouldDebounceQueueFlush":{"defaultValue":false,"metadata":{"dateAdded":"2024-02-05","description":"Enables an experimental flush-queue debouncing in Animated.js.","purpose":"experimentation"}},"animatedShouldUseSingleOp":{"defaultValue":false,"metadata":{"dateAdded":"2024-02-05","description":"Enables an experimental mega-operation for Animated.js that replaces many calls to native with a single call into native, to reduce JSI/JNI traffic.","purpose":"experimentation"}},"enableAccessToHostTreeInFabric":{"defaultValue":false,"metadata":{"description":"Enables access to the host tree in Fabric using DOM-compatible APIs.","purpose":"release"}},"enableAnimatedAllowlist":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-10","description":"Enables Animated to skip non-allowlisted props and styles.","purpose":"experimentation"}},"enableAnimatedClearImmediateFix":{"defaultValue":true,"metadata":{"dateAdded":"2024-09-17","description":"Enables an experimental to use the proper clearIntermediate instead of calling the wrong clearTimeout and canceling another timer.","purpose":"experimentation"}},"enableAnimatedPropsMemo":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-11","description":"Enables Animated to analyze props to minimize invalidating `AnimatedProps`.","purpose":"experimentation"}},"enableOptimisedVirtualizedCells":{"defaultValue":false,"metadata":{"dateAdded":"2024-08-21","description":"Removing unnecessary rerenders Virtualized cells after any rerenders of Virualized list. Works with strict=true option","purpose":"experimentation"}},"isLayoutAnimationEnabled":{"defaultValue":true,"metadata":{"description":"Function used to enable / disabled Layout Animations in React Native.","purpose":"release"}},"scheduleAnimatedEndCallbackInMicrotask":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-27","description":"Changes the completion callback supplied via `Animation#start` to be scheduled in a microtask instead of synchronously executed.","purpose":"experimentation"}},"shouldSkipStateUpdatesForLoopingAnimations":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-25","description":"If the animation is within Animated.loop, we do not send state updates to React.","purpose":"experimentation"}},"shouldUseAnimatedObjectForTransform":{"defaultValue":false,"metadata":{"dateAdded":"2024-02-05","description":"Enables use of AnimatedObject for animating transform values.","purpose":"experimentation"}},"shouldUseRemoveClippedSubviewsAsDefaultOnIOS":{"defaultValue":false,"metadata":{"dateAdded":"2024-02-05","description":"removeClippedSubviews prop will be used as the default in FlatList on iOS to match Android","purpose":"experimentation"}},"shouldUseSetNativePropsInFabric":{"defaultValue":true,"metadata":{"dateAdded":"2024-03-05","description":"Enables use of setNativeProps in JS driven animations.","purpose":"experimentation"}},"shouldUseSetNativePropsInNativeAnimationsInFabric":{"defaultValue":false,"metadata":{"dateAdded":"2024-03-05","description":"Enables use of setNativeProps in Native driven animations in Fabric.","purpose":"experimentation"}},"useInsertionEffectsForAnimations":{"defaultValue":false,"metadata":{"dateAdded":"2024-09-12","description":"Changes construction of the animation graph to `useInsertionEffect` instead of `useLayoutEffect`.","purpose":"experimentation"}},"useRefsForTextInputState":{"defaultValue":false,"metadata":{"dateAdded":"2024-07-08","description":"Enable a variant of TextInput that moves some state to refs to avoid unnecessary re-renders","purpose":"experimentation"}}}}
```
Reviewed By: mdvacca
Differential Revision: D64406244
fbshipit-source-id: 6f82da64d1212faf6d5a82862a71fbc1d168134b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47239
Changelog: [internal]
Small refactor of the types for feature flags in JS to make objects read-only.
Reviewed By: mdvacca
Differential Revision: D65058612
fbshipit-source-id: 0d72df2f4afebf0426b9ac76a8f8b195c74fea52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47208
Changelog: [internal]
Small change to unify the yarn commands for feature flags into a single `featureflags` command with options.
Reviewed By: NickGerleman, mdvacca
Differential Revision: D64982509
fbshipit-source-id: 3f9d7ac35f61950bd03fef243e1a95625144a0cd
Summary:
Far as i can see it, this is the last direct reference to how we used to get windows before the introduction of scenes. Everything now uses the new Scenes system (potentially we could start adding a `RCTSceneDelegate` if we ever want to move in that direction)
I also threw in a nullability check. Theoretically, that shouldn't happen, but honestly, who knows what platform will come in the future, better safe than sorry. Let me know if you think i should remove it
## Changelog:
[INTERNAL] [FIXED] - Potentially Migrate the last `KeyWindow` usage to `RCTKeyWindow` instead of tapping to the `UIWindow` directly via RCTSharedApplication
Pull Request resolved: https://github.com/facebook/react-native/pull/47220
Test Plan:
yarn test:
<img width="1784" alt="Screenshot 2024-10-26 at 23 48 22" src="https://github.com/user-attachments/assets/3c0c6b2b-6aa1-4e7a-b663-327a363e4de6">
iOS test: Sadly it seems like it is still broken on Xcode 16 on my machine. Will leave it up to the CI to test it. I can see that there are more that are potentially broken. Might try to take a look and see if i can fix it in another PR.
<img width="1840" alt="Screenshot 2024-10-26 at 23 53 47" src="https://github.com/user-attachments/assets/2e302aee-bc57-41fe-baf3-0292dc65485e">
Reviewed By: philIip
Differential Revision: D65057289
Pulled By: cipolleschi
fbshipit-source-id: a5b2e875e681120a54e57ede90d67e66e9376a56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47269
There were [reports](https://github.com/reactwg/react-native-releases/issues/595) that patching in the fixes for iOS controlled input did not work as expected.
I think tracked this down to a difference in how I tested, where the controlled component I used passed value as a child of the `TextInput`, instead of via `value`. Passing via `value` triggers a secondary bug, where we don't correctly pass a reference to correct ShadowView when creating attributedstring, specifically in the iOS TextInputShadowNode impl.
We previously passed nothing for the ShadowView (only the first two struct fields). This was exposed in D52589303 which enabled `-Wextra`, but there, I went with same behavior of passing empty ShadowView, instead of the correct behavior (like Android impl) of passing a ShadowView of the current ShadowNode.
After fixing this, we now correctly create event emitters in the passed attributedstring, which matches expectations for pargraph-level eventemitter now in typing attributes. We don't seem actually use this on iOS for TextInput right now (just Text), but this is likely the right foundation for events regardless.
Changelog:
[iOS][Fixed] - Fix missing emitter attributes on iOS TextInput when controlled component value specified using `value` instead of `children`
Reviewed By: cipolleschi
Differential Revision: D65108163
fbshipit-source-id: 499fe28439fabd2579eca6ded7fd13fd8ea2e43e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47253
changelog: [internal]
Add assert statements to make sure EventBeat and Scheduler classes are correctly setup.
Scheduler must receive RuntimeScheduler through ContextContainer.
Callers of EventBeat must set beatCallback before calling request.
Reviewed By: javache
Differential Revision: D65001802
fbshipit-source-id: 5e044e1e6b0249bc89c11cccd51801add2e85b88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47229
Adding a test case for an enum value in a fromNative position
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D65038107
fbshipit-source-id: ed323d9a8b226be3ff571c86fda617cabc17cdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47206
Share definition of `SubmitBehavior` enum on ios, and use it on android
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64718150
fbshipit-source-id: a078c9be44c625cc5e9001e4ae25d32eaaf5d8e4
Summary:
This step called an old reference, this function identifier was updated.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47243
Reviewed By: cipolleschi
Differential Revision: D65063054
Pulled By: blakef
fbshipit-source-id: 640a4c501818c9b83cebb27c89ba6efd82800be8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46702
In https://github.com/facebook/react-native/pull/44188, we've started combining multiple transactions in a single transaction, to meet React's atomicity requirements, while also dealing with the constraints of Android's Fabric implementation.
This revealed a bug where in some scenarios (especially when using transitions), a node may be deleted and created during the same transaction. The current implementation of FabricMountingManager assumes it can safely reorder some operations, which it does to optimize the size of IntBufferBatch mount items. This is however incorrect and unsafe when multiple transactions are merged.
**Example:**
Differentiator output:
```
# Transaction 1
Remove #100 from #11
Delete #100
# Transaction 2
Create #100
Insert #100 into #11
```
FabricMountingManager output
```
Remove #100 from #11
Insert #100 into #11
Delete #100
```
Note that the create action is also skipped, because we only update `allocatedViewTags` after processing all mutations, leading FabricMountingManager to assume creation is not required.
This leads to an invalid state in SurfaceMountingManager, which will be surfaced as a crash in `getViewState` on the next mutation that interacts with these views.
Changelog: [Android][Fixed] Fix crash in getViewState when using suspense fallbacks.
Reviewed By: sammy-SC
Differential Revision: D63148523
fbshipit-source-id: 07ae26b2f7b7eba1b9784041dd3059b0956c035e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47196
changelog: [internal]
EventBeat can use RuntimeScheduler directly, no need to go through RuntimeExecutor.
Reviewed By: christophpurrer
Differential Revision: D64927936
fbshipit-source-id: 9fb317d7c98da588d3438424ab9923dc0c0259c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47237
The Xcodeproj gem has been released yesterday to version 1.26.0 and it broke the CI pipeline of react native.
This should fix the issue
## Changelog
[Internal] - Pin Xcodeproj gem to 1.26.0
Reviewed By: blakef
Differential Revision: D65057797
fbshipit-source-id: f4035a1d3c75dd4140eb1646ab2aa0ccb08fb16b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47219
We received reports that textTransform does not correctly match the web behaviour for capitalize, eg. capitalized characters should not be lowercased when using `capitalize`.
Example input: 'hello WORLD', should become 'Hello WORLD'.
Changelog: [General][Fixed] TextTransform: capitalize better reflects the web behaviour
Reviewed By: NickGerleman
Differential Revision: D65023821
fbshipit-source-id: 8ba5fdbd7afb1460193bf82a2f4021c3aff2110a
Summary:
Adds unit tests that directly cover the order in which `LayoutableChildren` iterator goes over the descendant nodes. The covered cases are as follows (nodes with `display: contents` are marked green):
### Single `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
B --> D((D))
B --> E((E))
style B fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, D, E, C`
### Multiple `display: contents` nodes
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
A --> D((D))
A --> E((E))
B --> F((F))
B --> G((G))
C --> H((H))
C --> I((I))
style A fill:https://github.com/facebook/yoga/issues/090
style B fill:https://github.com/facebook/yoga/issues/090
style C fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `D, E, F, G, H, I`
### Nested `display: contents` nodes
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
B --> D((D))
B --> E((E))
E --> F((F))
E --> G((G))
style B fill:https://github.com/facebook/yoga/issues/090
style E fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, D, F, G, C`
### Leaf `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
style B fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, C`
### Root `display: contents` node
```mermaid
flowchart TD
R((R)) --> A((A))
R --> B((B))
R --> C((C))
style R fill:https://github.com/facebook/yoga/issues/090
```
Correct order: `A, B, C` - `LayoutableChildren` goes over the children with `display: contents` property, setting it on the root node should have no effect.
Changelog: [Internal]
X-link: https://github.com/facebook/yoga/pull/1731
Reviewed By: joevilches
Differential Revision: D64981779
Pulled By: NickGerleman
fbshipit-source-id: ee39759c663a40f96ad313f1b775d53ab68fb442
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47194
Fixes a case where a node with `display: contents` would not be cleaned up in some cases. This was caused by it being called after some early returns handling different quick paths. This PR moves the call to `cleanupContentsNodesRecursively` earlier so that it's always called.
The problem here wasn't mutating before cloning, but leaving a node marked as dirty after the layout has finished.
The exact case in which I found this was a node with a single `display: contents` child which needs to be a leaf. Then in the parent node [this](https://github.com/facebook/yoga/blob/b0b842d5e75d041e3af7e0ac55abfb8929fbbf21/yoga/algorithm/CalculateLayout.cpp#L1339) condition is true, so `cleanupContentsNodesRecursively` doesn't get called and the child node is never visited and cleaned. I assume the same will happen in the other paths with an early return here.
Changelog:
[General][Fixed] - Fix for nodes with `display: contents` not being cleaned in some cases
X-link: https://github.com/facebook/yoga/pull/1729
Reviewed By: rozele
Differential Revision: D64910099
Pulled By: NickGerleman
fbshipit-source-id: 6d56f8fbf687b7ee5af889c0b868406213c9cee8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47167
I couldn't find any usages of this method in javascript.
Removing, so that the native code is easier to read.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64606928
fbshipit-source-id: 1d52d58437370ae3d99e9c44500080687f137191
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47165
The c++ pipeline needs a javascript interface.
We could just re-use exceptions manager (for now).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64779068
fbshipit-source-id: 4e300668a01fa22e194ea9f149ef1d936d5e0834
Summary:
Now, handleError can be called with a JSError that wraps a non-error object!
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D64706198
fbshipit-source-id: 562ed7d4e2a13eaef48acfdf3499296462e54166
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45626
I'm deleting CoreFeatures class and all its imports because it was fully replaced by ReactNativeFeatureFlags
Changelog: [Internal][Removed] Delete CoreFeatures class in favor of ReactNativeFeatureFlags
Reviewed By: rubennorte
Differential Revision: D60137380
fbshipit-source-id: 8bf918cdd1ce66e315aa95e1c5a28879445ff9f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47179
In this diff I'm exposing the new parameter (JSBundleLoader) as parameter of DefaultReactHost.
changelog: [Android][Breaking] Added JSBundleLoader as parameter of DefaultReactHost
Reviewed By: cortinico
Differential Revision: D64381501
fbshipit-source-id: dd0d56441802f7db53c67c659bbcae63c4b1b613
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47128
Delete CompositeReactPackage from RN, these classes were deprecated for a long time and they can be deleted now, there are no internal usages
changelog: [Android][Breaking] Deleting deprecated CompositeReactPackage
Reviewed By: cortinico
Differential Revision: D64382211
fbshipit-source-id: d4fdfd51177612a64dde918cd68d6e852ef1b0e2
Summary:
Saw this while going through the remaining warnings of the project. I double checked, and i can't find any other usages left behind, so this is probably the last one
## Changelog:
[INTERNAL] [FIXED] - Switch to using the new sendString method for Websocket
Pull Request resolved: https://github.com/facebook/react-native/pull/47197
Test Plan:
yarn test:
<img width="933" alt="Screenshot 2024-10-25 at 00 55 58" src="https://github.com/user-attachments/assets/dbfebb90-4957-4fc9-8a90-153c03055ac9">
Running the tests in Xcode with `CMD+U` or the objc-test: I could not get it to pass in either the old code or the modified code. I know the test documentation said it needs a WebSocket, but it was a bit too vague , and even turning metro on did not help, so i have no idea how to test it. If anyone can guide me on that one, please let me know
Reviewed By: blakef
Differential Revision: D64934981
Pulled By: cipolleschi
fbshipit-source-id: c6f13d3da5aafe3eed8b99b98f04904fcdcc4115
Summary:
Danger seems to have a bug where it's not transpiling the import of
rnx-kit/rn-changelog-generator. This mitigates the issue to get our
project back on track.
This can be replicated locally by:
```bash
DEBUG="*" DANGER_GITHUB_API_TOKEN=$GITHUB_TOKEN yarn danger pr https://github.com/facebook/react-native/pull/47182
```
You can see it running correctly here when switching to the branch with the fix. **I'm a little concerned that this is still failing on the PR**. Thoughts?
{F1946190275}
Changelog: [internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47192
Reviewed By: cortinico
Differential Revision: D64924466
Pulled By: blakef
fbshipit-source-id: 68df0521620809effe3a78ce842e043382ad64a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47195
When a user wants to create a Fabric Component i their app (not in a separate library) the app fails to build because:
- The custom component has to inherit from `RCTViewComponentView`
- `RCTViewComponentView` imports `ViewProps.h`
- `ViewProps.h` imports `HostPlatformViewProps.h`
- `HostPlatformViewProps.h` imports `BaseViewProps.h`
- `BaseViewProps.h` imports `YogaStylableProps.h`
which is a Yoga private header and the App has not visibility over it.
It is also not possible to fix this issue with forward declaring the `YogaStylableProps`, because `BaseViewProps` inherit from the yoga's props, so the compiler needs the full declaration of `YogaStylableProps` to work
This needs to be picked in 0.76
## Changelog
[iOS][Fixed] - Give apps access to Yoga headers
Reviewed By: blakef
Differential Revision: D64925222
fbshipit-source-id: e724076bbfb0a678948340dfab2ce609e6509533
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47176
While writing the guide for the New Architecture, we realized that we need to exclude the generation of the Cls function in the RCTThirdPartyFabricComponentsProvider for components defined in the app.
This is needed because a component that is defined in the app will have those function defined in the app project. However, the RCTThirdPartyFabricComponentsProvider is generated in Fabric, inside the Pods project.
The pod project needs to build in isolation from the app and cocoapods then link the app to the pods project. But the compilation of the pods project fails if one of the symbol needed by the pods lives in the app.
By disabling the generation of that function in th RCTThirdPartyFabricComponentsProvider, we can successfully build the app.
The downside is that the user needs to register the component manually, but this is not an issue because if they are writing a component in the app space, they have all the information tomanually register it in the AppDelegate
## Changelog
[iOS][Fixed] - Do not generate the ComponentCls function in the RCTThirdPartyFabricComponentsProvider for components deined in the app.
Reviewed By: cortinico, blakef
Differential Revision: D64739896
fbshipit-source-id: 0eca818ea0198532a611377d14a3ff4c95cb5fe3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47147
By batching sync events if multiple events are dispatched during sync rendering this will reduce the number of re-renders.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64287526
fbshipit-source-id: a5dc3b643ef1853bef9e38ce8c2f5db75e02214b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47146
This will allows us to batch sync events which leads to better performance.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D64631346
fbshipit-source-id: b82dca150c13bdb7acae6bedb392a93993273988
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47163
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces final few in libdefs.
Changelog: [internal]
Reviewed By: alexmckenley
Differential Revision: D64776942
fbshipit-source-id: 5e96c6d4fecb1b6cf539a00aecb10b9b35fc140b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47119
# Changelog:
[General] [Fixed] - Microtasks are now correctly executed after the code evaluation in Console panel of DevTools.
Fixes https://github.com/facebook/react-native/issues/46966.
`runtimeExecutor` which is propagated here, is actually being used by Hermes:
https://www.internalfb.com/code/fbsource/[cba75f2b515a]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/runtime/ReactInstance.cpp?lines=112-113
The issue was that any expression that should be evaluated as part of `Runtime.evaluate` was not going through `RuntimeScheduler`, because specified `runtimeExecutor` was not going through it as well, and it was defined prior to `RuntimeScheduler`. Because of this, `RuntimeScheduler` was not draining out the microtasks queue and basically any scheduled Microtasks were not executed, see T200616136.
With this fix, we create an executor that goes through `RuntimeScheduler`, which is using another executor that makes sure that all scheduled callbacks are only executed after `Inspector` was setup.
It is extremely messy and in the future we should untangle these circular dependencies and try to simplify the approach.
Reviewed By: rubennorte
Differential Revision: D64552372
fbshipit-source-id: 467d37c71a2eb7c940297ce90ca8d68268b1ff33
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47124
With this we start the experiment to analyze the effect of the new `BackgroundDrawable.kt` and `BorderDrawable.kt` classes. This is also essentially a kotlinification of `CSSBackgroundDrawable`
We also start using CompositeBackgroundDrawable as the source of truth for **borderRadius** and **borderInsets**
We are hoping to get neutral results and a general win for code readability.
In general when the FeatureFlag passes we should not generate a CSSBackgroundDrawable at all and just use BackgroundDrawable and BorderDrawable
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63287222
fbshipit-source-id: 7ca98290c2e152b22d09b838e5f0e1cac97b1268
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46745
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62898246
fbshipit-source-id: 15d1a4ef61f0c757e648c002fc7ef26626d8e3f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46709
**Note:** This diff still does nothing yet, it will be enabled on a diff further up the stack. This split is just to simplify reviewing
`CSSBackgroundDrawable` holds the drawing logic for both **Borders** and **Background**. This is not ideal since it results in a huge file which does 2 things.
We now have `CompositeBackgroundDrawable` which allows us to set a different drawable per "layer" on our view.
By splitting up **Border** and **Background** logic we get better modularity and it'll make it easier to implement more `backgroundImage` features without further bloating the `CSSBackgroundDrawable` file
Also, this helps with the kotlinification efforts
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63137921
fbshipit-source-id: fc459beadfda1832e146e36d74c3d424a28ca905
Summary:
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn test --debug --watch TestName`,
open `chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
In order to adopt react 19's ref-as-prop model, Flow needs to eliminate
all the places where they are treated differently.
`React.AbstractComponent` is the worst example of this, and we need to
eliminate it.
This PR eliminates them from the react repo, and only keeps the one that
has 1 argument of props.
## How did you test this change?
yarn flow
DiffTrain build for [45804af18d589fd2c181f3b020f07661c46b73ea](https://github.com/facebook/react/commit/45804af18d589fd2c181f3b020f07661c46b73ea)
Reviewed By: jbrown215
Differential Revision: D64725736
Pulled By: SamChou19815
fbshipit-source-id: c9f6f316c95d12a9ae98926faba111395b550ccf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47141
D64152004 fixed a soundness hole in Flow's checking of frozen object types (e.g. try-Flow https://fburl.com/rmct2mf6). This diff suppresses Flow errors that appear when this fix is enabled (`experimental.object_freeze_fix` flag is set).
For most of these cases the result of `Object.freeze()` is assigned to some variable typed as a mutable type. The variable is then passed to a context where its fields can be written to. Thus changing the annotation type to a readonly version would only cause more errors downstream. So, instead, these assignments are suppressed so that the choice of using Object.freeze can be revisited.
Changelog: [internal]
Reviewed By: SamChou19815
Differential Revision: D64699992
fbshipit-source-id: 48e4376d4ed3dbda21d32cabe512e6457384994f
Summary:
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces 2 more remaining ones in react-native. Now the only remaining one is the one synced from react repo.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722899
fbshipit-source-id: 2b2484c385fc5d6c173253f9bee66dfc736368a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47150
In https://github.com/facebook/react/pull/31314, I will change the host component type that will be synced to react-native. Notably, it will expose the issue where all the `HostComponent<mixed>` types are wrong, since it doesn't make sense to write `React.AbstractComponent<mixed>`. This diff fixes the existing usages first in prep for that typing change.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64722939
fbshipit-source-id: 14e1477090128205d8be8fc7b135a8478f94b790
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47143
In order to adopt react 19's ref-as-prop model, we need to eliminate all the places where they are treated differently. `React.AbstractComponent` is the worst example of this, and we need to eliminate it.
This diff replaces most of the remaining `React.AbstractComponent` in react-native.
Changelog: [Internal]
Reviewed By: alexmckenley
Differential Revision: D64701145
fbshipit-source-id: c765674fdf59812895c4fae43df97cf8b9d24f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47121
This class should be internal. I've verified this API is not used in OSS so this is technically breaking but not really affecting anyone in OSS.
Changelog:
[Android] [Breaking] - Stable API - Make AppStateModule internal
Reviewed By: Abbondanzo
Differential Revision: D64598660
fbshipit-source-id: aebc385c741e2e1f352d473db2be87d918f0ef65
Summary:
While working on https://github.com/facebook/react-native/pull/47110, I wanted to disable fabric in the `rn-tester` to test some things in Paper. I followed all the steps but ended up deleting the whole repository locally, cloning it again and explicitly installing the pods `fabric_enabled` in all steps and it didn't work. I ended up disabling the new architecture by passing `RCT_NEW_ARCH_ENABLED=0` and then it worked immediately.
Wanted to add this extra hint as it might help other contributors.
## Changelog:
[INTERNAL] [ADDED] - extra instructions to disable fabric in the `rn-tester` package
Pull Request resolved: https://github.com/facebook/react-native/pull/47127
Test Plan: Follow the instructions to disable fabric, try passing `RCT_NEW_ARCH_ENABLED=0` if `fabric_enabled = false` is not enough.
Reviewed By: cortinico
Differential Revision: D64652149
Pulled By: rshest
fbshipit-source-id: 0fc4149832a7973c57161b4fff5815414f304a3c
Summary:
Was working on something, saw that CanvasUtils has some unused imports. Figured i'd send a PR to clean up.
## Changelog:
[INTERNAL] [FIXED] - Cleanup CanvasUtils imports
Pull Request resolved: https://github.com/facebook/react-native/pull/47132
Test Plan:
Ran yarn test:
<img width="513" alt="Screenshot 2024-10-19 at 22 54 13" src="https://github.com/user-attachments/assets/6ca86852-cab5-425a-b71c-785c7d1ea95e">
Also tried running ./gradlew test, but it appears it is not having fun with my Node version (18.20.3), so `createBundleHermesReleaseJsAndAssets` randomly fails, to be investigated why:
<img width="1515" alt="Screenshot 2024-10-19 at 22 56 02" src="https://github.com/user-attachments/assets/f860cdc5-4f42-4d54-9497-7eaa028b6bc6">
Reviewed By: NickGerleman
Differential Revision: D64663918
Pulled By: cortinico
fbshipit-source-id: a681d6ee76dfcbc56889e76da6cf8ea11907bdf2
Summary:
This PR adds support for `display: contents` style by effectively skipping nodes with `display: contents` set during layout.
This required changes in the logic related to children traversal - before this PR a node would be always laid out in the context of its direct parent. After this PR that assumption is no longer true - `display: contents` allows nodes to be skipped, i.e.:
```html
<div id="node1">
<div id="node2" style="display: contents;">
<div id="node3" />
</div>
</div>
```
`node3` will be laid out as if it were a child of `node1`.
Because of this, iterating over direct children of a node is no longer correct to achieve the correct layout. This PR introduces `LayoutableChildren::Iterator` which can traverse the subtree of a given node in a way that nodes with `display: contents` are replaced with their concrete children.
A tree like this:
```mermaid
flowchart TD
A((A))
B((B))
C((C))
D((D))
E((E))
F((F))
G((G))
H((H))
I((I))
J((J))
A --> B
A --> C
B --> D
B --> E
C --> F
D --> G
F --> H
G --> I
H --> J
style B fill:https://github.com/facebook/react-native/issues/050
style C fill:https://github.com/facebook/react-native/issues/050
style D fill:https://github.com/facebook/react-native/issues/050
style H fill:https://github.com/facebook/react-native/issues/050
style I fill:https://github.com/facebook/react-native/issues/050
```
would be laid out as if the green nodes (ones with `display: contents`) did not exist. It also changes the logic where children were accessed by index to use the iterator instead as random access would be non-trivial to implement and it's not really necessary - the iteration was always sequential and indices were only used as boundaries.
There's one place where knowledge of layoutable children is required to calculate the gap. An optimization for this is for a node to keep a counter of how many `display: contents` nodes are its children. If there are none, a short path of just returning the size of the children vector can be taken, otherwise it needs to iterate over layoutable children and count them, since the structure may be complex.
One more major change this PR introduces is `cleanupContentsNodesRecursively`. Since nodes with `display: contents` would be entirely skipped during the layout pass, they would keep previous metrics, would be kept as dirty, and, in the case of nested `contents` nodes, would not be cloned, breaking `doesOwn` relation. All of this is handled in the new method which clones `contents` nodes recursively, sets empty layout, and marks them as clean and having a new layout so that it can be used on the React Native side.
Relies on https://github.com/facebook/yoga/pull/1725
X-link: https://github.com/facebook/yoga/pull/1726
This PR adds a few things over the corresponding one in Yoga:
- new value in the `DisplayType` enum - `Contents`
- new `ShadowNodeTrait` - `ForceFlattenView`, that forces the node not to form a host view
- updates TS types to include `display: contents`
- aliases `display: contents` to `display: none` on the old architecture
## Changelog:
[GENERAL] [ADDED] - Added support for `display: contents`
Pull Request resolved: https://github.com/facebook/react-native/pull/46584
Test Plan:
<details>
<summary>So far I've been testing on relatively simple snippets like this one and on entirety of RNTester by inserting views with `display: contents` in random places and seeing if anything breaks.</summary>
```jsx
import React from 'react';
import { Button, Pressable, SafeAreaView, ScrollView, TextInput, View, Text } from 'react-native';
export default function App() {
const [toggle, setToggle] = React.useState(false);
return (
<View style={{flex: 1, paddingTop: 100}}>
<SafeAreaView style={{width: '100%', height: 200}}>
<Pressable style={{width: 100, height: 100, backgroundColor: 'black'}} onPress={() => setToggle(!toggle)}>
<ScrollView />
</Pressable>
<View style={{display: 'flex', flexDirection: 'row', flex: 1, backgroundColor: 'magenta'}}>
<SafeAreaView style={{
// display: 'contents',
flex: 1,
}}>
<View style={{
display: 'contents',
width: '100%',
height: 200,
}}>
<View style={{
display: 'contents',
flex: 1,
}}>
{ toggle && <View style={{flex: 1, backgroundColor: 'yellow'}} /> }
<View style={{flex: 1, backgroundColor: 'blue'}} />
<View style={{flex: 1, backgroundColor: 'cyan'}} />
</View>
</View>
</SafeAreaView>
</View>
{/* <View style={{width: 100, height: 100, backgroundColor: 'magenta', display: 'flex'}} /> */}
<TextInput style={{width: 200, height: 100, backgroundColor: 'red', display: 'flex'}}>
<Text style={{color: 'white'}}>Hello</Text>
<Text style={{color: 'green'}}>World</Text>
</TextInput>
</SafeAreaView>
</View>
);
}
```
</details>
Reviewed By: joevilches
Differential Revision: D64584476
Pulled By: NickGerleman
fbshipit-source-id: bec77b5087ff95f0980cf02274fbb2c8581eb3c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47035
This PR adds support for `display: contents` style by effectively skipping nodes with `display: contents` set during layout.
This required changes in the logic related to children traversal - before this PR a node would be always laid out in the context of its direct parent. After this PR that assumption is no longer true - `display: contents` allows nodes to be skipped, i.e.:
```html
<div id="node1">
<div id="node2" style="display: contents;">
<div id="node3" />
</div>
</div>
```
`node3` will be laid out as if it were a child of `node1`.
Because of this, iterating over direct children of a node is no longer correct to achieve the correct layout. This PR introduces `LayoutableChildren::Iterator` which can traverse the subtree of a given node in a way that nodes with `display: contents` are replaced with their concrete children.
A tree like this:
```mermaid
flowchart TD
A((A))
B((B))
C((C))
D((D))
E((E))
F((F))
G((G))
H((H))
I((I))
J((J))
A --> B
A --> C
B --> D
B --> E
C --> F
D --> G
F --> H
G --> I
H --> J
style B fill:https://github.com/facebook/yoga/issues/050
style C fill:https://github.com/facebook/yoga/issues/050
style D fill:https://github.com/facebook/yoga/issues/050
style H fill:https://github.com/facebook/yoga/issues/050
style I fill:https://github.com/facebook/yoga/issues/050
```
would be laid out as if the green nodes (ones with `display: contents`) did not exist. It also changes the logic where children were accessed by index to use the iterator instead as random access would be non-trivial to implement and it's not really necessary - the iteration was always sequential and indices were only used as boundaries.
There's one place where knowledge of layoutable children is required to calculate the gap. An optimization for this is for a node to keep a counter of how many `display: contents` nodes are its children. If there are none, a short path of just returning the size of the children vector can be taken, otherwise it needs to iterate over layoutable children and count them, since the structure may be complex.
One more major change this PR introduces is `cleanupContentsNodesRecursively`. Since nodes with `display: contents` would be entirely skipped during the layout pass, they would keep previous metrics, would be kept as dirty, and, in the case of nested `contents` nodes, would not be cloned, breaking `doesOwn` relation. All of this is handled in the new method which clones `contents` nodes recursively, sets empty layout, and marks them as clean and having a new layout so that it can be used on the React Native side.
Relies on https://github.com/facebook/yoga/pull/1725
Changelog: [Internal]
X-link: https://github.com/facebook/yoga/pull/1726
Test Plan: Added tests for `display: contents` based on existing tests for `display: none` and ensured that all the tests were passing.
Reviewed By: joevilches
Differential Revision: D64404340
Pulled By: NickGerleman
fbshipit-source-id: f6f6e9a6fad82873f18c8a0ead58aad897df5d09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47125
Original commit changeset: 9f05a461d178
Original Phabricator Diff: D64238887
Changelog: [Internal]
NOTE: while this seems to work on IGVR it breaks on the two use cases highlighted in D64339251, backing out the diff while trying to find out a solution that works on all cases!
Reviewed By: Abbondanzo
Differential Revision: D64611594
fbshipit-source-id: b43353b17448c181a76b2af09968cf0e4934c53c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47126
This will be used to validate the fix to `maintainVisibleContentPosition` for the two major use cases when the FlatList resizes:
* when the items have fixed size
* when the items scale with the size of the list
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D64339251
fbshipit-source-id: d0ee8d73cd9e6527a7ce0950e8f3941337b70474
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47120
Fixes no-op behaviour of the "Open DevTools" Dev Menu item (bug on `main` introduced with D63329456).
This was caused by a change to the `description` field contents in our CDP `/json/list` response, when under Fusebox. In the `/open-debugger` call from the Dev Menu, we were still using the older `appId` param.
This did not affect `j` to debug, which uses the `target` param.
{F1937186832}
Changes:
In short: Matching against the `description` string is now fully eliminated for modern debugger targets.
- Update native Dev Menu implementation to omit `appId` parameter (`device` param alone is sufficient and fully precise on these platforms).
- Update `/open-debugger` implementation to ignore the `appId` parameter for modern targets, and document this in the `dev-middleware` README.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D64597581
fbshipit-source-id: 46f536e7d0a4ececab0d52f4c0704e8698466cd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47088
Whe migrating this interface to Kotlin we've subtly introduced a breaking change which is causing a lot of breakages in the ecosystem.
This is forcing users to do:
```
// Before
reactContext.getNativeModule(UIManagerModule::class.java)!!.eventDispatcher
// After
reactContext.getNativeModule(UIManagerModule::class.java)!!.getEventDispatcher()
```
This reverts this breaking change.
Plus the method had a generic parameters which was completely unnecessary so I'm removing it.
Changelog:
[Android] [Fixed] - Undo breaking change on UIManager eventDispatcher accessor
Reviewed By: cipolleschi
Differential Revision: D64533594
fbshipit-source-id: c4f9a36993a22839fae90fb239f883305422ecec
Summary:
Fixes this: https://github.com/facebook/react-native/issues/41151
## Changelog:
[GENERAL] [FIXED] - Passed height and width as native props to support cases where source is an array.
**Issue**: Unable to use height and width as props in Image components when passing source as an array.
This functionality worked before this [commit](https://github.com/facebook/react-native/pull/34481). In Image.android.js and Image.ios.js, height and width props are extracted before passing them to the native side. This extraction makes these props ineffective when passed directly. Although setting height and width in style is a workaround, these props should still be respected since they exist for this purpose.
The issue occurs only when the source prop is an array. When source is an object, width and height are manually passed to the style object, so the issue doesn't arise.
Pull Request resolved: https://github.com/facebook/react-native/pull/47044
Test Plan: Tested this on `rn-tester` app
Reviewed By: necolas, javache
Differential Revision: D64458292
Pulled By: cipolleschi
fbshipit-source-id: 5cacad79b8d4468a4a1fd0977221e42ce4b2e5d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47109
Fixes the `lint/sort-imports` errors that are now surfaced after fixing the lint configuration.
For a couple files, I added lint suppressions instead because the unsorted import ordering is important due to interleaved calls with side effects.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D64569485
fbshipit-source-id: 26415d792e2b9efe08c05d1436f723faae549882
Summary:
During testing for 0.76-RC6, I came across the following behavior in RNTester.
Components > FlatList > Basic > Toggle `Empty` switch
You'll notice there are activity indicators in the header/footer (see video) for some time and things appear to be somewhat janky. I think the expectations would be to see only the `ListEmptyComponent` that is defined for this to look more correct. This will help not give any false indication that something has gone wrong with the latest picks when testing newer versions.
## Changelog:
[INTERNAL] [FIXED] - Fixed FlatList Empty behavior in RNTester
Pull Request resolved: https://github.com/facebook/react-native/pull/47094
Test Plan: https://github.com/user-attachments/assets/6e116641-5b24-473c-a654-7d32a081b83f
Reviewed By: yungsters
Differential Revision: D64541905
Pulled By: cipolleschi
fbshipit-source-id: 0447d99588d85f9e1a46c6da169a0838e94994bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46984
X-link: https://github.com/facebook/yoga/pull/1725
The legacy (wrong) absolute positioning path positions in two places, including work that is definitely always overwritten in the new absolute layout path.
This came up before for position: static, but we didn't clean this up at the time. This code is also now leading display: contents impl being more annoying.
This diff tries to converge to the more spec correct implementation of positioning here, that also only happens in one place.
Previous path would potentially also incorrectly justify when `justify-content` was non-default, but not handled in the previous few cases? We don't have access to the flexLine at this point later, and apart from the existing tests now passing I reused the new correct logic for justification (spec says we should position child as if its the only child in the container https://www.w3.org/TR/css-flexbox-1/#abspos-items).
I added a new, more scoped errata `AbsolutePositionWithoutInsetsExcludesPadding` to preserve some of the legacy behavior that showed as very breaking.
I also did not try removing `AbsolutePercentAgainstInnerSize` which I suspect would be more breaking than this change.
Changelog:
[General][Breaking] - More spec compliant absolute positioning
Reviewed By: joevilches
Differential Revision: D64244949
fbshipit-source-id: ca97570e0de82e8f0424a0912adfd0b05254559e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47078
Changelog: [Internal]
in fabric, we've found a scenario where this modal state update is required to cleanup all artifacts from the modal presentation views. it is safe to add this back, as it was originally removed for a scenario that no longer exists.
Reviewed By: shwanton
Differential Revision: D64388550
fbshipit-source-id: f13571260379554b0126c379ace9f9e1b81866be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47105
`codegenNativeComponent` expects we declare props as extending `ViewProps`, but the generated ViewConfig extends from BaseViewConfig.
This doesn't matter on iOS, where ViewProps are implemented more uniformly across components, but on Android, means we miss about 40 view props, since `ReactViewManager` backing `<View>` supports quite a bit more than `BaseViewManager`. This means that any components which extend `ReactViewManager` have some ViewProps omitted.
In this diff, I went with the solution of moving the props specific to View's ViewConfig to BaseViewConfig. This means the SVC may treat more props as valid than the underlying native component, but this should be safe compared to undercounting, and this will make future moves from ReactViewManager to BaseViewManager safer.
BaseViewConfig was already exposing props not supported by BaseViewManager, like those related to border widths (which effect LayoutShadowNode, but cannot be drawn out of the box?), so this shouldn't be too out there.
The alternative to this was to publicly expose the View ViewConfig and extend from that in codegen instead, but this seemed more complicated without much benefit.
Changelog:
[Android][Fixed] - Merge Android ViewNativeComponent ViewConfig into BaseViewConfig
Reviewed By: elicwhite
Differential Revision: D64570806
fbshipit-source-id: de5c590e935c879e33d59c36ddce1f2481023c19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46980
Changelog: [Android][Added] React Activity exposes ReactHost
**Context:**
*These changes will not impact `DefaultReactHost` which is the way most OSS apps interface with `ReactHost`*
* We are simplifying `ReactHost` and `ReactHostDelegate` for Brownfield uses.
* We fetch the `ReactHost` to create the `ReactDelegate`
https://www.internalfb.com/code/fbsource/[00ee07afc695]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactActivityDelegate.java?lines=110-112
* With Bridgeless, you must use or extend `ReactHostDelegate` to get the `ReactHost` since we don't expose a getter on `ReactActivity`.
* If there is a custom Application, then getting the `ReactHost` will need a custom implementation.
* For the base case, we shouldn't need to subclass the delegate.
**Change:**
* Expose `ReactHost` on `ReactActivity` for Bridgeless access.
* Expose `ReactActivity` on `ReactActivityDelegate`. This will help us avoid keeping a reference to Activity in each subclass.
* Update the RN Android API's
Reviewed By: arushikesarwani94
Differential Revision: D64150994
fbshipit-source-id: a9d790a4b4ce4eca29dee4bdc8d9fc56cf742f1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46819
Just some preparation to implement the new `BackgroundDrawable` and `BorderDrawable`.
This makes shadows and outline rely on `CompositeBackgroundDrawable` to set the state of `BorderRadiusStyle` and also makes them have a nullable borderRadius variable and initialize it only if we have it set saving a bit of overhead and performance
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63798853
fbshipit-source-id: 994327415ba160cf8e5ccb3135c4917809499f81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47104
In https://github.com/facebook/react-native/pull/46082, the lint configuration for `lint/sort-imports` was accidentally removed.
This has happened on more than one occasion in the past. In order to prevent this from happening again in the future, I'm also adding a Jest integration test to verify that this lint rule is enabled in the `eslintrc.js` configuration.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D64547410
fbshipit-source-id: ec4f14aff140691b644189dfa3116a3d39285f80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47102
Changelog: [internal]
In D64466057 / https://github.com/facebook/react-native/commit/32f7b3b4e0b8be1d1138f43c46b3c86d9a64c29a we accidentally modified the API of `NativePerformance.mark` (which we wanted to preserve and move the changes to `NativePerformance.markWithResult` after some iteration) to make `startTime` optional, which isn't compatible with the previous native API.
This fixes the issue by reverting the type back to being required and always passing it from the JS API.
Differential Revision: D64557467
fbshipit-source-id: 3ade4271622ac6213fd4c2d4948c7d40e4abe715
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47098
Changelog: [Internal]
D63329456 updated the `description` field to be human-readable.
Unfortunately, InspectorProxy relies on this field to compare the incoming `/open-debugger` calls.
hoxyq discovered the symptom of Fusebox failing to launch with `No compatible apps connected. React Native DevTools can only be used with the Hermes engine.` in Metro
Reviewed By: hoxyq
Differential Revision: D64547367
fbshipit-source-id: deed6851f3ede2c74be2b492def1eba6e58c43e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47101
See https://github.com/facebook/react-native/issues/47011
borders do not have this problem because they call `removeAllAnimations` on the layer after changing it, which is what I am doing here
Changelog: [iOS] [fixed] - Fixed bug where background colors would sometimes animate when changing on Views
Reviewed By: cipolleschi
Differential Revision: D64493968
fbshipit-source-id: cf81549f21b124b67c6e7647c6ae827bfe80a9cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47085
changelog: [internal]
Move induce method from AppleEventBeat and AndroidEventBeat to its subclass EventBeat.
# Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override EventBeat::request and EventBeat::induce.
Reviewed By: christophpurrer
Differential Revision: D64302639
fbshipit-source-id: cdea5ee64dc25633ae59fdce5b1ce6aff8a97d68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47092
This class should not be public. I'm updating the BUCK rule to make it `internal` and remove it from the public API surface.
Technically breaking however I haven't found meaningful usages of this API in OSS so this should be safe to ship.
Changelog:
[Android] [Breaking] - Make `AccessibilityInfoModule` internal
Reviewed By: mdvacca
Differential Revision: D64539866
fbshipit-source-id: 21c9965dc95b697bef93bbad23872921a73566aa
Summary:
## Summary
The React Native Renderer exports a
`__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED` property with a
single method that has no remaining call sites:
`computeComponentStackForErrorReporting`
This PR cleans up this unused export.
## How did you test this change?
```
$ yarn
$ yarn flow fabric
$ yarn test
```
DiffTrain build for [a3d9ea05bf01f3c3d7aedc2d938c581ad11fd14a](https://github.com/facebook/react/commit/a3d9ea05bf01f3c3d7aedc2d938c581ad11fd14a)
Reviewed By: rickhanlonii, kassens
Differential Revision: D64484457
Pulled By: yungsters
fbshipit-source-id: 9a7629210739d23175480191d30fc02ba3ee2fee
Summary:
Currently, tests on components that use the `AccessibilityInfo.announceForAccessibilityWithOptions` method fail because a mock for this method is not present in the `jest` setup file. This PR adds the mock for the before mentioned method in the appropriate `setup.js` file
## Changelog:
[General][Added] - Added the missing `announceForAccessibilityWithOptions` function mock in the `packages/react-native/jest/setup.js` file.
Pull Request resolved: https://github.com/facebook/react-native/pull/47063
Test Plan:
Here are the commands I executed after making the modification:
- `yarn prettier`
- `yarn lint`
- `yarn test`
### Test output

Reviewed By: tdn120
Differential Revision: D64495941
Pulled By: lunaleaps
fbshipit-source-id: 6ab835e2934b87ec3ac64cf0aebd8dcb58cd0da1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47087
In the repo, we don't have a `build-apple-framewroks.sh` file, but we do have a `build-apple-framewrok.sh` file, with no ending `s`
## Changelog:
[Internal] - Fix CI cache key
Reviewed By: cortinico
Differential Revision: D64531456
fbshipit-source-id: 05c104390b875eeef2cf15f8a30c8672cfc9b61d
Summary:
This PR improves PerformanceObserver Native Public API and fixes issue with `performance.measure` not working with mark names.
## Changelog:
- Made `PerformanceEntryReporter::report[Mark|Measure]` return the created entry with computed data.
- Updated JS-Native interface to return computed data from Native side to JS.
- Updated JS tests
[GENERAL] [FIXED] - Fixed `performance.measure` with mark names
[GENERAL] [INTERNAL] - `PerformanceEntryReporter::reportMark` and `PerformanceEntryReporter::reportMeasaure` now return created performance entries.
Pull Request resolved: https://github.com/facebook/react-native/pull/46786
Test Plan:
- [ ] Update JS tests
- [ ] Update Native tests
Reviewed By: rshest
Differential Revision: D64466057
Pulled By: rubennorte
fbshipit-source-id: d280d66c268a9830fbc9e6f3304e108ecf870a59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47070
For the sake of Stable API, I'd like to get this class converted to Kotlin
The class is becoming `final` so could be breaking for some users if they subclass `MainReactPackage` which I believe this should not be a valid usage of this API.
Changelog:
[Android] [Changed] - Migrate MainReactPackage to Kotlin (and make it final)
Reviewed By: tdn120
Differential Revision: D64479418
fbshipit-source-id: 24a07de4e5796a7b82ba34c9b36511b8fc526f1a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47086
When we migrated `ViewManagerDelegate` to Kotlin, we convered his string params to be `String` (rather than `String?`).
Existing implementation of this interface in OSS written in Kotlin were using `String?` due to this interface being in Java (and not being Nullsafe annotated).
Therefore now changing this interface from `String?` to `String` is a breaking change for them.
Affected libraries are:
https://github.com/search?q=%22fun+receiveCommand%28%22+%22commandId%3A+String%3F%22+%22args%3A+ReadableArray%22+language%3Akotlin+-org%3Afacebook+-is%3Afork&type=code&p=4
This prevents the breaking change and should be included in 0.76.
Changelog:
[Android] [Fixed] - Undo breaking change on ViewManagerDelegate.kt String params
Reviewed By: cipolleschi
Differential Revision: D64532446
fbshipit-source-id: aac286554ad0e35f557160f900bcbad1acc5930d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47084
Changelog: [internal]
This unifies all the feature flags that control the new event loop on RN. Before, we'd have granular flags for different aspects of it. With this diff, we enable the event loop by default with bridgeless, and we introduce a new flag to explicitly disable it in that case if necessary.
When we're ready to clean up this opt-out, we just need to remove the `&& !ReactNativeFeatureFlags::disableEventLoopOnBridgeless()` conditions.
Reviewed By: fkgozali
Differential Revision: D64464902
fbshipit-source-id: d1a0ba38dd4c189c2da905b49de23a821223ac3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47059
Changelog: [internal]
This adds a new configuration for feature flags to preserve their definition only in JavaScript and skip their native API and implementations. This is useful to preserve the API in JavaScript when JavaScript changes progress faster than native changes.
Reviewed By: sammy-SC
Differential Revision: D64464779
fbshipit-source-id: 0af9624daad7bd655172905f8f616d53655cb407
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47057
changelog: [internal]
EventBeat should never be copied. Make that explicit.
EventBeat::induce must never be empty, remove the default implementation.
# Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override EventBeat::request and EventBeat::induce.
Reviewed By: christophpurrer
Differential Revision: D64291845
fbshipit-source-id: 9265491c33b23d6ec2ccad4e2ea55e2b11211e6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47053
changelog: [internal]
AsyncEventBeat is Android specific, let's rename it to reflect that.
Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override EventBeat::request and EventBeat::induce.
Reviewed By: christophpurrer
Differential Revision: D64301829
fbshipit-source-id: cc550ce3836764519c2f4ef849d699ed66226359
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47052
changelog: [internal]
EventBeat can be constructed in Scheduler and passed to EventDispatcher. This is cleaner than passing down all dependencies and constructing it in place.
# Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override EventBeat::request and EventBeat::induce.
Reviewed By: christophpurrer
Differential Revision: D64291401
fbshipit-source-id: ef6d2bdb630767de1dab6052d9d9226c9e1a5f3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47051
changelog: [internal]
copy weak owner instead of using const&. const& is wrong here and hides important information because weak owner is always copied into ivat.
Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override EventBeat::request and EventBeat::induce.
Reviewed By: christophpurrer
Differential Revision: D64291515
fbshipit-source-id: 3e74270f03fac121e9f45b0a8ad287ccdb0a059a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47050
changelog: [internal]
- Rename SchedulerToolbox::asynchronousEventBeatFactory to SchedulerToolbox::eventBeatFactory. There is only one eventBeat, no need to distinguish between sync and async.
- Remove typealias EventBeat::SharedOwnerBox and pass by value instead of const&.
# Goal of this stack:
Centralise event beat logic into EventBeat class inside react-native-github. Subclasses should only override `EventBeat::request` and `EventBeat::induce`.
Reviewed By: christophpurrer
Differential Revision: D64291288
fbshipit-source-id: 96afc56a51677ed9e61b2a662bb968678fa770f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47066
This suppresses the warning:
```
Sharing is only supported for boot loader classes because bootstrap classpath has been appended
```
which is not relevant for us.
Changelog:
[Internal] [Changed] - Add -Xshare:off for Unit tests
Reviewed By: cipolleschi
Differential Revision: D64474372
fbshipit-source-id: 67d0a2da47ecd1d4ab906b03515b9a59f2e4f245
Summary:
After examining Hermes artifacts built after merging of https://github.com/facebook/react-native/issues/46865 , it was apparent that tvOS frameworks were missing from the Hermes universal framework generated by CI.
I went back and discovered additional steps that need to be added to the `build-hermes-macos` action to make CI work correctly.
## Changelog:
[Internal][Fixed] add required steps to build tvOS in build-hermes-macos action
Pull Request resolved: https://github.com/facebook/react-native/pull/47073
Test Plan: After merging, Hermes artifacts generated by CI should contain the missing tvOS bits.
Reviewed By: rshest
Differential Revision: D64528911
Pulled By: cipolleschi
fbshipit-source-id: 61db3e154767830a4726d7ceeec229a4af30d247
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47040
Updates `useMergeRefs` to support cleanup functions.
Changelog:
[General][Changed] - `useMergeRefs` and components using it (e.g. `Pressable`) now support ref cleanup functions.
Reviewed By: lunaleaps
Differential Revision: D64437947
fbshipit-source-id: b715abfa5b4236c1a7685ac023ff1d0384b6a3a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47076
The Jest unit tests for `useMergeRefs` were incorrectly implemented, leading to missing expected values. The root cause is that the test helpers were rendering to new roots instead of reusing the same root.
This refactors the test helpers to be simpler and easier to debug, and then fixes the bug described above.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D64498741
fbshipit-source-id: f0dd65f89e0c13721e83a8e38a699bc688812a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47069
Use of this internal type will trigger a `internal-type` error in the next version of Flow. This diff eliminates the last use in react native.
Changelog: [Internal]
Reviewed By: panagosg7
Differential Revision: D64479166
fbshipit-source-id: d440a2fbfe88223462ce61252082a2e7381fb4c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46914
The `BridgelessDevSupportManager` should have lived inside the `.devsupport` package alongside all the other
devsupport related tooling.
It was instead created inside `.runtime` causing a tight coupling with `ReactHostImpl`.
This made it impossible for Frameworks to customize it (i.e. in Expo GO) also because there was a circular
dependency between ReactHostImpl and BridgelessDevSupportManager
In this diff I'm:
1. Breaking the circular dependency by using `ReactHostDevHelper`
2. Updating all the parameters to reference `ReactHost` rather than `ReactHostImpl`
3. Moving BridgelessDevSupportManager to the `.devsupport` package.
This is breaking for users that are manually composing a `BridgelessDevSupportManager` or
that are extending the `ReactInstanceDevHelper`.
- `ReactInstanceDevHelper` has 3 new method which will have to be implemented.
- `BridgelessDevSupportManager` is now living in a different package.
Changelog:
[Android] [Breaking] - Add 3 methods to ReactInstanceDevHelper
Reviewed By: rshest
Differential Revision: D64105790
fbshipit-source-id: 13478fe1a035adb5b0dc83ebb1daad6cfb243881
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46986
# Changelog: [Internal]
Encapsulate integration with `FuseboxTracer.cpp` into `TracingAgent.cpp`, which will be responsible for handling `Tracing` domain CDP events.
Closer to the top of the stack, more changes will be added to it.
Reviewed By: huntie
Differential Revision: D64249695
fbshipit-source-id: 4adf5973299275e210e7cdf9c816efab881c9daf
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0004
## 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 ] [ Added ] - Add setOpacity test in new-arch-example
Pull Request resolved: https://github.com/facebook/react-native/pull/47043
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D64457441
Pulled By: cipolleschi
fbshipit-source-id: 310270293f5c7ec8a94c0d38fdd0897e4591ec14
Summary:
While working on the changelog, I realized that version 0.75.4 ended up in between RCs of 0.76
To avoid to lose the changelog of 0.75.4 once we release 0.76, I moved it to the right place, above 0.75.3's changelog
bypass-github-export-checks
## Changelog:
[Internal] - Sort Changelog properly
Reviewed By: cortinico
Differential Revision: D64470420
fbshipit-source-id: 0602b6cf4d7b9d9b3befb2535de6079d28545a15
Summary:
This PR addresses a potential `ArrayIndexOutOfBoundsException` in the Android module's permission checking logic.
```diff
- results.length > 0 && results[j] == PackageManager.PERMISSION_GRANTED
+ results.length > j && results[j] == PackageManager.PERMISSION_GRANTED
```
It ensures that we only access the results array when the index `j` is within bounds, preventing crashes due to invalid array access that have been occurring in the production environment.
Here is the Crashlytics dashboard concerning this type of crash on my app last week (react-native 0.75.4 - old arch):

## Changelog:
[ANDROID] [FIXED] - Prevent ArrayIndexOutOfBoundsException in permission check
Pull Request resolved: https://github.com/facebook/react-native/pull/47047
Test Plan:
1. Verify normal permission request scenarios still work on Android:
- Request a permission (e.g., camera, location)
- Grant the permission
- Verify the app functions correctly with the granted permission
2. Monitor production crash reports:
- Deploy the fix to production
- Observe a decrease in ArrayIndexOutOfBoundsException occurrences in the permission check logic
Note: As this crash was only observed in production, we'll rely on production monitoring to verify the fix's effectiveness over time.
Reviewed By: rshest
Differential Revision: D64464171
Pulled By: cortinico
fbshipit-source-id: 87beacf7ee749a51665577d05a56cc8d6889d70f
Summary:
Adds tvOS to the list of Apple platforms supported by the Hermes artifacts. After this, the React Native TV builds will be able to use the same Hermes artifacts as those used by RN core.
~Added some code in `hermes-utils.rb` so that the Hermes podspec can use a local Maven repo (`/tmp/maven-local`).~
> *Note:* ~This PR should not be merged until the corresponding Hermes PR https://github.com/facebook/hermes/pull/1529 is merged.~ (https://github.com/facebook/hermes/pull/1529 has been merged)
## Changelog:
[iOS][Added] tvOS support for Hermes artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/46865
Test Plan: - tvOS is also added to the build and test GitHub workflows.
Reviewed By: rshest
Differential Revision: D64461324
Pulled By: cipolleschi
fbshipit-source-id: d63889c60c72519818e7076cd0ab5851791715a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47018
This change makes it so that newly typed text in a TextInput will include the existing attributes present based on cursor position. E.g. if you type after an inner fragment with blue text, the next character will be blue (or, an event emitter specific to an inner fragment will also be expanded). This is a behavior change for the (admittedly rare) case of uncontrolled TextInput with initially present children AttributedText, but more often effect controlled components, before state update (we are after, less likely to need to reset AttributedString because of mismatch).
Originally included this in D64121570, but it's not needed to fix the common case since we include paragraph-level event emitter as part of default attributes, and has some of its own risk, so I decided it is better separate.
Changelog:
[iOS][Changed] - Include existing attributes in newly typed text
Reviewed By: cipolleschi
Differential Revision: D64352310
fbshipit-source-id: 90ef8c49f50186eadf777e81cf6af57e1aada207
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46970
Fixes https://github.com/facebook/react-native/issues/44157
This one is a bit of a doozy...
During auto-correct in UITextField (used for single line TextInput) iOS will mutate the buffer in two parts, non-atomically. After the first part, after iOS triggers `textFieldDidChange`, selection is in the wrong position. If we set full new AttributedText at this point, we propagate the incorrect cursor position, and it is never restored.
In the common case, where we are not mutating text in the controlled component, we shouldn't need to be setting AttributedString in the first place, and we do have an equality comparison there currently. But it is defeated because attributes are not identical. There are a few sources of that:
1. NSParagraphStyle is present in backing input, but not the AttributedString we are setting.
2. Backing text has an NSShadow with no color (does not render) not in the AttributedText
3. Event emitter attributes change on each update, and new text does not inherit the attributes.
The first two are part of the backing input `typingAttributes`, even if we set a dictionary without them. To solve for them, we make attribute comparison insensitive to the attribute values in a default initialized control. There is code around here fully falling back to attribute insensitive comparison, which we would ideally fix to instead role into this "effective" attribute comparison.
The event emitter attributes being misaligned is a real problem. We fix in a couple ways.
1. We treat the attribute values as equal if the backing event emitter is the same
2. We set paragraph level event emitter as a default attribute so the first typed character receives it
After these fixes, scenario in https://github.com/facebook/react-native-website/pull/4247 no longer repros in new arch. Typing in debug build also subjectively seems faster? (we are not doing second invalidation of the control on every keypress).
Changes which do mutate content may be susceptible to the same style of issue, though on web/`react-dom` in Chrome, this seems to not try to preserve selection at all if the selection is uncontrolled, so this seems like less of an issue.
I haven't yet looked at old arch, but my guess is we have similar issues there, and could be fixed in similar ways (though, we've been trying to avoid changing it as much as possible, and 0.76+ has new arch as default, so not sure if worth fixing in old impl as well if this is very long running issue).
Changelog:
[iOS][Fixed] - Fix cursor moving in iOS controlled single line TextInput on Autocorrection (New Arch)
Reviewed By: javache, philIip
Differential Revision: D64121570
fbshipit-source-id: 2b3bd8a3002c33b68af60ffabeffe01e25c7ccfe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47019
NOTE: This code is largely the same as https://github.com/facebook/react-native/pull/46847, I am merely fixing some internal issues
The original diff (D63989547) was backed out because it was causing some crashes related to some internal code that had to be changed. That code did not necessarily need to be changed - we could have just left the `RCTCreateCGColorRefFromSharedColor` function and not touched the internal code - which is what I am going to do here
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D64201626
fbshipit-source-id: a8ead7a542514aee0749973e284cb7727d393c03
Summary:
App Clips are full of bugs. One such bug is how launching an App Clip from Test Flight (and perhaps other systems) will cause the user activity to be of type `NSUserActivityTypeBrowsingWeb` but with a nullish `userActivity.webpageURL` (even though it's typed as never being nullish in this mode).
## Changelog:
[IOS] [FIXED] - Fix launching App Clips with nullish URLs.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/47000
Test Plan:
The following was failing cryptically and required extensive debugging to get launching.
https://github.com/user-attachments/assets/ffd26297-b20b-45a2-97cc-35a48b740cb2
Reviewed By: cipolleschi
Differential Revision: D64372170
Pulled By: lunaleaps
fbshipit-source-id: 388f05530f3bccdd9b446382931f127421bc8a27
Summary:
part of https://github.com/facebook/react-native/issues/46757
closes ME2E0006, ME2E0007
## 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] - add e2e test for Legacy Style Event
Pull Request resolved: https://github.com/facebook/react-native/pull/46784
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D64172277
Pulled By: cipolleschi
fbshipit-source-id: adf3a55b354f1a293c4620dc617a6a08e3aebd2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46953
Changelog: [internal]
This unifies all the feature flags that control the new event loop on RN. Before, we'd have granular flags for different aspects of it. With this diff, we enable the event loop by default with bridgeless, and we introduce a new flag to explicitly disable it in that case if necessary.
When we're ready to clean up this opt-out, we just need to remove the `&& !ReactNativeFeatureFlags::disableEventLoopOnBridgeless()` conditions.
Reviewed By: javache
Differential Revision: D64175216
fbshipit-source-id: b879447def8ab47c6ab772812ff1031177494069
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46972
Changelog: [internal]
I'm unifying the feature flags for the new event loop (so it's enabled by default when bridgeless is enabled, unless a feature flag is explicitly set), and I realized that the feature flags for Bridgeless, Fabric and Turbo Modules aren't being set in iOS, causing my changes to be incorrect (as we're using bridgeless but the bridgeless flag is off).
This forces the right flags when using bridgeless so the configuration is consistent.
Reviewed By: rshest, cipolleschi
Differential Revision: D64234056
fbshipit-source-id: bfdbe6742ee84c23d6d2c0c56e6ca8fce1788b26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47027
While I was writing the documentation for extracting a module in a library, I realized that Codegen ignored the local node modules.
The reason is that `require.resolve` fails to resolve a local path.
bypass-github-export-checks
## Changelog
[General][Fixed] - Make Codegen work with local modules
Reviewed By: cortinico
Differential Revision: D64242713
fbshipit-source-id: cc5167665a49df1d09eb66a0dc9d76466f087a25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47030
Looking at the videos from the E2E tests, it seems that the tests are pretty reliable aside from the first one that often fail. And it looks like it is failing not because the test is wrong, but because maestro hits some sort of timeout and kills the test sooner.
With these changes we are:
- giving more time to maestro to run
- not killing the emulator anymore
Killing and restarting the simulator was making this problem workse, because a newly started simulator required more time to boots and to work properly
## Changelog:
[Internal] - stop killing simulators and increase timeouts
Reviewed By: cortinico
Differential Revision: D64398111
fbshipit-source-id: 17b107fee24d0fbd4897212c1907be3761e337ab
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0005
## 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 ] [ Added ] - Add console.log measure test in new-arch-example
Pull Request resolved: https://github.com/facebook/react-native/pull/47020
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D64397112
Pulled By: cipolleschi
fbshipit-source-id: c9192d66065038528751e2e366f58158b06eb864
Summary:
In the new architecture, if you open the soft keyboard, unmount `KeyboardAvoidingView`, close the keyboard, and then remount `KeyboardAvoidingView`, it still assumes the keyboard is open and displays the keyboard avoiding area.
We need to check if the keyboard is still open after remounting.
Fixes https://github.com/facebook/react-native/issues/46942
## Changelog:
[GENERAL] [FIXED] - Fix KeyboardAvoidingView not aware of the keyboard closing it is unmounted
Pull Request resolved: https://github.com/facebook/react-native/pull/46952
Test Plan:
Code to reproduce in RNTester:
```JSX
import type {RNTesterModuleExample} from '../../types/RNTesterTypes';
import {Button, KeyboardAvoidingView, Text, TextInput, View} from 'react-native';
import {Fragment, Suspense, useState} from "react";
const infiniteThenable = { then() {} };
function Suspender({ freeze, children }) {
if (freeze) {
throw infiniteThenable;
}
return <Fragment>{children}</Fragment>;
}
function Freeze({ freeze, children }) {
return (
<Suspense>
<Suspender freeze={freeze}>{children}</Suspender>
</Suspense>
);
}
function Playground() {
const [isFrozen, setIsFrozen] = useState(false);
return (
<>
<TextInput style={{ height: 100 }} />
<Button title="Freeze" onPress={() => setIsFrozen(true)} />
<Button title="Unfreeze" onPress={() => setIsFrozen(false)} />
<Freeze freeze={isFrozen}>
<KeyboardAvoidingView behavior="padding" style={{ flex: 1 }}>
<View style={{ backgroundColor: '#909090', flex: 1, alignItems: 'center', justifyContent: 'flex-end' }}>
<Text>Test</Text>
<Text></Text>
</View>
</KeyboardAvoidingView>
</Freeze>
</>
);
}
export default ({
title: 'Playground',
name: 'playground',
render: (): React.Node => <Playground />,
}: RNTesterModuleExample);
```
### Steps
1. Tap the text input to show the soft keyboard.
2. Tap Freeze.
3. Tap the Enter or Done button on the soft keyboard to hide it.
4. Tap Unfreeze.
5. Verify that there is no blank area at the bottom of the screen.
### Videos
#### iOS
Before | After
-- | --
<video src="https://github.com/user-attachments/assets/0c8d840e-14a6-47ad-a163-d34ac9cfbf40" /> | <video src="https://github.com/user-attachments/assets/1d88a70c-e029-433d-920d-da7582edb3f2" />
#### Android
Before | After
-- | --
<video src="https://github.com/user-attachments/assets/f29f6526-c5a4-4b6a-b3aa-7c4c7ff3ed30" /> | <video src="https://github.com/user-attachments/assets/c4e92356-694b-4fca-8897-7dfca8495db0" />
Reviewed By: andrewdacenko
Differential Revision: D64178982
Pulled By: cipolleschi
fbshipit-source-id: 8d71654aac599cec4e1928b14d87cff34f28174a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47015
CMake is complaining that this variable is set outside the build but not used.
I'm using it inside our top level .cmake file to silence this warning.
We need this variable as user projects might use it.
Changelog:
[Internal] [Changed] - Silence CMake warning caused by `PROJECT_ROOT_DIR`
Reviewed By: javache
Differential Revision: D64334462
fbshipit-source-id: 558bfc9f647e62890e3cc25628b5544880c47e4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46990
This is a reattempt land D63643856 to fix the scroll onendreached event not firing.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: NickGerleman
Differential Revision: D64222424
fbshipit-source-id: 7e22f377d2f754beb39fff2b5c097cea350daa7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47012
Update Metro from `0.81.0-alpha.2` to `0.81.0`.
This is also intended to be the final, stable release for RN 0.76.
Changelog:
[General][Changed]: Update Metro to 0.81.0
Reviewed By: blakef
Differential Revision: D64329574
fbshipit-source-id: e12bed356b46e4ed68c75b397b7f9e2228c377be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46982
E2E test setup for each of the `resizeMethod` methods for Image on Android
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D64136839
fbshipit-source-id: 876939a50243836030401c6456410f119abe01b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46987
X-link: https://github.com/facebook/metro/pull/1371
Update `babel/register` to latest version, fixing the bug that were preventing us from updating it previously.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D64245277
fbshipit-source-id: f3d07b06a11fbe3a0ed28e22f5b687541782dda9
Summary:
When migrating `PackagerConnectionSettings` from Java to Kotlin in https://github.com/facebook/react-native/pull/45800 the new class ended up being declared as final, causing a breaking change in 0.76.
We should add the `open` directive to `PackagerConnectionSettings.kt` to restore the old behavior. That would be crucial for the `expo-dev-client` package, given that Expo needs to be able to extend this class in order to overwrite the `debugServerHost` value.
## Changelog:
[ANDROID] [FIXED] - Make PackagerConnectionSettings class open again
Pull Request resolved: https://github.com/facebook/react-native/pull/47005
Test Plan: Run RNTester on Android
Reviewed By: huntie
Differential Revision: D64323645
Pulled By: cortinico
fbshipit-source-id: 6870a3dee929ba664e4c402f321f84af7704f892
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46979
It seems that, when the items in a virtualized list don't have a fixed size (i.e. they dynamically scale with the size of the container), we need to also take into account their size when updating the scroll position as a consequense of setting `maintainVisibleContentPosition`.
Changelog:
[Android][Fixed] - Account for items dynamically scaling with the container when using `maintainVisibleContentPosition` in virtualized lists
Reviewed By: javache, NickGerleman
Differential Revision: D64238887
fbshipit-source-id: 9f05a461d178bc191137b1a350072337ba62e224
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47001
changelog: [internal]
EventBeat::beat is only used on Windows, let's move it there.
EventBeat::induce is only called by subclasses, doesn't need to be public.
Reviewed By: christophpurrer
Differential Revision: D64287646
fbshipit-source-id: 48edceddd273b45e8a4e63f4c1d5fda6c5adf425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46993
Calling ReactNativeFeatureFlags::enableDeletionOfUnmountedViews() from the destructor increases the chance of accessing ReactNativeFeatureFlags during the tear down of React Native.
We are moving this call into the contructor of the object which always happen on the js thread
changelog: [internal] internal
Reviewed By: rubennorte
Differential Revision: D64190029
fbshipit-source-id: 377b85e8ff0704db0f6603662f595b75a6705693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46994
This diff makes a small refactor on Systrace.traceSection() to unblock CI, which was broken by D64141515
changelog: [internal] internal
Reviewed By: Abbondanzo
Differential Revision: D64276651
fbshipit-source-id: e35950f88cde3d547992bb700208a4d4d309710f
Summary:
Using a new JVM profiler (D64128815) to find blind spot in the early startup init markers and adding them.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D64141515
fbshipit-source-id: d2968ed5dafdd891b8cc5a6115479c0678bfdc80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46963
Changelog: [internal]
This introduces a new method in `ReactNativeFeatureFlags` to force setting overrides without triggering any errors (they're returned a string instead to be handled in userland). This is partially equivalent to calling `dangerouslyReset` and `override` but completely avoids the hard crashes that could be caused by race conditions.
Reviewed By: javache, rshest
Differential Revision: D64186262
fbshipit-source-id: 854caa03810ec78217999292a4335dad373b7fcb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46965
Converting this class as close to 1:1 as possible.
Changelog: [Internal]
Reviewed By: NickGerleman, rshest
Differential Revision: D64124890
fbshipit-source-id: 2034ed8ecb877bb267a953b183b77daaf883a80a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46964
Graceful degradation is better than outright crashing. When rendering images that exceed Android's memory limits, React Native applications will fatally crash. This change intervenes by swallowing the exception that Android raises and forwards it to the `onError` handler. As a result, no image will be rendered instead of fatally crashing.
Fresco already intervenes by default. It will raise a `PoolSizeViolationException` if the bitmap size exceeds memory limits set by the OS and applies a 2048 pixel maximum dimension to JPEG images, but it's still possible for these configuration limits to be removed and for images to fall just short of Fresco's memory limit. The exception is raised when we attempt to draw the bitmap, not when the bitmap is allocated in memory, so we must handle the exception here and not in Fresco.
## Changelog
[Android][Fixed] - Apps will no longer fatally crash when trying to draw large images
Reviewed By: tdn120
Differential Revision: D64144596
fbshipit-source-id: 32b69ad4ecef0564c2cad7a287a31b56688f38b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46981
changelog: [internal]
stateUpdate with closure syntax has to be used in order to not override contentSize stored inside of C++ state.
Reviewed By: jessebwr
Differential Revision: D64242221
fbshipit-source-id: 32d55ccc03e32922f2746293ccb6c0941ca67d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46961
Changelog: [Internal]
Runtime Shadow Node Reference Syncing causes asserts when updating the shadow tree without passing through the JS-thread. This diff disables the feature by default to avoid the asserts encountered on RN Windows.
Reviewed By: sammy-SC
Differential Revision: D64188839
fbshipit-source-id: eb65206662d842f8150f1771c86dc8d190cbc3aa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46955
This is a major bump of Kotlin. It comes with no breaking changes for the Kotlin API, but there are several new warnigns that I had to fix.
Most importantly several `override` methods that are overriding Deprecated API, also need to be deprecated as well in Kotlin.
Changelog:
[Android] [Changed] - Bump Kotlin 1.9.x to 2.0.x
Reviewed By: tdn120
Differential Revision: D64179842
fbshipit-source-id: 295ab2636ce9f9bb04e9d8c7ed27d9f8a1a64338
Summary:
This change move E2E tests to larger mac machines to see if we can reduce the flakyness.
Most of the time the flakyness is due to slowness in connecting to the simulator or slowness in Metro to provide the bundle to RNTester when we run the tests in Debug.
More power should speed-up those processes.
E2E tests took < 30 min in this diff
on Main, they took > 120 min
## Changelog:
[Internal] - Move the E2E tests to bigger machines
Pull Request resolved: https://github.com/facebook/react-native/pull/46960
Test Plan: GHA
Reviewed By: blakef
Differential Revision: D64237659
Pulled By: cipolleschi
fbshipit-source-id: c2458413c8de70c07fae8f2b5f202371c6293815
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46958
This will make it easier to link against custom C++ TM which will most likely live inside ./shared or
some other paths outside of ./android.
CMake will have access to `PROJECT_ROOT_DIR` which points to ./android (the folder where the settings.gradle file exists).
Changelog:
[Internal] [Changed] - RNGP - Pass PROJECT_ROOT_DIR to CMake
Reviewed By: cipolleschi
Differential Revision: D64183641
fbshipit-source-id: 347256c04f10e92cf5a13e9c70db16aa29bcb741
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46936
Let's enable box-shadow everywhere! This should be safe, now that we assume any background mutating methods in BaseViewManager go through BackgroundStyleApplicator. `boxShadow` is also already in `BaseViewConfig` instead of configs for each native component (bc we were already planning to make this change).
Changelog:
[Android][Added] - Add boxShadow support to BaseViewManager
Reviewed By: mdvacca
Differential Revision: D64140841
fbshipit-source-id: e937a4bcaa4506fd25d0916633313083c7e49333
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46934
BaseViewManagerDelegate is a handcrafted second source of truth, used specifically for codegen.
The organization here has some problems, but this diff adds the props currently missing from it, so that these work correctly in generated view managers.
Changelog:
[Android][Fixed] - Add missing BaseViewManager props to BaseViewManagerDelegate
Reviewed By: mdvacca
Differential Revision: D64137615
fbshipit-source-id: 4ff85f2524e5472f3b768e212fd5f2d4d9a36e17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46932
In the old error handling pipeline, when the app [assigns an object to error[ExceptionsManager.decoratedExtraDataKey]](https://fburl.com/code/9t9u8rgv)
```
const error = new Error('Some error happened');
// Annotates the error with some custom extra data.
error[ExceptionsManager.decoratedExtraDataKey] = {foo: 'bar'};
ExceptionsManager.handleException(error, true);
```
That object [gets forwarded as extraData](https://fburl.com/code/gy7v173u) to ExceptionsManager.
This diff implements that functionality within the c++ earlyjs pipeline.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63927091
fbshipit-source-id: ac88bf3e545714aa42531e8e1365e2eba32a7c2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46935
Now, whenever the earlyjs c++ pipeline handles an error, it'll invoke callbacks registered via javascript.
## The API
```
if (global.RN$registerExceptionListener != null) {
global.RN$registerExceptionListener(
(error: ExtendedExceptionData & {preventDefault: () => mixed}) => {
error.preventDefault();
// show logbox
},
);
}
```
## The Future API
We want something more aligned with the HTML spec:
```
addEventListener('error', (event) => {
event.preventDefault();
// show logbox
});
```
## Fatals vs soft errors
The earlyjs pipeline covers just main bundle execution for now.
So, it displays logbox only if there was a soft error. If there was a fatal error, it'll just continue to display redbox as usual.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63769385
fbshipit-source-id: 9c01e1cfe0ec80842af2e5bcfbf0adfb040dbcf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46895
For the js error handling pipeline, the javascript data structure looks like [this](https://www.internalfb.com/code/fbsource/[6181b57f4ba3619f58056bcec65382650d6ff59a]/xplat/js/react-native-github/packages/react-native/src/private/specs/modules/NativeExceptionsManager.js?lines=17-35):
```
export type StackFrame = {|
column: ?number,
file: ?string,
lineNumber: ?number,
methodName: string,
collapse?: boolean,
|};
export type ExceptionData = {
message: string,
originalMessage: ?string,
name: ?string,
componentStack: ?string,
stack: Array<StackFrame>,
id: number,
isFatal: boolean,
// flowlint-next-line unclear-type:off
extraData?: Object,
...
};
```
So, I made the c++ data structure look similar
```
struct ParsedError {
struct StackFrame {
std::optional<std::string> file;
std::string methodName;
std::optional<int> lineNumber;
std::optional<int> column;
};
std::string message;
std::optional<std::string> originalMessage;
std::optional<std::string> name;
std::optional<std::string> componentStack;
std::vector<StackFrame> stack;
int id;
bool isFatal;
jsi::Object extraData;
};
```
Notes:
* [parseErrorStack](https://fburl.com/code/e27q9gkc) doesn't actually generate a collapse property on the error object. So, I omitted it from the c++.
* ExceptionsManager [always provides an extraData field](https://fburl.com/code/2bvcsxac). So, I made it required.
* In C++, I just stored extraData as a jsi::Object. I wanted the freedom to store arbitrary key/value pairs. But, I also didn't want to use folly::dynamic.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D63929580
fbshipit-source-id: 51d8fcc79c9383789d456cfe4527cdd3f579395f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46872
This can now be flow typed as a union because the codegen supports it.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D63681874
fbshipit-source-id: 97783df5ae71292dd10602dee0bea39743e62234
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46959
This method was deprecated in: b8893c7003
since React Native 0.72.
I verified that no-one is using it in OSS so I'm removing it.
This is necessary as I'll need to refactor the BridgelessDevSupportManager a bit.
Changelog:
[Android] [Breaking] - Remove Deprecated DefaultDevSupportManagerFactory.create()
Reviewed By: javache
Differential Revision: D64184635
fbshipit-source-id: a4081b2189d2e22cd9b2067f982a6ffd4f8b054e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46956
isHighlighted/isPressable/selection color are the same as the native default, there's no need to send these in our props payload needlessly.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64179256
fbshipit-source-id: 22e62c8d440d3bd219a79f445e49739c24fa5d52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46898
Replaces *many* `Text` component usages with `RNTesterText`: a thin wrapper around `Text` that applies color based on the color scheme chosen by the user. It makes text legible for dark mode across 41 different example files. This changes intentionally do not touch a few larger component sites that expand beyond RNTester, like `Animated` and `NewAppScreen`
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64053464
fbshipit-source-id: 9516fef2afe1b364eb38e85e3a2dbb5c434e44db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46949
# Changelog:
[Internal] -
This adds an (optional) event start time field into RawEvent, so that it can be threaded by the platform-specific code to tell where is the earliest point of the event start (depending on the platform).
For example, on Android platform it can be the point of time when the original MotionEvent was received.
Reviewed By: rubennorte
Differential Revision: D64175467
fbshipit-source-id: 535c95c695713dbbed74c554bceb70fa5e511d6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46929
Got this error on Marketplace Home when I tried on the iOS 18 simulator:
```
Cannot read property 'stack' of null
if (rejection.stack && ...
```
This indicated `rejection` was null.
Fixed by adding an extra null check there.
Changelog:
[iOS][Fixed] Fixed crash on promise rejection handler in iOS 18.
Differential Revision: D64116020
fbshipit-source-id: 4198748b47d27c6def9957ff475ee780962d3baa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46933
Some small tweaks to either resolve or better log clipping-related crashes in ReactViewGroup
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63914809
fbshipit-source-id: cf8bfd260c6affb85b8e1ac13447ae9f01d19135
Summary:
On Android, when `ReactEditText` is attached to window, `setTextIsSelectable` moves the caret to the beginning, so we need to restore the selection.
This is similar to what we did in https://github.com/facebook/react-native/pull/17851.
Fixes https://github.com/facebook/react-native/issues/46943
## Changelog:
[ANDROID] [FIXED] - Fix TextInput caret moving to the beginning when attached to window
Pull Request resolved: https://github.com/facebook/react-native/pull/46948
Test Plan:
Code to reproduce in RNTester:
```TSX
import type {RNTesterModuleExample} from '../../types/RNTesterTypes';
import {TextInput} from 'react-native';
import {useEffect, useRef} from 'react';
function Playground() {
const input = useRef(null);
useEffect(() => { setTimeout(() => input.current?.focus(), 1000); }, []);
return <TextInput ref={input} value='1.00' selection={{start: 4, end: 4}} />;
}
export default ({
title: 'Playground',
name: 'playground',
render: (): React.Node => <Playground />,
}: RNTesterModuleExample);
```
Before | After
-- | --
 | 
Reviewed By: cortinico
Differential Revision: D64175774
Pulled By: rshest
fbshipit-source-id: ef9fdbecca582c8075bcdfd2d9b810b04d87e3d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46931
Prepare for deletion of this deprecated type that contain support for string ref in the next flow release.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64127228
fbshipit-source-id: 9d3a1c0e6303efb35a540349fdc8e42b7b70be8b
Summary:
This PR follows up with the deprecation introduced here: https://github.com/facebook/react-native/pull/46228
The idea is to have new architecture depend on one flag, namely `newArchEnabled`. It exposes additional initializers for RCTRootViewFactory.
## Changelog:
[IOS] [CHANGED] - Use `newArchEnabled` flag in RCTAppDelegate and RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/46652
Test Plan: CI Green
Reviewed By: javache
Differential Revision: D64173015
Pulled By: cipolleschi
fbshipit-source-id: 49474baf5415a2527e481a5d68ec94ae874185e6
Summary:
There is a numerical issue that causes vertical scroll view to be considered as the horizontal one and leads to problems described [here](https://github.com/facebook/react-native/issues/46592). The problem is no longer visible after checking if the scroll view is horizontal with float equality.
~~I am not sure if it also happens on Android, so I am leaving it as a draft for now.~~
Fixes https://github.com/facebook/react-native/issues/46592
## Changelog:
[IOS] [FIXED] - check if scroll view is horizontal with float equality.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - fixed scroll view
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46836
Test Plan: Tested on the repro provided in the above issue.
Reviewed By: rshest
Differential Revision: D64114476
Pulled By: cortinico
fbshipit-source-id: a5048e1403c4bb675d32928937d6411cfb12fd51
Summary:
Update React Native on iOS to do less manual memory management, by replacing uses of `CGColorRef` with `UIColor`, and only calling `UIColor.CGColor` when needed. This results in much less manual memory management, which is probably a good thing in 2024 :D. The downside is there is a breaking change: the signature of a method in `RCTBorderDrawing` changes.
This is a followup to https://github.com/facebook/react-native/issues/46797 . After that PR merged and I tested merging React Native macOS to the `0.76-stable` branch cut commit again, I saw even more places I needed to manually call `CGColorRetain` / `CGColorRelease`. The reason is due to React Native macOS specifics (explained below) and I could update React Native macOS to not need these changes, but I thought I would at least throw up a PR to propose the changes, as it may be good to move away from using Core Graphics' C base API as much as possible.
## Longer Explanation
With https://github.com/microsoft/react-native-macos/pull/2209 , I wrote a shim of [UIGraphicsImageRenderer](https://developer.apple.com/documentation/uikit/uigraphicsimagerenderer) for macOS. The main difference is my shim calls the NSImage API [imageWithSize:flipped:drawingHandler:](https://developer.apple.com/documentation/appkit/nsimage/1519860-imagewithsize?language=objc) to shim the UIGraphicsImageRenderer API [imageWithData:](https://developer.apple.com/documentation/uikit/uiimage/1624137-imagewithdata). The difference between the two is that the macOS API copies the block, and executes it when Appkit is about to draw the image, while the iOS API executes the block right away. Because of this, I think I am hitting way more places where `CGColorRef` variables needed to be retained / released. Additionally, I hit more of them when I merge to the 0.76 branch cut commit (this is why I didn't catch it with https://github.com/facebook/react-native/issues/46797).
Given this constraint, I have a couple of options:
1. Refactor my macOS shim to use the deprecated API [[NSImage lockFocus]](https://developer.apple.com/documentation/appkit/nsimage/1519891-lockfocus)
- I am not a fan of this because `lockFocus` was deprecated for `imageWithSize:flipped:drawingHandler:`
2. Refactor my macOS shim to do what we used to do: Create a CGContext manually and write it to an image
- This is probably OK. Relies on less Appkit specifics, and potentially gives more control to RN on the rendering layer, which I recall lenaic told me is better for Fabric)
3. Refactor React Native to avoid CGColorRef altogether, and use `UIColor` (which ARC will memory manage for us) as much as possible.
- This is the approach of this PR and my preferred approach. The downside is this changes the signature of some of the methods in `RCTBorderDrawing` which is a breaking change. I've seen other PRs do this, so maybe its OK?
## Changelog:
[IOS] [BREAKING] - Replace uses of `CGColorRef` with UIColor to avoid manual memory management
Pull Request resolved: https://github.com/facebook/react-native/pull/46847
Test Plan: Launching RNTester's View example (which tests a lot of the border / outline / shadow rendering) does not crash for me on both iOS and macOS.
Reviewed By: NickGerleman
Differential Revision: D63989547
Pulled By: joevilches
fbshipit-source-id: 5e85e17567e3dd8b4b0388452398954ad2e02464
Summary:
Windows has a stricter set of rules for C++ files where we treat warning as error, the following files have fixes to correctly cast numbers and fix control path errors.
Control Path Error on React-Native-Windows repo:
```
1>react-native-windows\node_modules\react-native\ReactCommon\react\performance\timeline\PerformanceEntryReporter.h(138,1): warning C4715: 'facebook::react::PerformanceEntryReporter::getBufferRef': not all control paths return a value
1>react-native-windows\node_modules\react-native\ReactCommon\react\performance\timeline\PerformanceEntryReporter.h(154,1): warning C4715: 'facebook::react::PerformanceEntryReporter::getBuffer': not all control paths return a value
```
Apply these fixes will allow us to unfork these files in our repo :)
## Changelog:
[GENERAL] [FIXED] - Fix cast and control paths errors on windows
Pull Request resolved: https://github.com/facebook/react-native/pull/46899
Test Plan: Tested on the RNW repo, these files are already forked with the respective fix
Reviewed By: cipolleschi
Differential Revision: D64086963
Pulled By: arushikesarwani94
fbshipit-source-id: fdad72dafa1a01c426536fc1b007dd4a83588d93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46809
BaseViewManagerInterface isn't adding much value right now. It was added in D16984121 to allow codegen generated ViewManager delegates to apply to view managers which derive from ViewMangager instead of BaseViewManager (if they did some cleverness, to make VM delegate apply to a no-op class, still implementing all of BaseViewManager's methods).
All of the cases where that was used have since been moved to `SimpleViewManager`, and `BaseViewManagerAdapter` (needed to wire this together) doesn't exist anymore, so it's not possible to take any advantage of this interface existing. We should remove it, since its existence is a source of error (e.g. it was missing setters for `accessibilityValue` or those related to pointer events), and is more generally confusing for anyone adding to `BaseViewManager` in the future.
This is a breaking change, because there are some libraries which vendor a copy of generated ViewManagerDelegate when building against legacy arch to be able to share code normally generated at build time. That means these will need to be updated to maintain compatibility with RN versions of 0.77+ with new arch disabled. This will not effect compatibility of these libraries against the default new arch, and the updated delegate is still compatible with older RN version.
```
sourceSets.main {
java {
if (!isNewArchitectureEnabled()) {
srcDirs += [
"src/paper/java",
]
}
}
}
```
1. `react-native-picker/picker`
2. `rnmapbox/maps`
3. `react-native-gesture-handler`
4. `react-native-screens`
5. `react-native-svg`
6. `react-native-safe-area-context`
7. `react-native-pdf`
Changelog:
[Android][Breaking] - Remove BaseViewManagerInterface
Reviewed By: cortinico
Differential Revision: D63819044
fbshipit-source-id: 7e4935c8e43706b168f0f599a6676e8abfa66937
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
ME2E0019
## Changelog:
[ Internal ] [ Added ] - Added a test case for Image
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/46831
Test Plan:
yarn e2e-test-ios
yarn e2e-test-android
Reviewed By: cortinico
Differential Revision: D63889719
Pulled By: cipolleschi
fbshipit-source-id: 674879066ec159f11894f24935fe39a86ea1ea63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46896
On Android Paper UIManager, when calling `ReactRootView.unmountReactApplication`, the ReactRootView tag is unset [here](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java#L926), before the round trip unmount operation to JS makes it's way back to a `dropView` call on `NativeViewHierarchyManager`.
In practice, this means that legacy architecture apps that unmount surfaces via `ReactRootView.unmountReactApplication` leak references to Views, and the "finalization" step (`onDropViewInstance`) is not universally called.
This is an attempt to fix the issue by skipping the `clearReactRoot` step on Paper, instead waiting for the round trip `UIManager.removeRootView` call.
## Changelog
[Android][Fixed] Fix issue where `onDropViewInstance` cleanup was not being handled after `ReactRootView.unmountReactApplication`
Reviewed By: javache
Differential Revision: D64054042
fbshipit-source-id: b8b8c237796674ca23a332e57a1bf2e07ab5af13
Summary:
While the new `installJSIBindings(..)`/`BindingsInstaller` functionality allows you to synchronously set up stuff in the JS runtime before JS runs, there is no access to the JS CallInvoker, meaning you cannot really set up anything that uses callbacks or asynchronous code.
[Nitro](https://github.com/mrousavy/nitro) needs this.
## 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
-->
[IOS] [ADDED] - Add `CallInvoker` to `installJSIBindings(..)`
[ANDROID] [ADDED] - Add `CallInvoker` to `BindingsInstaller`
Pull Request resolved: https://github.com/facebook/react-native/pull/46851
Test Plan: In `SampleTurboModuleJSIBindings`, we can now use the `CallInvoker`.
Reviewed By: rshest
Differential Revision: D63975546
Pulled By: javache
fbshipit-source-id: 43cd469de2c35581f5362d2500fc27e41d6eab72
Summary:
For users who may have node installed in a path with a space, this requires escaping. For example:
```
NODE_BINARY=/Users/blakef/Library/Application Support/fnm/node-versions/v20.12.0/installation/bin/node
```
Needs to be:
```
NODE_BINARY=/Users/blakef/Library/Application\ Support/fnm/node-versions/v20.12.0/installation/bin/node
```
# Changelog
[iOS][Fixed] Generated NODE_BINARY in .xcode.env.local now supports paths with a space
Reviewed By: cipolleschi
Differential Revision: D64080118
fbshipit-source-id: 1045473e4fd284fc570fa538984618630be1af6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46887
Changelog: [internal]
This is a small change to use CommonJS in `ReactNativeFeatureFlags.config.js` so the file can be easily imported from Node.js.
Reviewed By: jorge-cab
Differential Revision: D64039860
fbshipit-source-id: c84ddbdbfe942224e213d12b9496c41b73dd5731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46817
As I've cleaned up all the RN Tester warnings, I'm enable warningAsErrors for RNTester to make
sure we keep up with our warning count.
Changelog:
[Internal] [Changed] - Enable warningAsErrors for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D63837633
fbshipit-source-id: f83273dadc7aa10ce7ae52ae790279819fb88345
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46890
Add details as this is discussed in the Turbo Native Modules documentation going out in 0.76:
```
Usage: combine-js-to-schema-cli.js <outfile> <file1> [<file2> ...]
Options:
--help Show help [boolean]
--version Show version number [boolean]
-p, --platform Platforms to generate schema for, this works on filenames:
<filename>[.<platform>].(js|tsx?) [default: null]
-e, --exclude Regular expression to exclude files from schema generation
[default: null]
```
## Changelog:
[General][Added] Add cli --help details to combine-js-toschema-cli.js
Reviewed By: dmytrorykun
Differential Revision: D64045337
fbshipit-source-id: a4b977da2cbb0198a5d43f17ca3466ebde21e9a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46873
## Summary
Adds a small showcase for the different `resizeMethod` options and how downsampling is applied
## Changelog
[Android][Added] - Added showcase for Android `resizeMethod` options when applied to a large image
Reviewed By: rshest
Differential Revision: D62393212
fbshipit-source-id: 46e7ff6310617acb9eb288e3831c0b5e6b1751c8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46866
## Summary
Adds a new `resizeMethod` called `none`. It disables downsampling on the image request and disregards the global image pipeline default. This has been a pain point raised when rendering large images on Android in issues like [this one](https://github.com/facebook/react-native/issues/21301) and [this one](https://github.com/facebook/fresco/issues/2397).
## Changelog
[Android][Added] - Adds a new `resizeMethod`, `none`, which disables downsampling for an image
Reviewed By: yungsters
Differential Revision: D62393211
fbshipit-source-id: d85e3ed098ad502c8edbdfa817c841271ee9e914
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46891
This was set but never directly used - fix it.
Changelog:
[iOS][Fixed] Removed usage of set but unused variable.
Reviewed By: mg-here
Differential Revision: D64029449
fbshipit-source-id: 0d60428317de95aa235f249c512fa968aa04f879
Summary:
This diff reverts D63643856
`_highestMeasuredFrameIndex` is not properly invalidated causing issues with previous logic when data size shrinks.
bypass-github-export-checks
Changelog:
[General][Changed] - Revert "Fix onEndReached not being called when getItemLayout is present and we scroll past render window"
Reviewed By: NickGerleman
Differential Revision: D64009287
fbshipit-source-id: 8a21b57f5247fc743e65f9a730ff33a9a89d2bc1
Summary:
`FpsDebugFrameCallback.getTotalTimeMS()` implementation loses accuracy due to incorrect order of type casting to int
## Changelog:
[ANDROID] [CHANGED] - Improve FpsDebugFrameCallback.getTotalTimeMS() accuracy
Pull Request resolved: https://github.com/facebook/react-native/pull/46869
Test Plan:
- Launch some test app
- Open up the [Dev Menu](https://reactnative.dev/docs/debugging#accessing-the-dev-menu) in your app and toggle Show Perf Monitor
- Compare results of current & improved implementations
Reviewed By: rshest
Differential Revision: D64024054
Pulled By: arushikesarwani94
fbshipit-source-id: 438792bace0e3443d151cf13364f6e94b66dfb5e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46878
Removes an unused code path from `ResourceDrawableIdHelper`. Vector drawables are now loaded via Fresco decoder so we don't need to offer this utility anymore. While part of the public API, it only made it into 0.76.0 RCs and should have really been marked internal.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D64021956
fbshipit-source-id: 6e8073e0f7f079d023fa1e45a5a43f8652ca2826
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46871
changelog: [internal]
Original commit changeset: 748efce7f0b8
Original Phabricator Diff: D59859754
This is temporarily until we find an actual solution that can both cache the colors and also react to theme changes updating the colors value properly.
Reviewed By: javache
Differential Revision: D64002346
fbshipit-source-id: 9ba3bd0d653b9a0d8617f45d42c0c3d966fba01f
Summary:
Modifying the CxxReactPackage by changing the annotation from UnstableReactNativeAPI to FrameworkAPI so as to now support custom C++ TM wrapper
Changelog:
[Android][Changed] - Modify CxxReactPackage to support custom C++ TM wrapper
Reviewed By: shwanton, christophpurrer
Differential Revision: D63740964
fbshipit-source-id: 175b1104dcd11674413199b30415516d4d324a97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46845
Previously, the parser was throwing away the values of a string union when storing it in the schema. It would only store the union as
```
{
type: 'UnionTypeAnnotation',
memberType: 'StringTypeAnnotation'
}
```
We now track the string literals through the parser and store them in the schema:
```
{
type: 'StringLiteralUnionTypeAnnotation',
types: [
{
type: 'StringLiteralTypeAnnotation'
value: 'light'
},
{
type: 'StringLiteralTypeAnnotation'
value: 'dark'
},
],
}
```
We aren't changing the generators, those still just output "string". They could eventually be made smarter.
The value of this is that the compat checker can now error when the union changes.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D63917685
fbshipit-source-id: 34a10e1f1910d2935837a3659f66049fd4473134
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46867
In multi-root Android React Native apps (e.g., multiple ReactFragments), if the following sequence occurs:
1. a Modal is displayed via the secondary root
2. the secondary root is destroyed
3. the app is backgrounded
4. the app is foregrounded
The LifecycleEventListener on the ReactModalHostView will fire, causing the Modal to be rehydrated in the onHostResume callback.
Removing the lifecycle event listener when the modal is detached from the window resolves the issue.
## Changelog
[Android][Fixed] Fix issues with Modals and lifecycle events in multi-surface apps
Reviewed By: alanleedev
Differential Revision: D64001103
fbshipit-source-id: 10f8304cd9cca0d5c90e39f5e361290f4fc35283
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46864
## Summary
Fresco v3.3.0 contains necessary adjustments to allow downsample overrides per image request (see https://github.com/facebook/fresco/pull/2787), as well as numerous other bug fixes and adjustments across both Drawee and Vito images.
## Changelog
[Android][Changed] - Update Fresco from 3.2.0 to 3.3.0
Reviewed By: oprisnik
Differential Revision: D63983051
fbshipit-source-id: 9ad0c40dfc864d24ffa39ca9e2bc0ddf8210f4f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46827
You can now define a native module that takes an argument that is a specific string literal:
Like this:
```
export interface Spec extends TurboModule {
+passString: (arg: string) => void;
+passStringLiteral: (arg: 'A String Literal') => void;
}
```
On the native side, this will still generate `string`, but the schema will now store the string literal, and it will be allowed in JS. This should allow more strict flow / typescript types for modules.
This will also allow the compatibility check to fail if the literal changes.
This is a step towards accepting a union of string literals.
Changelog: [General][Added] Codegen for Native Modules now supports string literals
Reviewed By: GijsWeterings
Differential Revision: D63872440
fbshipit-source-id: e54b97d34af4a3d1af51727db0777f26fb7b778c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46764
This is a patched fix to earlier attempt (D63700769) and resolving crash due to`java.lang.IllegalArgumentException: View=DecorView@b9f88af[AdsManagerActivity] not attached to window manager`.
- removing ` !dialogWindow.isActive` check as it is always true resulting in always doing early return causing other bugs
- adding try/ catch instead so the code can still run but can catch the known exception without crashing
Changelog:
[Android][Fixed] - Fix crash for Modal not attached to window manager
Reviewed By: mdvacca
Differential Revision: D63712422
fbshipit-source-id: 85fb6df340eb1139f954c92b5f1daf0dc41671d2
Summary:
React Native [app template provided by the CLI](https://github.com/react-native-community/template) currently uses [`metro-config` directly for `MetroConfig` type](https://github.com/react-native-community/template/blob/main/template/metro.config.js#L7).
However, it doesn't have `metro-config` as neither a dependency or dev dependency, which can lead to version mismatches.
While this is obviously a mistake on the template repo side, `metro-config` versions aren't matched with `react-native` versions. Therefore, getting the correct version of `metro-config` from `react-native/metro-config` would require reflecting on `react-native/metro-config`'s package.json etc. which is far from ideal. In my opinion it's would be much better to expose `MetroConfig` type from `react-native/metro-config` directly.
Version mismatching can happen in a monorepo setup. Say we have the monorepo structure using Yarn Modern:
```tree
.
├── RN75-app (workspace)
├── RN76-app (workspace)
│ ├── metro.config.js
│ └── node_modules
│ └── react-native
│ └── metro-config (0.76)
│ └── node_modules
│ └── metro-config (version for 0.76)
└── node_modules
├── react-native
│ └── metro-config (0.75)
└── metro-config (version for 0.75)
```
`react-native@0.75` gets hoisted to the monorepo root while `react-native@0.76` sits in an RN 0.76 app workspace.
Say we have the following `RN76-app/metro.config.js` contents:
```js
const {getDefaultConfig, mergeConfig} = require('react-native/metro-config');
/**
* Metro configuration
* https://reactnative.dev/docs/metro
*
* type {import('metro-config').MetroConfig}
*/
const config = {};
module.exports = mergeConfig(getDefaultConfig(__dirname), config);
```
In this case, `require('react-native/metro-config')` would resolve to `RN76-app/node_modules/react-native/node_modules/metro-config` since `react-native/metro-config` is a (dev) dependency of the App.
However `import('metro-config).MetroConfig` would resolve to `node_modules/metro-config` since it's not a direct dependency.
This is how we have a mismatch - imported functions come from different packages than imported type.
## Changelog:
[GENERAL] [ADDED] - Expose `MetroConfig` type directly from `react-native/metro-config`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46602
Test Plan:
`yarn build` to generate dist for `react-native/metro-config`, see it has the export of `MetroConfig`.
## Notes
If this PR gets approved, I'll submit relevant one to the CLI template.
Reviewed By: huntie
Differential Revision: D63258881
Pulled By: robhogan
fbshipit-source-id: e6f3c880eb4a0aa902c62932d58f243c38b07c2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46824
Changelog: [Internal]
Removing the implementation of layout-only shadow node reference updates, since the full version of shadow node reference updates are being released.
Reviewed By: shwanton
Differential Revision: D63831453
fbshipit-source-id: 84cb231be6c16bdc4a4b12a559c41b5a77064813
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46777
Simplifies this internal logic plus ensures there is one source of truth for `reactNativeVersion` in our CLI plugin. Also, renames the `ctx` variable to `cliConfig`, to more clearly signal that this is an integration point with the Community CLI.
Completes this wave of `community-cli-plugin` simplifications.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D63534247
fbshipit-source-id: bf5779fcf971dee1e0caf58b071df360636c53e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46839
The `ReactNativeFlipper` object is not referenced in the template since 0.75. We can safely remove it as users should not reference it anymore.
Changelog:
[Android] [Breaking] - Remove ReactNativeFlipper object, deprecated in 0.75
Reviewed By: huntie
Differential Revision: D63897187
fbshipit-source-id: a7d73a98550518e46f8dbc0c9b859e0afb16e8a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46854
When segment fetch fails, it seems incorrect to call the callback twice: once with error, and once with null.
This seems like a bug.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D63959015
fbshipit-source-id: f3ebb0f4732d99d91b5717a5bf193f44d957bde4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46846
As of D61658739, BaseViewManager setting color now goes through BackgroundStyleApplicator, which gives a default implementation of setting a background color, while storing information in a way where we can impement things like border radii and shadows on background for out of the box views.
I knew this could lead to breaks where we previously overrode view-level `setBackgroundColor` to do something custom, but didn't override on VM level, but didn't see any external usages so I assumed it should be relatively safe. Turns out we have some internal usages which run into this pattern (D63913128 already fixed one), including a usage in RN itself! Let's override the view managers in these to delegate to the view's custom drawing.
Changelog:
[Android][Fixed] - Fix some cases where we override setBackgroundColor on View-level instead of VM level
Reviewed By: Abbondanzo
Differential Revision: D63922722
fbshipit-source-id: af988d1436c790be97b2be1325541aa418bf43a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46820
Relanding this as we had to unship due to some issues, which are fixed in the previous diff
Reviewed By: NickGerleman
Differential Revision: D63844167
fbshipit-source-id: b3e62004fe87ff732aac1c1622ac35d581b4980f
Summary:
X-link: https://github.com/facebook/yoga/pull/1715
Pull Request resolved: https://github.com/facebook/react-native/pull/46799
Content box impl had a bug where we resolved padding % against the same reference length as the dimensions. Padding should always be against containing block's width. This is also true for width, but not for height, which should be against containing block's height.
This just pipes the width into our box sizing functions.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63787577
fbshipit-source-id: e512338770f25b66506cabab5a7cde8f04397ea0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46844
Currently we can't see when a network query is made. It makes it hard to debug performance in apps like Store because it's unclear which queries are preloaded, which are fetched as early as they can and which ones are fetched late.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D63858486
fbshipit-source-id: 29d74a68f96a7d4c7b212453d7c0ceba525f3e39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46841
Some apps are crashing because surfaces are started and stopped concurrently and this can create a deadlock.
This is an attempt to disentangle the deadlock by not moving synchronously to the main queue when starting a surface
## Changelog
[iOS][Changed] - Do not move to the main queue synchronously when starting a new surface
Reviewed By: fkgozali
Differential Revision: D63899469
fbshipit-source-id: 98cb313ebd610c65f6b06a683912856a00102e44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46747
You can now use unions in native modules.
Support for this pretty much existed, but one callsite was throwing for non-cpp modules which meant nobody could use this.
Previously, StructCollector would throw that this was not supported because it couldn't generate it for objc. Instead of generating something smart in the native code for each option, it just tells native to treat them like the base type (number, string, object).
Changelog: [General][Added] Codegen now supports Union Types in NativeModules
Reviewed By: GijsWeterings
Differential Revision: D63664505
fbshipit-source-id: 73278ed9cd64452173c5170aba44ced71181510f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46826
This change adds `isDarkerSystemColorsEnabled()` to `AccessibilityInfo` to enable access to iOS's "Increase Contrast" setting option. It also adds a new event, `darkerSystemColorsChanged`, to enable listeners to subscribe to changes on this setting.
## Changelog
[iOS][Added] - Added `isDarkerSystemColorsEnabled()` to `AccessibilityInfo` to read "Increase Contrast" setting value
Reviewed By: cipolleschi
Differential Revision: D63880393
fbshipit-source-id: a476f8fc4d7354826bc344876b359eb1a3485f0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46816
This converts the same native module from Java to Kotlin.
I've converted the whole module as it was quite simple + I've fixed some of the warnings.
Changelog:
[Internal] [Changed] - Convert react/nativemodule/samples/ to Kotlin
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D63837631
fbshipit-source-id: bb126d7649a6e8a36510bf2b252ecdfae91fe09f
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0017
- ME2E0018
## 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 ] [ Added ] - Add e2e test for button
Pull Request resolved: https://github.com/facebook/react-native/pull/46829
Test Plan:
yarn e2e-test-ios
yarn e2e-test-android
Reviewed By: rshest
Differential Revision: D63889079
Pulled By: cipolleschi
fbshipit-source-id: ca2ede3142d77170fcb4121b025eab56818ffb07
Summary:
This pr is part of issue https://github.com/facebook/react-native/issues/46757 solving tasks [ME2E0001] and [ME2E0002].
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ Internal ] [ Added ] - Add e2e test for modal
Pull Request resolved: https://github.com/facebook/react-native/pull/46796
Test Plan:
yarn e2e-test-ios
yarn e2e-test-android
Reviewed By: cortinico
Differential Revision: D63829299
Pulled By: cipolleschi
fbshipit-source-id: ff64d0babde8aea6e2586c2f69056a10533750f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46832
After bumping to minIOSVersion 15.1, we refactored the code to remove some check.
In the refactoring, we changed how the `keyWindow` is returned and now we are unsafely casting `UIScene` to `UIWindowScene`.
We have some internal apps that use `UIScene` that are not `UIWindowScene` and the change is causing them to crash.
This change fixes the crash by checking whether the selector is available in the UIScene and casting it only in that case.
Otherwise we return `nil`, the same behavior we used to have before the refactor.
## Changelog
[iOS][Fixed] - Cast the UIScene to UIWindowScene only if the scene respond to the selector
Reviewed By: javache
Differential Revision: D63890980
fbshipit-source-id: 3230e0075f06ed3f3d759b48f9c7bd13d8787b44
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0011
- ME2E0012
## 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 ] [ Added ] - Add e2e test for button
Pull Request resolved: https://github.com/facebook/react-native/pull/46805
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D63829243
Pulled By: cipolleschi
fbshipit-source-id: 87d8e62650c66fb07e116877a212eff79f10eaf2
Summary:
This PR moves `RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED` as it was used as string in the codebase and in OSS libraries.
## Changelog:
[IOS] [FIXED] - move RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED to const
Pull Request resolved: https://github.com/facebook/react-native/pull/46833
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D63891220
Pulled By: javache
fbshipit-source-id: d4fa1f751b4b0cb131ab6c6d4dd0a345762d7c71
Summary:
I discovered this while working on my shim of `UIGraphicsImageRenderer` for macOS (See https://github.com/microsoft/react-native-macos/pull/2209). A variable of type`CGColorRef` is not automatically retained and released when passed into a block. There was a case in `RCTBorderDrawing` where we were doing so. To fix this, we have two options:
1. Pass a `UIColor` instead (Requires a change to the signature of the function calling it)
2. Properly retain and release the variable.
The first option would technically be a breaking change (we would need to change the signature of `RCTGetBorderImage`, so I'm opting for option 2.
## Changelog:
[IOS] [FIXED] - Properly retain/release backgroundColor in RCTBorderDrawing
Pull Request resolved: https://github.com/facebook/react-native/pull/46797
Test Plan: CI should pass. Locally, borders still draw fine for me.
Reviewed By: joevilches
Differential Revision: D63827824
Pulled By: cipolleschi
fbshipit-source-id: 926601d062b90a7d741d7a1af3070cec4b8795ae
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## 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
-->
[GENERAL] [FIXED] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46787
This issue was raised by a some partner that were integrating with libraries that were setting the wrong C++ version.
With this change, RN takes ownership of the version of C++ that must be supported.
## Changelog
[iOS][Breaking] - Cocoapods decide the C++ version for iOS pods
Reviewed By: blakef
Differential Revision: D63760271
fbshipit-source-id: 5e629c61accd97fb10a199430d31e8b4c73d482b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46160
We use this for all built-in components now, and rely on going through `BackgroundStyleApplicator` to be able to set additional background effects like borders, rounded corners, box shadow, outlines.
Let's use this in `BaseViewManager`, to allow exposing those other effects to all views, letting RN manage the background drawable for views using `BaseViewManager` and exposing the props for the managed styles.
This is technically breaking, in the case where a custom component could previously inherit directly from `BaseViewManager`/`ReactViewGroupManager`, (vs `SimpleViewManager`/`ReactViewManager`), then override `setBackgroundColor` on the Android View, instead of the view manager, but this effected zero of the [276 top libraries](https://github.com/elicwhite/react-native-libraries), so I don't think it would be common to hit.
Changelog:
[Android][Breaking] - Use BackgroundStyleApplicator when setting background color in BaseViewManager
Reviewed By: tdn120
Differential Revision: D61658739
fbshipit-source-id: 15af649328ea18fda3cd68e56d481ed1c0fd43c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46800
X-link: https://github.com/facebook/yoga/pull/1716
Had a mini heart attack thinking I set the default to content box. Wrote this to double check and it passed. Might as well check it in
Technically the default to BoxSizing.h is ContentBox, but in the style we override that. Regardless I switched that around so border box was the default.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63802722
fbshipit-source-id: 49ed29657c964bc12a2bf70988061ab4599267ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46712
## Summary
Now that XML resources are loaded via Fresco decoder, this change removes the custom branch that attempts to load drawables on the main thread. Loading (i.e. binary XML decompression) is performed on a background decoder thread from Fresco the same as every other image type.
## Changelog
[Android][Fixed] - Avoid blocking the main thread when decompressing drawable resources
Reviewed By: javache
Differential Revision: D63476282
fbshipit-source-id: a8510d140f85a55b90bf4aab6fd4cf5e46dfc7fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46812
Convert to Kotlin as close a 1:1 as possible.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D63773448
fbshipit-source-id: 72d67ec5993ffb225b016937e6a33fc8d4a8af16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46763
Changelog: [Internal]
[iOS][DeprecatedAPI] - Deprecate UIApplication.windows access for iOS versions higher than 13.0
> 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead [-Werror,-Wdeprecated-declarations]
Reviewed By: cipolleschi
Differential Revision: D63708635
fbshipit-source-id: 18cfeda89def996319a46573abeb88d4672f6c0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46811
I turned this off a few weeks after we turned off in FB app in (D60273063), after discovering it defeated a check used to disable `removeClippedSubviews` in RTL (reintroducing its bugged behavior).
D63318754 fixed that bug, so this is turning back on by default. This is also needed to fix border rendering direction bug introduced in BackgroundStyleApplicator in views where the contextual layout direction is different from the root Android layout direction (either because of `direction`, or `I18nManager` forceRTL). This fixes some existing RNTester RTL screenshot test failures which are hooked via forceRTL.
This also fixes rendering of some native components like `Switch` which would previously not respect contextual direction.
Changelog:
[Android][Fixed] - Reenable `setAndroidLayoutDirection` by default
Reviewed By: javache
Differential Revision: D63815077
fbshipit-source-id: fea64191d83d366c6bfc7b8c58b215773c8e8efe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46613https://github.com/facebook/react-native/commit/bd323929dc5be5666ee36043babec7d981a095dc added a workaround to a bug where Android new arch would return incorrect measurements when the last character in dynamically sized TextInput is a newline. This workaround works by adding a placeholder character after any trailing newlines.
Apart from a minor oversight in the impl (unnecessary `toString()` copying text on every layout), approach of mutating Spannable will create problems for `PrecomputedText`, where we want to avoid mutating Spannable after set in more common cases for normal text (though mutation must happen for a few other cases, like adjustment, or EditText).
The real root cause of the issue is that StaticLayout tries to derive the size of text for area outside of what is covered by the Spannable (whose last char is the newline, considered on the previous to last line). This causes it to use text size, family, etc from `TextPaint`, which does not have this information set in new arch (the font size (but oddly nothing else) is set in Paper).
This updates TextLayoutManager to set this information on TextPaint before creating a layout. Because TextPaint is now mutable, and TextLayoutManager can be called by multiple threads, I made the variable thread local to avoid concurrent mutation. We also have the cached Spannable scenario where we have already lost the AttributedString, but in this case, we can reuse the underlying EditText paint, which I associate with the underlying cached Spannable.
I also marked a few more methods in TextLayoutManager private which nothing else is calling, to be able to better reason.
A followup, is that `ReactTextInputManager` sets all of these extra fields on the `EditText` paint (so those will be consistent), but `ReactTextAnchorViewManager` does not set all of these, so its underlying TextView would normally show newlines with an inconsistent size compared to the attributes present (though I don't think it much matters if we add the right amount of extra space to the actual layout).
Changelog:
[Android][Fixed] - Properly fix measurement of trailing newlines
Reviewed By: cortinico, mdvacca, mellyeliu
Differential Revision: D63303172
fbshipit-source-id: 63e5e24bce7fe8866524171d9acfc8f13e1efffc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46612
This information is lost by the time the AttributedString makes its way to be measured.
Pretty sure I've seen code do incorrect heuristics like grabbing first span for this (IIRC adjustFontSizeToFit does this)? Another case where we hit this on Android is when the last character is a newline (which is part of the Spannable), and layout needs to predict the size of the line which will come next (where it uses the EditText's underlying TextPaint, who is using these base attributes).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63303709
fbshipit-source-id: 644a97c80a9280e643514786ea6cf32faa4f1cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46711
## Summary
Vector drawable decompression is a blocking operation and can sometimes take upwards of 20-30ms per image, especially if that vector drawable uses complex colors. Less complex vector drawables still take several milliseconds to decompress and are served from a cache on later load attempts.
Here's a list of all the load times of vector drawable images in FBVR:
{F1891592104}
This diff aims to shift decompression to one of Fresco's decode threads, off the main thread, so we don't block while waiting for decompression operations to complete. This relies on adding a new custom decoder that reads the header of XML binary and converts encoded image requests to drawable objects that are yielded from the new `XmlDrawableFactory`.
It's important to note that this change does not stop `ReactImageView` from loading XML-based drawables on the main thread, it merely offers a new mechanism for loading them.
## Changelog
[Android][Added] - Add a new Fresco decoder for XML resource types
Reviewed By: mdvacca
Differential Revision: D63476283
fbshipit-source-id: b0f9b5af42254bcf038a9eb088e7d72dd39cdb51
Summary:
While digging through the types I came accross this TODO. Now that react-native uses version 5 of TS this can be updated
## Changelog:
[General] [Added] - Updated FlatList setNativeProps type
Pull Request resolved: https://github.com/facebook/react-native/pull/46773
Reviewed By: NickGerleman
Differential Revision: D63765333
Pulled By: cipolleschi
fbshipit-source-id: ad612205d168cd90f270da72092f8ce67f5038c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46789
GitHub is reporting those warnings on each pull request. This clears them up as they're effectively unused.
Changelog:
[Internal] [Changed] - Remove several unused imports in Flow code
Reviewed By: cipolleschi
Differential Revision: D63757201
fbshipit-source-id: 21189136a03de8899adcbf18c8f0e29844ade340
Summary:
On the old architecture you could take control of loading the bundle by implementing
```objc
- (void)loadSourceForBridge:(RCTBridge *)bridge
onProgress:(RCTSourceLoadProgressBlock)onProgress
onComplete:(RCTSourceLoadBlock)loadCallback;
```
in your `RCTBridgeDelegate`. This is not currently possible in the new architecture.
I've added this using a pretty much identical api by adding a function to both the `RCTInstanceDelegate` and `RCTHostDelegate` protocols. This will be called on the `RCTRootViewFactory`. I've added two properties to the `RCTRootViewFactoryConfiguration`, `loadSourceForHost` and `loadSourceWithProgressForHost`. If one is present, we call it, otherwise we fallback to the normal loading process
## Changelog:
[iOS] [Breaking] - Add ability to control bundle loading on the new architecture similar to `loadSourceForBridge`. Removed some properties from the `RCTRootViewFactory`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46731
Test Plan: Rn-tester works as normal and it is working for our use case in expo go.
Reviewed By: blakef
Differential Revision: D63755188
Pulled By: cipolleschi
fbshipit-source-id: f1f26b2775b9e547ce7a23028665797c19bfdd9b
Summary:
Because `UIGraphicsImageRenderer` doesn't exist on macOS, I need to shim it for React Native macOS (See https://github.com/microsoft/react-native-macos/pull/2209). I planned to use the name `RCTUIGraphicsImageRenderer`. However.. it seems that is used by a static helper function in `RCTBorderDrawing.m`. So.. let's rename it? The function is just a helper method to make an instance of the class, so I think the name `RCTMakeUIGraphicsImageRenderer` is slightly more idiomatic anyway.
This method is not public, so it should not break the public API of React Native.
## Changelog:
[IOS] [CHANGED] - Rename `RCTUIGraphicsImageRenderer` to `RCTMakeUIGraphicsImageRenderer`
Pull Request resolved: https://github.com/facebook/react-native/pull/46772
Test Plan: CI should pass
Reviewed By: joevilches
Differential Revision: D63765490
Pulled By: cipolleschi
fbshipit-source-id: de68dce0f92ec249ea8586dbf7b9ba34a8476074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46806
This fixes the CI which is currently red due to wrong C++ imports.
Changelog:
[Internal] [Changed] - Unbreak build_android
Reviewed By: javache, cipolleschi
Differential Revision: D63826953
fbshipit-source-id: 4d9e407331af666a420cf56178420df40e598ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46794
Original commit changeset: f57e9a51236c
Original Phabricator Diff: D63430964
Seeing some issues with this so gonna turn it off for the meantime.
Changelog: [Internal]
Differential Revision: D63777437
fbshipit-source-id: fe8abd0110b2cf7296911c5b1e95ada40d30994c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46795
Original commit changeset: d7bb6f115bca
Original Phabricator Diff: D63471840
See previous diff, there were some problems
Changelog: [Internal]
Differential Revision: D63777438
fbshipit-source-id: ea9f370eade10282fcee84d07d709b549dde1b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46736
Copying the comment in code:
> We only call `onEndReached` after we render the last cell, but when getItemLayout is present, we can scroll past the last rendered cell, and never trigger a new layout or bounds change, so we need to check again after rendering more cells.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: yungsters
Differential Revision: D63643856
fbshipit-source-id: 9c53789cb15b225ceac353c37cbb67f7beeaf4fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46793
Currently performance logging has several problems:
- We have widly different APIs. It's hard to know which to use for what.
- Most of these APIs don't allow retroactive timestamp which is important for hero logging and react flame graphs
- These APIs aren't accessible from JS/C++/Java/Koltin (this part will be fixed in another diff)
- Logging doesn't go to the right place. It either only goes to Systrace, or Perfetto but with broken async timeline etc...
This diff start addressing the problem by refactoring. Currently performance.measure/performance.mark are the best APIs. Let's start with refactoring them so that we can call them directly without the otherwise PerformanceEntry side effects.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63560473
fbshipit-source-id: 86755b3e8491a7cf6919173a07ba9421cd30e663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46788
Changelog: [internal]
This fixes the reported keys for C++ TurboModules:
```
import MyNativeCppModule from 'MyNativeCppModule';
Object.keys(MyNativeCppModule); // [] - expected
Object.keys(Object.getPrototypeOf(MyNativeCppModule)); // [] - NOT expected
```
Before, we were trying to read the properties from the method map in the public `TurboModule`, but in this implementation all the logic is actually in its delegate (also a `TurboModule` instance, yeah, confusing).
This fixes the issue by forwarding the call to the delegate that has the right information.
Reviewed By: javache
Differential Revision: D63761381
fbshipit-source-id: 90bd216efa0f60352c5ca341d210d83239c80dba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46785
changelog: [internal]
Make sure logs match the class name
Reviewed By: rubennorte
Differential Revision: D63757693
fbshipit-source-id: 815e70e8ae38d99b1908d3aa2a9cfffdd9dc9851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46780
This is primarily a debugger server change to better-align the `title` and `description` fields (visible in via the CDP `/json/list` endpoint), reporting them directly from the device.
For React Native users, the net effect of this change is to improve/align the display name for each debugger target in the CLI multi-select menu (`j` to debug). This change may also be useful for discovery in non-Fusebox frontends such as VS Code (`vscode-expo` extension).
Changes:
- Rename `title` prop on `InspectorPageDescription`/`IInspector::addPage` to `description` (no call site changes).
- Add `deviceName` param to `InspectorPackagerConnection`.
- Move the page `description` to the `description` JSON field.
- Update `InspectorPackagerConnection::Impl::pages()` to return new `title` and `description` fields.
- Align `OpenDebuggerKeyboardHandler` to display `title` field.
- Deprecate the nonstandard `deviceName` field.
**Before**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "React Native Bridgeless [C++ connection]",
"description": "com.facebook.RNTester",
...
}
```
The `description` field was previously the closest thing we had to a target identifier. Today, this is not needed, since we have the stable `reactNative.logicalDeviceId` field.
**After**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "com.facebook.RNTester (iPhone 16 Pro)",
"description": "React Native Bridgeless [C++ connection]",
...
}
```
The `title` field is now more human readable and aligned with what we render in the window title of React Native DevTools. The `description` field describes the type of debugger target (the specific React Native implementation).
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D63329456
fbshipit-source-id: cfe98f77e31c729431005925cfc66e2780ef8c72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46782
changelog: [internal]
Avoid setting C++ state for the same contentOffset. This is redundant work and can be safely avoided.
Reviewed By: NickGerleman
Differential Revision: D63700308
fbshipit-source-id: d6ea8cf6a1da47a13787b49abd66a87e3da57d34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46778
This has been rolled out internally already and is a good cleanup for OSS too. We no longer use this config externally (BRIDGE+FABRIC) so this shouldn't actually affect the new arch rollout.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752084
fbshipit-source-id: da3025f7b072dc7b82f8de22ff247b3979ae64d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46776
All other paths that touch `mAttachedReactRoots` uses this lock. We expect this to address a crash we're seeing in production where `startSurface` is invoked multiple times.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752083
fbshipit-source-id: f06d07aa70719945f6956fbf6e0cde3e9c8e8ed0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46751
rubennorte noticed that some turbo module methods were not getting cached on the jsRepresentation as expected. This is caused by the react-native-codegen wrappers we generate overriding the `get` method and bypassing this caching layer. Instead they should be overriding `create` to lazily allocate new properties. To prevent this from re-occuring, I've made `get` final so no other overrides can happen.
## Changelog:
[General][Fixed] Properties for C++ TurboModules using codegen were not correctly cached
[General][Breaking] TurboModule::get is now a final method, override `create` to customize property lookup
Reviewed By: rubennorte
Differential Revision: D63665966
fbshipit-source-id: c614901c2f0d698147ec9ba36a4b592ed3d37652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46697
Changelog: [internal]
This is already the case in `PerformanceMeasure` but for some reason we didn't apply it here as well.
Reviewed By: rshest
Differential Revision: D63541134
fbshipit-source-id: 262d504ed153e07e89492945f761887729bad9e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46698
Changelog: [internal]
Small optimization to use readers/writers for locking in `PerformanceEntryReporter`.
Reviewed By: rshest
Differential Revision: D63540236
fbshipit-source-id: 80b3fd313453ad8da4f0af2deaab61a86064b4b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46693
Changelog: [internal]
This unifies the native modules for `Performance` and `PerformanceObserver` in the same module. Keeping them separate is artificial and introduces unnecessary duplication. These APIs are very closely related so it makes sense to unify
Reviewed By: javache
Differential Revision: D63471855
fbshipit-source-id: fa8c5dc7b7c68954fc11867f68909d2c6c2ee85c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46760
Changelog: [internal]
Relying on the singleton was causing issues in iOS tests for RuntimeScheduler. This fixes those issues.
Reviewed By: rshest
Differential Revision: D63702251
fbshipit-source-id: 42b98e673ffba6f45b52510cdb3eea410e55b894
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46688
Changelog: [internal]
Just aligns on `report*` as the public API in `PerformanceEntryReporter` (e.g.: `measure` -> `reportMeasure`, `logEventEntry` -> `reportEvent`, etc.).
Reviewed By: rshest
Differential Revision: D63471856
fbshipit-source-id: 59617160c238aaefaefe8b6fc27de4481ef32ada
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46714
Sets up a feature flag to experiment with scheduling `Animation` completion callbacks in a microtask instead of executing them synchronously. (The completion callback is the callback passed into `animation.start(<callback>)`).
There are currently 4 potential scheduling behaviors of the animation completion callback:
- Synchronously when `start()` is invoked, for spring and timing animations that immediately complete (e.g. no delays and not native driver).
- Synchronously when `stop()` is invoked, if the animation has not yet completed.
- Synchronously during the layout effect phase, or commit phase (if the `useInsertionEffectsForAnimations` feature flag is enabled), if the animation has not yet completed.
- Asynchronously when the animation completes (e.g. non-zero delay or when the native driver is employed).
The wide number of variables and the timing-dependent nature of these variables means that the behavior of the completion callback is very non-deterministic.
Imperically, we have also found that most codebases using `useNativeDriver` mostly have completion callbacks executed asynchronously. However, this leads to surprising problems where the callback causes unpredictable behavior when it is called synchronously (e.g. when the animating component is unmounted *during* the animation).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63573322
fbshipit-source-id: 16c48be78c9ac65a64021249fad10f7265737c44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46718
Simple rename of a protected method that should not be called by anyone outside of the `Animation` class and its subclasses, just to make it more intuitive.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572363
fbshipit-source-id: cf68f63a9b361767b9dbfcd73124bcdae7a1806e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46717
Reduces redundancy and cleans up the layers of abstraction between the `Animation` class and its subclasses, by hoisting common and duplicated logic into the parent class.
I also cleaned up the Flow types in these files while I was at it.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572064
fbshipit-source-id: ab6bf7265b67ab38cc5a9d5c94f8cd1456c93f23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46720
Refactors the `Animation` subclasses (from Animated) such that using `useNativeDriver` with a non-native `AnimatedValue` will consistently fail when calling `start()`.
The current behavior is inconsistent because if a timing or spring animation has a non-zero delay, the error will be thrown in asynchronously in a timeout.
Changelog:
[General][Changed] - Animations started with incompatible `useNativeDriver` and `AnimatedValue` configurations will now synchronously fail. Previously, spring and timing animations with non-zero delays would throw the error asynchronously.
Reviewed By: javache
Differential Revision: D63572062
fbshipit-source-id: 2619e2867fe7754695e3347c838ad6fe136a6614
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46719
Implements a minor refactor of `TimingAnimation#start` so that we standardize how the `_useNativeDriver` case is handled.
There is no behavior change from this besides more consistently assigning to `this._startTime`. (Previously, we would not set it if the duration were 0 and `!useNativeDriver`.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572066
fbshipit-source-id: 9cbd05c5ca5e00227be69441b9d7d8a502690246
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46716
Changes `_nativeId` to be a private property in the `Animation` class (from Animated).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572065
fbshipit-source-id: 24facca0ccb1256f602ec4406bf8c0b22c4bbf96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46721
Currently, the `Animation` class (from Animated) defines an unofficially protected `__onEnd` property that subclasses are expected to populate. However, subclasses are expected to *not* invoke `__onEnd`, but instead call `__debouncedOnEnd`.
In order to make this code less fragile, this commit refactors the `Animation` class and its subclasses so that `onEnd` is stored in a private property and initialized by the `start` method in the `Animation` parent class. Now, the only way to invoke the `onEnd` callback is by calling `__debouncedOnEnd`.
The subclasses have been adjusted to call the `start` superclass method to initialize this.
Changelog:
[General][Changed] - The `Animation` superclass no longer exposes `__onEnd` as a property. Subclasses must instead invoke `super.start(…)` in their `start()` implementation.
Reviewed By: javache
Differential Revision: D63572063
fbshipit-source-id: 221153ca890c67c59713d607032536f57d7a5b0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46715
Properly mocks `NativeAnimatedModule` in Jest so that we can cleanup the `process.env.NODE_ENV` checks in Animated.
Changelog:
[General][Added] - Added Jest mocks for `NativeAnimatedModule`
Reviewed By: javache
Differential Revision: D63572067
fbshipit-source-id: a4fcedeebbaaa47a34bb356305652a3ed6358855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46742
Migrates type definitions in React Native to use the newly created `HostInstance` type instead of `NativeMethods` and `React.ElementRef<HostComponent<T>>`.
Changelog:
[General][Changed] - Simplified Flow types to use `HostInstance` (which changing nominal types).
Reviewed By: NickGerleman
Differential Revision: D63646763
fbshipit-source-id: 904894dc40da4d2e70bcb6df47018fc6248ea972
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46743
Creates a new `HostInstance` type for React Native, to more accurately capture the intent most developers have when using the `NativeMethods` type or `React.ElementRef<HostComponent<T>>`.
Since `React.ElementRef<HostComponent<T>>` is typed as `React.AbstractComponent<T, NativeMethods>`, that means `React.ElementRef<HostComponent<T>>` is equivalent to `NativeMethods` which is equivalent to `HostInstance`.
Changelog:
[General][Added] - Added `HostInstance` type to represent the instance of a `HostComponent<T>`.
Test Plan:
Ran the following successfully:
```
$ cd ~/fbsource
$ js1 flow
```
Reviewed By: NickGerleman
Differential Revision: D63646555
Pulled By: yungsters
fbshipit-source-id: 075859e6b0217521ba9ab2b92843ae7e47db5be0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46746
This change adds `isHighTextContrastEnabled()` to `AccessibilityInfo` to enable access to Android OS's "High contrast text" setting option. It also adds a new event, `highContrastTextChanged`, to enable listeners to subscribe to changes on this setting.
## Changelog
[Android][Added] - Added `isHighTextContrastEnabled()` to `AccessibilityInfo` to read `ACCESSIBILITY_HIGH_TEXT_CONTRAST_ENABLED` setting value
Reviewed By: NickGerleman
Differential Revision: D63155444
fbshipit-source-id: 9829b40e6c183f6beba732190dc318894e9d9a3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46762
changelog: [internal]
Typealias NonOwningList obscures the underlaying type and provides limited benefit. Using std::vector<ShadowViewNodePair*> is more readable.
Reviewed By: NickGerleman
Differential Revision: D63396285
fbshipit-source-id: 70cda3f33a7649cabbf5888fbefe0610d2c002b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46770
Small updates to the `react-native start` command CLI output:
- Change "Welcome..." text to blue.
- Display server base URL instead of port only.
- Embolden key command letters.
- "Ctrl+C to exit" prompt.
- Extra newlines for balance.
Changelog: [Internal]
Reviewed By: cortinico, cipolleschi
Differential Revision: D63328267
fbshipit-source-id: 119ddb2ba68c99df532840285c3c1f922e727e8b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46769
(Further refactors to logging after D63255296.)
Fully decouples `community-cli-plugin` from the unlisted optional dependency on `react-native-community/cli-tools'`. This is motivated by changes in https://github.com/facebook/react-native/pull/46627 which switch to using Metro's `TerminalReporter` API for emitting logs safely.
- Swaps out logs in the dev server for the `unstable_server_log` Metro reporter event.
- Swaps out `logger.debug()` calls for the `debug` package, currently used by Metro and `dev-middleware`.
- Swaps out other logs in the `bundle` command for `console`.
- (Also specify missing `semver` dep.)
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63328268
fbshipit-source-id: f552748ecc3456bd5fb8870c3a51d744a6bf3e70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46741
X-link: https://github.com/facebook/yoga/pull/1711
box sizing is really just a reinterpretation of what length properties (like `width`, `height`, `max-width`, etc) mean. So to implement this I just add the border and padding if we are in content box when we ask for any of these properties. All the math that gets done by the algorithm is still in border box land, and the layout we return is to be interpreted as the border box (this is actually the expected behavior per https://drafts.csswg.org/css-sizing/#box-sizing). This makes this implementation pretty simple actually.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63416833
fbshipit-source-id: fd76132cf51e8a5092129802c3a12ab24023018b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46649
X-link: https://github.com/facebook/yoga/pull/1705
To get the height and width we call a function currently named `getResolvedDimension`. This returns a `Style::Length`, which in most cases we "resolve" immediately by calling `resolve`. This is a bit confusing that you need to `resolve` something that is already `resolved`.
I plan on adding a new function soon for `contentBox` which would resolve the length for you, so I think this should be renamed.
Also deleted unused `getResolvedDimensions`
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63407730
fbshipit-source-id: e855c17d9c99817be308b7263fcb5d43559ede14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46761
The legacy paths for this is all gone and non functional. We can clean thes up fully now.
Changelog: [Internal]
Reviewed By: rshest, Abbondanzo
Differential Revision: D63652264
fbshipit-source-id: cabc1af0098553c64f834e6bc30000ef7a942a4c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46627
IMPORTANT: Requires a Metro bump, CI will fail until updated.
Introduces a target selection API for launching React Native DevTools when more than one device is connected.
Credit to robhogan for the initial internal implementation of `OpenDebuggerKeyboardHandler`!
(This leverages recent additions to Metro's reporter API — which we should follow up on to use for the rest of `community-cli-plugin`. Notably, using `TerminalReporter` ensures server output won't conflict with Metro's own event and progress logs.)
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63255295
fbshipit-source-id: da93500358791eabe4cab433cad31b82d518fb5f
Summary:
The previous scripts to trigger the react-native-communty/template
release workflow has not been working. This is a rewrite is js, along
with some testing to make this more robust.
I've have a PR to combine the publish and tag steps in the template publication: https://github.com/react-native-community/template/pull/65, this takes advantage of that change.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/46363
Test Plan:
1. Unit tests
2. Once the infrastructure lands in the `react-native-community/template` workflow, we can trigger a dry run.
## TODO:
- ~~Still needs to be used in the GH release workflow.~~
- ~~Template release workflow needs to land the dry_run input change.~~
## Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D62296008
Pulled By: blakef
fbshipit-source-id: 217326c44b1d820e36a1d847cf9ad24d228087c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46759
Changelog: [internal]
This improves the example in RNTester for `performance.mark` and `performance.measure` by only listing the marks/measures explicitly emitted from the example. This removes noise if other parts of the app are logging marks/measures as well.
Reviewed By: rshest
Differential Revision: D63695731
fbshipit-source-id: f65cf59363da0e6c9e0b3ffadf05abd2eb5a214c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46758
There are some occurrencies where the Modal results not attached to the Window, perhaps when the app is backgrounded.
This trigger an exception `java.lang.IllegalArgumentException: View=DecorView@b9f88af[AdsManagerActivity] not attached to window manager`.\
This was fixed already but the conversion from Java to Kotlin missed a condition in the `||` clause. We are adding it back.
## Changelog
[Android][Fixed] - Fix crash for Modal not attached to window manager
## Facebook
The original fix is in this diff D22264672 by mdvacca
Also see this post: https://fb.workplace.com/groups/rn.support/permalink/27047414764880449/
Reviewed By: cortinico
Differential Revision: D63700769
fbshipit-source-id: bc8a44868d5cacb8822e1646c2b7643682f45e1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46735
We had some crash on Android where we call [`callFunctionOnModule`](https://github.com/facebook/react-native/blob/main/packages/react-native/ReactCommon/react/runtime/ReactInstance.cpp#L258) when the `bufferedRuntimeExecutor_` might not be initialized. This can happen when navigating away from RN surface and quickly navigate to another one or across refreshes.
There could be a scheduled JS function from the previous surface/instance that might try to call a native module while the new instance is being created.
This change prevent the crash and replace it with a soft crash, that should show a RedBox on the screen.
## Changelog
[Internal] - Throw JS exception when calling a method if buffereRuntimeExecutor is not initialized
## Facebook
Have a look at T201983945 that generated the crash report
Reviewed By: cortinico
Differential Revision: D63638633
fbshipit-source-id: ba331f5173963265232d0810c2d12895cea3d528
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46756
prepareGlog was firing a warning due to a duplicate config.h file. Here I'm setting so that the file is always overridden (which is the desired behavior) to suppress this warning.
Changelog:
[Internal] [Changed] - Fix build warning for prepareGlog
Reviewed By: cipolleschi
Differential Revision: D63696664
fbshipit-source-id: 83b78afea09c4a5d39f341dd5b604cec466470ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46754
This method has been deprecated since 0.76, but we're still using it inside our codebase.
I'm cleaning up the only usage of it replacing it with the implementation.
Changelog:
[Internal] [Changed] - Do not reference `setTranslucentBackgroundDrawable`
Reviewed By: cipolleschi
Differential Revision: D63695933
fbshipit-source-id: d39b13b584d3ac1406c61c3bf86b86b05dc984d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46755
There is no need to apply `java-gradle-plugin` to the root build of RNGP as that does not contain any Gradle Plugins (they're in subfolders).
This is actually causing the build to be a bit slower as extra tasks for compilation/bundling will be created which are definitely not needed.
Changelog:
[Internal] [Changed] - RNGP - Do not apply `java-gradle-plugin` on root build
Reviewed By: cipolleschi
Differential Revision: D63695934
fbshipit-source-id: 84268105c73b49afdcd94610fcb7006ef53306a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46750
Fixes https://github.com/facebook/react-native/issues/39659
Fix is pretty straightforward, parameter is annotated as Nullable, but is accessed with a `.split` call.
This causes a crash when the `textDecorationLine` property is removed (i.e. is null).
Changelog:
[Android] [Fixed] - Fix NPE on ReactTextInputManager.setTextDecorationLine
Reviewed By: cipolleschi
Differential Revision: D63689492
fbshipit-source-id: 3424897cc40beaeb579e3affd0a87656ff43afee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46753
Colors can be more than just ints, so we need to use `ColorPropConverter` to convert it correctly. For ViewManagers, this happens automatically through the ReactProp annotation, but since this is a nested field, we need to manually apply it.
Changelog: [Android][Fixed] BoxShadow now supports platformColor.
Reviewed By: fabriziocucci
Differential Revision: D63693048
fbshipit-source-id: 26b1da24db1b6f319af8cef6f62e4739c3f65ee3
Summary:
This PR exposes `RCT_NEW_ARCH_ENABLED` flag to Swift.
It allows you to use conditional compilation:
```swift
#if RCT_NEW_ARCH_ENABLED
func test() {
print("I'm running on new arch!)
}
#else
func test() {
print("I'm running on old arch!)
}
#endif
```
## Changelog:
[IOS] [ADDED] - expose RCT_NEW_ARCH_ENABLED to Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/46749
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D63689711
Pulled By: cipolleschi
fbshipit-source-id: 706013019571f597d1966ffcf13bd47ba7f29a2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46659
The current `AnimatedProps` maps all types to `any` which prevents us from catching many types of issues. Introduce an alternative variant which we can adopt incrementally which enforces the underlying types.
Changelog: [General][Fixed] Improved types for AnimatedProps
Reviewed By: SamChou19815
Differential Revision: D63315760
fbshipit-source-id: 718fc2754cc99891e490a48d7792f626205c37e4
Summary:
This further reduces the build warning coming from the Hermes build, which we can't do much about as we don't own that code.
## Changelog:
[Internal] [Changed] - Further Reduce Build Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46733
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D63644753
Pulled By: cortinico
fbshipit-source-id: d0e65559715ac1fa2b920f4c3d3cf63b6171765d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46734
The TypeScript definition for `NativeMethods` defined a `refs` property for referencing component instances by string refs.
String refs are deprecated and support is being formally dropped in React 19.
This removes the obsolete type definition.
Changelog:
[General][Removed] - Removed `refs` property from `NativeMethods` TypeScript definition.
Reviewed By: NickGerleman
Differential Revision: D63640881
fbshipit-source-id: 82148ac91bd44d63da9a41b1d1dcebb7ca32a5bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46727
It makes scripts operating on the schema complicated when the elementType might be there or might not. Let's make it required, but VoidTypeAnnotation if it's unknown.
Arguably we shouldn't allow it to be unknown at all, but that's out of scope here.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D63616703
fbshipit-source-id: 290586384b911928e55344aa522bd296f23a074c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46726
An object isn't allowed to have both an indexer and regular properties. Previously, the schema just wouldn't include the properties and would only include the indexer. Instead of failing silently and not generating the expected code, let's explicitly error out.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D63615090
fbshipit-source-id: a4c881b7a809f0b467509f7f7e2131be59ee274e
Summary:
In an effort to achieve a similar API in the new architecture, I was trying to replace the following code from the old architecture:
```
import { NativeModules } from 'react-native'
// ...
NaiveModules.DevMenu.show()
```
After https://github.com/facebook/react-native/issues/46694 landed, you can achieve this with the following import in the new architecture:
```
// ts-ignore
import DevMenu from "react-native/Libraries/NativeModules/specs/NativeDevMenu"
// and then use it
DevMenu.show()
```
However, this change provides the interface for `DevMenu` from the `react-native` package, similar to the API for `DevSettings`, making it easier to use via the public API and better type support.
```
import { DevMenu } from 'react-native'
DevMenu.show()
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Export `DevMenu` from `react-native`
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46723
Test Plan:
<img width="750" alt="image" src="https://github.com/user-attachments/assets/dc5a9876-4364-473e-9fd8-c49484d6de01">
### Before
`any` type on `show` from the private import
<img width="226" alt="image" src="https://github.com/user-attachments/assets/45a085d2-9794-482d-b5ec-3b882aadb56b">
### After
typed show method from the new import
<img width="399" alt="image" src="https://github.com/user-attachments/assets/7c7587b3-499b-40f0-8262-126e4ec17dc6">
Reviewed By: cortinico
Differential Revision: D63631196
Pulled By: huntie
fbshipit-source-id: a00efa85c8ca1aa127c9ae0a059978ba5eadb376
Summary:
Ok so this is a doozy.
## Overview
There was a report that some console.error calls were being shown as warnings in LogBox but as console.error in the console. The only time we should downlevel an error to a warning is if the custom warning filter says so (which is used for some noisy legacy warning filter warnings internally).
However, in when I switched from using the `Warning: ` prefix, to using the presence of component stacks, I subtly missed the default warning filter case.
In the internal warning filter, the `monitorEvent` is always set to something other than `unknown` and if it's set to `warning_unhandled` then `suppressDialog_LEGACY` is always false.
However, the default values for the warning filter are that `monitorEvent = 'unknown'` and `suppressDialog_LEGACY = true`. In this case, we would downlevel the error to a warning.
## What's the fix?
Change the default settings for the warning filter.
## What's the root cause?
Bad configuration combinations in a fragile system that needs cleaned up, and really really bad testing practices with excessive mocking and snapshot testing (I can say that, I wrote the tests)
## How could it have been caught?
It was, but I turned off the integration tests while landing the component stack changes because of mismatches between flags internally and in OSS, and never turned them back on.
Changelog: [General] [Fixed] - Fix logbox reporting React errors as Warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/46637
Reviewed By: huntie
Differential Revision: D63349613
Pulled By: rickhanlonii
fbshipit-source-id: 32e3fa4e2f2077114a6e9f4feac73673973ab50c
Summary:
Solve a part of this issue: https://github.com/facebook/react-native/issues/46631
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [CHANGED] - Passed correct title and titleColor prop to updateTitle function
**What's the Issue:**
When updating the PullToRefreshViewProps in a React Native iOS app, changes to the title and titleColor were not being reflected properly in the RefreshControl. This happened because the function responsible for updating the title (_updateTitle) was not always receiving the correct or updated values for title and titleColor.
**Updated `_updateTitle` function:**
The _updateTitle method was modified to accept both title and titleColor as parameters. This ensures that the latest values are always used when updating the refresh control's attributedTitle.
If the title is empty, the attributedTitle is cleared by setting it to nil. Otherwise, both the title and titleColor (if present) are applied correctly.
Pull Request resolved: https://github.com/facebook/react-native/pull/46655
Test Plan:
**Without fix:**
https://github.com/user-attachments/assets/8a83c247-bf78-4080-bdc1-ac5a852481e8
**With Fix:**
https://github.com/user-attachments/assets/52e2495a-4419-41d1-b308-acb64600f9f7
Reviewed By: javache
Differential Revision: D63466516
Pulled By: cipolleschi
fbshipit-source-id: fef61a003b658b20a25b61b6d07ee9fe0750dae7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46705
We have multiple classes in React Native Android acting as a binding layer (between C++ and Java, between C++ and JS). Make it more obvious this Binding is for (Android) FabricUIManager and flatten the (now) unused Binding interface.
Changelog: [Android][Removed] BindingImpl is no longer part of the public interface
Reviewed By: cortinico
Differential Revision: D63536329
fbshipit-source-id: 329d184c1889fbe804995211cdd339b50a7c9234
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46701
Reduce the interface we expose in SurfaceHandler(Binding), and concentrate the logic in the FabricUIManager Binding.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D63536328
fbshipit-source-id: 5882bdd24fd3ca8f3d36210dca80587fee091dcf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46704
Our build log for Gradle is extremely noisy due to Hermes.
Here I'm suppressing all the build output from Hermes as we can't really do much from that side of the build.
This should make it easier for folks on GitHub Actions to immediately spot where are failures.
Changelog:
[Internal] [Changed] - Silence unnecessary Gradle outputs
Reviewed By: GijsWeterings
Differential Revision: D63541175
fbshipit-source-id: d1a60098c317ff9e8c9575b5b8b2aab639f28f2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46680
Since the parent of a view with mixBlendMode prop set is the one responsible for setting the compositing of the child, when updating mixBlendMode on a child we need to also invalidate the parent.
Changelog: [Android] [Fixed] - mixBlendMode now properly does state updates
Reviewed By: joevilches
Differential Revision: D63424394
fbshipit-source-id: 0eb15520f1087e25683853632943e64a66344481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46685
This attempts a similar fix to D59566611, but keeps the removedClippedSubviews logic as is, instead moving the current translation done in ReactHorizontalScrollContainerView onLayout to ShadowNode layout metric assignment (so the world is consistent from very early on, and `removeClippedSubviews` never sees coordinates before translation),
I suspect doing this at the ShadowNode layer might also result in some fixes to DevTools in RTL.
This should let us roll out setAndroidLayoutDirection again.
Changelog:
[Android][Fixed] - Fix interactions between removeClippedSubviews and RTL
Reviewed By: mdvacca
Differential Revision: D63318754
fbshipit-source-id: 828e103e2ad21c7e886e39c163474b10ebd5099e
Summary:
A crash we are getting in the wild suggests that destruction on weak ref count going away may be delaying RuntimeExecutor task destruction to a point where jsi::Function is invalid. Let's try backing D62748768 out and seeing if the crash goes away.
Changelog:
[General][Fixed] - Attempt to fix crash from delayed RuntimeExecutor task destruction
#bypass-github-export-checks
Reviewed By: mdvacca
Differential Revision: D63568504
fbshipit-source-id: 6152e7293902d0eb67a14c5840bea56561c35b08
Summary:
Fixes https://github.com/facebook/react-native/issues/46568 . cc cipolleschi
## Changelog:
[IOS] [FIXED] - Fabric: Fixes animations strict weak ordering sorted check failed
Pull Request resolved: https://github.com/facebook/react-native/pull/46582
Test Plan:
See issue in https://github.com/facebook/react-native/issues/46568
## Repro steps
- Install Xcode 16.0
- navigate to react-native-github
- yarn install
- cd packages/rn-tester
- bundle install
- RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
open RNTesterPods.xcworkspace to open Xcode
{F1885373361}
Testing with Reproducer from OSS
| Paper | Fabric (With Fix) |
|--------|-----------------|
| {F1885395747} | {F1885395870} |
Android - LayoutAnimation (Looks like it has been broken and not working way before this changes.)
https://pxl.cl/5DGVv
Reviewed By: cipolleschi
Differential Revision: D63399017
Pulled By: realsoelynn
fbshipit-source-id: aaf4ac2884ccca2da7e90a52a8ef10df6ae4fc8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45786
Following D60377082, `packages/react-native/Libraries/` is now 100% parsable by `flow-api-translator` and covered by `flow-api-test`. This diff increases test strictness to preserve this state going forward.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60377123
fbshipit-source-id: 8c48bdd73d9d0d97a114d553eb70cc01faf18e89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45785
Adds `flow` annotation, and/or adds minimal Flow types to remaining files under `packages/react-native/Libraries/`. As of this diff, 100% of this directory is now parsable by `flow-api-translator` and covered by `public-api-test`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60377082
fbshipit-source-id: 67e8acafc3fdd8f107f1d8d53c69ee6c27d3ed0a
Summary:
Similar to D63541483, modernises our Flow syntax support for our published ESLint config to use `hermes-eslint` (`hermes-parser`).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541856
fbshipit-source-id: 06cc5725faf5934fda07713ec1dac54ff9c32ddf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46696
Following D62161923, we began to lose sync with modern Flow syntax when Metro's `transformer.hermesParser` option is disabled. This config option loads Babel for transformation (instead of `hermes-parser`), which requires a Babel plugin to parse (not strip) Flow syntax.
This diff migrates us away from `babel/plugin-syntax-flow` (see also https://github.com/babel/babel/issues/16264) and uses the modern [`babel-plugin-syntax-hermes-parser`](https://www.npmjs.com/package/babel-plugin-syntax-hermes-parser) instead (a component of the modern Hermes Parser stack).
Following this change, new projects that unset `transformer.hermesParser` will compile.
Resolves https://github.com/facebook/react-native/issues/46601.
Changelog:
[General][Fixed] - Fix parsing of modern Flow syntax when `transformer.hermesParser = false` is configured in Metro config
Reviewed By: cipolleschi
Differential Revision: D63535216
fbshipit-source-id: d2c6ddec030d89e2698e03b76194cf3568d04e6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46699
Switch from legacy Babel Flow parser integrations to the Meta-maintained `hermes-eslint` and `babel-plugin-syntax-hermes-parser` packages (both part of the `hermes-parser` codebase).
Required to unblock D63535216.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D63541483
fbshipit-source-id: 04ccfa04c9a2b8c0a87ef1a5c38e952971838b77
Summary:
I've noticed that some users are reporting build failures due to warnings inside RNGP.
We do have `allWarningsAsErrors` set to true for everyone (also for users).
That's too aggressive, and can cause build failures which are not necessary. Let's keep it enabled only on our CI (when the `enableWarningsAsErrors` property is set).
## Changelog:
[INTERNAL] - RNGP: Read `enableWarningsAsErrors` property correctly
Pull Request resolved: https://github.com/facebook/react-native/pull/46657
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D63459601
Pulled By: cortinico
fbshipit-source-id: 0307e8d6771518038a5abe27ca5a993cb0a9f8c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46691
In Bridgeless, ReactSurface would only call `registerSurface` when it started, which did not match the behaviour seen in startSurface(WithConstraints). Instead, make all calls to start the surface go through the FabricUIManager Binding so we can correctly configure `setMountingOverrideDelegate` which is required for layout animations.
Changelog: [Android][FIxed] LayoutAnimations work on full new architecture
Reviewed By: cortinico
Differential Revision: D63533635
fbshipit-source-id: f6d3db020bb2d7245f7b14f2407271d76837d40c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46663
# Changelog: [Internal]
Now we can use the native module for persisting settings in React DevTools. Basically, this diff adds read / write implementations.
Reviewed By: huntie
Differential Revision: D62967060
fbshipit-source-id: c14ef056c8d7e30a23d2b84d1ad4fc0ad8eaaf34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46665
# Changelog: [Internal]
Looks like this module was missing on android for a while.
Reviewed By: huntie
Differential Revision: D63460309
fbshipit-source-id: 7146e7f2104f868d0f2b7271bd2c452608611ea3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46662
# Changelog: [Internal]
This should not have been a public API in the first place.
1. Moving this to `src/private`.
2. Removed some unused APIs, such as profiling settings.
Reviewed By: huntie
Differential Revision: D62965492
fbshipit-source-id: fb97eccaf647ce418f500b02d153263aa8632eee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46669
# Changelog: [Internal]
In React DevTools 6.0.0, settings manager is [no longer used](https://github.com/facebook/react/pull/30986), because the host of the Backend is responsible for settings persistance.
Also, `installHook()` call was removed from the top level of the JavaScript module and now we need to call `initialize()` explicitly.
The logic for persisting settings will be added in one of the next diffs at the top.
Reviewed By: huntie
Differential Revision: D62967059
fbshipit-source-id: 5022546aab02540f38c8d2e2f2e7dfeb82863f3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46694
The DevMenu module was never implemented on Android. This adds its implementation by mirroring the iOS implementation.
Fixes https://github.com/facebook/react-native/issues/46679
Changelog:
[Android] [Fixed] - Add missing Android implementation for DevMenu Module
Reviewed By: cipolleschi
Differential Revision: D63535172
fbshipit-source-id: 791e72b46b7d3264b98e85a73f2d9025dc3a2c7d
Summary:
If the module sets the method queue to the main queue, we should call it on the main queue if it contains some UI operations, otherwise it may lead to some undefined behavior.
## Changelog:
[IOS] [FIXED] - Fixes the exported synchronous method not being called on the method queue when it's the main queue
Pull Request resolved: https://github.com/facebook/react-native/pull/46344
Test Plan: The sync method should be called on the main queue if the module's method queue is main queue.
Reviewed By: cipolleschi
Differential Revision: D63532525
Pulled By: javache
fbshipit-source-id: 55baaa60af96bb1355d3641174f23bccd8eb9344
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46677
Since removing `react-native-community/cli` as a dependency in 0.76 the `npx react-native init` command isn't working. This is the deprecated way to run this command, but users should still expect it to work for now.
This now forks this kind of request to `npx react-native-community/cli init <args>` as described in the warning logs to the user.
Changelog: [Internal]
Issue: reactwg/react-native-releases#508
Reviewed By: cortinico
Differential Revision: D63467046
fbshipit-source-id: 84560bdae8d6f62629dee61da3cbbf544b9a83b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46623
I've just noticed that ReactFragment is not properly instantiating the `ReactDelegate` with a ReactHost
when on Bridgeless. This causes Fragments to crash when the app is on bridgeless mode.
Fixes https://github.com/facebook/react-native/issues/46566
Changelog:
[Android] [Fixed] - ReactFragment should properly instantiate ReactDelegate on Bridgeless
Reviewed By: mdvacca
Differential Revision: D63319977
fbshipit-source-id: 08256e35b2769e18df2d24f870ec5d98e5574f85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46683
Enabling these Microtask, ModernRuntimeScheduler and NativeViewConfigsInBridgelessMode in BridgeMode is risky and leads to bugs. In this diff I'm ensuring we only enable these flags when newArchitecture is enabled
changelog: [internal] internal
Reviewed By: shwanton
Differential Revision: D63503519
fbshipit-source-id: 4ef757834b8f7fba595b3394735f4b91335d7c98
Summary: Backing out the stack since a same crash that previously effected many apps appeared again, and there are changes soon landing that will add more conflicts.
Reviewed By: Abbondanzo
Differential Revision: D63493332
fbshipit-source-id: 4423bf41c793e00a0aa22d12a77bca69d3b1ae77
Summary: Backing out the stack since a same crash that previously effected many apps appeared again, and there are changes soon landing that will add more conflicts.
Reviewed By: Abbondanzo
Differential Revision: D63493331
fbshipit-source-id: 44658ffc99eb4ebc947f95bb6e6bde105ac88c93
Summary: Backing out the stack since a same crash that previously effected many apps appeared again, and there are changes soon landing that will add more conflicts.
Reviewed By: Abbondanzo
Differential Revision: D63493334
fbshipit-source-id: 175fc7b5b69aa2874c867e460ab102bb077a7cd8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46668
Small tweaks post-Kotlin-conversion:
- Make `overflow` a var
- Replace `+ -` with `-`
- Clean up properties and move up init block
- Iterate over entire allChildren array to clean up listeners
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63343964
fbshipit-source-id: 2e9022e2d7e54ac338d1003419d8959771f7f270
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46676
Changelog: [internal]
## Context
We recently "fixed" a problem in `MountingCoordinator` on Android where it would report that it doesn't have any pending transactions when, in fact, it does. The fix introduces a new method in that class to delay marking transactions as done until a mount hook is invoked for that surface.
That fixed the issue... by always reporting that there were pending transactions accidentally.
The reason for this bug is that the mount hook doesn't have access to the mounting coordinator of the surface if the surface is registered through some of the methods in `Binding.cpp` that don't add the surface to a registry. In that case, we can never mark the transactions as done and the mounting coordinator for those surfaces always report pending transactions incorrectly.
NOTE: this bug only affects apps that have the `fixMountingCoordinatorReportedPendingTransactionsOnAndroid` feature flag enabled.
## Changes
This fixes the issue by making sure that surfaces are always registered in the registry and that we can access their mounting coordinators in the mount hook to report the transactions as done.
Reviewed By: rubennorte
Differential Revision: D63466672
fbshipit-source-id: a621a12cda89a3ab7331d3c6a16c6cdfa9341821
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46678
I'm investigating some issues with surface management and noticed `surfaceHandlerRegistry_` is not updated in the bridgeless path when using ReactSurfaceView.
Adding a warning to help us validate this is resolved when we do eventually fix it.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63463521
fbshipit-source-id: 38995924588f1d71b9fc517c76a6e0c572fd0699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46674
bypass-github-export-checks
React DevTools no longer operates with just Fibers, it now builds its
own Shadow Tree, which represents the tree on the Host (Fabric on
Native, DOM on Web).
We have to keep track of public instances for a select-to-inspect
feature. We've recently changed this logic in
https://github.com/facebook/react/pull/30831, and looks like we've been
incorrectly getting a public instance for Fabric case.
Not only this, turns out that all `getInspectorData...` APIs are
returning Fibers, and not public instances. I have to expose it, so that
React DevTools can correctly identify the element, which was selected.
Changes for React Native are in
[D63421463](https://www.internalfb.com/diff/D63421463)
DiffTrain build for commit https://github.com/facebook/react/commit/d66fa02a303fc53d901bdb0d7bbdaec3e6774b19.
Test Plan: Sandcastle tests
Reviewed By: poteto
Differential Revision: D63453667
Pulled By: hoxyq
fbshipit-source-id: 21b1d5d4cd68b42748d4a785e0f28eaf5db57f21
Summary:
Changelog: [internal]
(this functionality hasn't been enabled in OSS yet, so no changelog necessary).
Fix https://github.com/facebook/react-native/issues/45122.
performance.mark is currently O(1) but performance.clearMark is O(n) (being n the number of entries in the buffer), which makes this operation very slow.
### Changes overview
- Created new `PerformanceEntryBuffer` abstraction with the following subtypes, that differ on how entries are stored:
- `PerformanceEntryCircularBuffer` - stores them in a ring buffer that was already implemented, removed key lookup cache (`BoundedConsumableBuffer`)
- `PerformanceEntryKeyedBuffer` - stores them in a `unordered_map`, allowing for faster retrieval by type
- `PerformanceEntryLinearBuffer` - a simple infinite buffer based on `std::vector`, currently used in a `PerformanceObserver`
- Created `PerformanceObserver` abstraction on native side.
- Created `PerformanceObserverRegistry` that collects active observers and forwards entries to observers that should retrieve them
- Moved some method implementations to `.cpp` files to reduce potential compilation time slowdown. As the `PerformanceEntryReporter` can be included from anywhere in the code, it will be beneficial to make header files as light as possible.
- Add comments to methods that note which standard is the method from/for.
- Added some `[[nodiscard]]` attributes
- Since the logic of routing entries to observers is moved to native side, JS side of the code got much simplified
- If ever needed, `PerformanceObserver` can be created from native-side
Standards covered:
- https://www.w3.org/TR/performance-timeline
- https://www.w3.org/TR/event-timing/
- https://w3c.github.io/timing-entrytypes-registry
- https://w3c.github.io/user-timing/
Pull Request resolved: https://github.com/facebook/react-native/pull/45206
Test Plan:
I've tested this e2e on IGVR and in the RNTester playground for the performance APIs. Everything works as expected.
There are also new unit tests for this.
C++ test results: https://www.internalfb.com/intern/testinfra/testconsole/testrun/8725724513169247/
Reviewed By: rshest
Differential Revision: D63101520
Pulled By: rubennorte
fbshipit-source-id: 5970b5c14692ff33ffda44a9f09067f6a758bdbe
Summary:
While developing my project with New Architecture enabled I've found out that properties `tintColor` and `progressViewOffset` of component `RefreshControl` don't apply on iOS. This happens due to the lack of handling of these properties in the `RCTPullToRefreshViewComponentView.mm` class.
The bug can be easily reproduced in RNTester app on RefreshControlExample.js screen, since it has property `tintColor="#ff0000"` (Red color), but RefreshControl renders with gray color:
<img width="300" alt="RefreshControlExample.js" src="https://github.com/user-attachments/assets/10931204-dbe8-4cbd-9adc-d0f38319febd">
<img width="300" alt="gray Refresh Control" src="https://github.com/user-attachments/assets/e5d088e8-b3f5-46b8-9284-9b452232ad10">
<br />
<br />
This PR is opened to fix that by applying `tintColor` and `progressViewOffset` props to `_refreshControl` in `RCTPullToRefreshViewComponentView.mm` class.
Fixes https://github.com/facebook/react-native/pull/46628
## Changelog:
[IOS][FIXED] - Fix applying of tintColor and progressViewOffset props for RefreshControl component with New Architecture enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/46628
Test Plan:
1. Run rn-tester app with New Architecture enabled on iOS
2. Open screen of RefreshControl component:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 48 49" src="https://github.com/user-attachments/assets/94a2d02d-f3e3-4e18-a345-87c22d4a2620">
3. Open `/packages/rn-tester/js/examples/RefreshControl/RefreshControlExample.js` file and change properties `tintColor` and `progressViewOffset` of RefreshControl components on the line 85:
<img width="300" alt="Снимок экрана 2024-09-24 в 22 01 19" src="https://github.com/user-attachments/assets/425826a6-d34c-4316-8484-e65f125a8b28">
4. check that your changes applied:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 54 46" src="https://github.com/user-attachments/assets/b97621f1-b553-48c9-bc81-e04a99a7e099">
Reviewed By: cortinico
Differential Revision: D63381050
Pulled By: cipolleschi
fbshipit-source-id: 4f3aed8bd7a1e42ce2a75aa19740fd8be1623c86
Summary:
This change fixes the workflow by using the right URL. I also added some logging for debugging.
## Changelog:
[Internal] - Fix Trigger E2E tests workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/46653
Test Plan: Tested the script locally and verified that it triggers the workflow.
Reviewed By: cortinico
Differential Revision: D63452098
Pulled By: cipolleschi
fbshipit-source-id: f44956071edb68046ed1cb74e286e8edbe0eb23a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46620
The following error was thrown when the test `packages/metro/src/integration_tests/__tests__/server-test.js` was running on Metro:
{F1816961963}
It led me to investigate why don't we wait for Metro to be torn down.
Currently we close metro by closing the http server that it launches.
```
const httpServer = await Metro.runServer(/* ... */);
httpServer.close(callback);
```
While we can listen to the callback fired when the server is closed, it only covers one of the systems running internally in metro. The systems that are not covered are:
* File watchers
* File map workers
* Dependency graph
* Bundler
And many systems that were themselves listening to the above like "eslint file map" or the "dependency analysis".
**These systems are closed by us _after_ the server is closed.** This means that a listener to `server.on('close'` would only get the indication where these systems has started to close rather than actually got closed.
https://www.internalfb.com/code/fbsource/[17e03bc6bd86]/xplat/js/tools/metro/packages/metro/src/index.flow.js?lines=359-361
This diff introduces a way to wait for all of metro to be closed.
In this diff I use that new way of listening to Metro closure to get rid of the jest test warning mentioned above in `packages/metro/src/integration_tests/__tests__/server-test.js`:
```
let serverClosedPromise;
beforeEach(async () => {
config = await Metro.loadConfig({
config: require.resolve('../metro.config.js'),
});
let onCloseResolve;
serverClosedPromise = new Promise(resolve => (onCloseResolve = resolve));
httpServer = await Metro.runServer(config, {
reporter: {update() {}},
onClose: () => {
onCloseResolve();
},
});
});
afterEach(async () => {
httpServer.close();
await serverClosedPromise;
});
```
Changelog: [Feature] add `onClose` to `Metro.runServer` configuration allowing to wait for metro and all associated processes to be closed.
Reviewed By: huntie
Differential Revision: D61594124
fbshipit-source-id: e3c50ef986077503bce0caa42a9f9430efc65272
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46632
Changelog: [General][Added] Add Playground to RNTester for testing out features & submitting reproducers.
**Context**
- Adding the Playground from Catalyst to RNTester
- This should help folks test React Native features for a particular version
**Change**
- Add a new playground component to RNTester
- Add a new reducer action for opening an example from navbar press
- Fixed typing issues
- Add icon from this fb asset pack: https://www.internalfb.com/assets/set/facebook_icons/nucleus-beaker/variant_outline-size_24?q=beaker
- Matched background color using this imagemagick script
**dark**
```
convert input.png -fill 'rgb(178,180,186)' -colorize 100% output.png
```
**light**
```
convert input.png -fill 'rgb(81,82,84)' -colorize 100% output.png
```
Reviewed By: NickGerleman
Differential Revision: D61972594
fbshipit-source-id: 4a5523a84a6ef09d3266d5f56825907bd3fbe4b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46638
This is annoying, but in the next diff that fixes a bug I need to test using the default warning filter instead of a mock (really, all this mocking is terrible, idk why I did it this way).
Unfortunately, in Jest you can't just reset mocks from `jest.mock`, `restoreMocks` only resets spies and not mocks (wild right).
So in this diff I converted all the `jest.mock` calls to `jest.spyOn`. I also corrected some of the mocks that require `monitorEvent: 'warning',` like the warning filter sets.
I also added a test that works without the fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349615
fbshipit-source-id: 4f2a5a8800c8fe1a10e3613d3c2d0ed02fca773e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46636
Adds more integration tests for LogBox (currently incorrect, but fixed in a later diff).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349614
fbshipit-source-id: 8f5c6545b48a1ed18aea08d4ecbecd7a6b9fa05a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46639
These tests were skipped when we were switching to component stacks, which also hid a bug later in the stack. Re-enable them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349616
fbshipit-source-id: ccde7d5bb3fcd9a27adf4af2068a160f02f7432a
Summary:
X-link: https://github.com/facebook/yoga/pull/1701
Pull Request resolved: https://github.com/facebook/react-native/pull/46630
I would like to write some tests for box sizing that will drive a lot of my development as I implement content box. To do that, I need this publicly exposed. Obviously not that ideal since this currently does not do anything. Maybe we can name the value in such a way that its clear it is in development?
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63135970
fbshipit-source-id: 7520823bf925364eae45341531e012e80ec92284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46629
If we clipped and had no border or corner radius we would end up hitting this path every time. We can optimize this a bit to avoid that.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63299597
fbshipit-source-id: 90031f964b7669049a4a2efe00a553c888d28cd7
Summary:
This PR fixes the retrieval of react native package name to retrieve it from package.json.
This fixes the annoying message in codegen that poped up when installing pods:
```
[Codegen] Found react-native-macos
[Codegen] CodegenConfig Deprecated Setup for react-native-macos.
The configuration file still contains the codegen in the libraries array.
If possible, replace it with a single object.
BEFORE:
{
// ...
"codegenConfig": {
"libraries": [
{
"name": "libName1",
"type": "all|components|modules",
"jsSrcsRoot": "libName1/js"
},
{
"name": "libName2",
"type": "all|components|modules",
"jsSrcsRoot": "libName2/src"
}
]
}
}
AFTER:
{
"codegenConfig": {
"name": "libraries",
"type": "all",
"jsSrcsRoot": "."
}
}
```
## Changelog:
[GENERAL] [CHANGED] - get react-native package name from package.json in codegen script
Pull Request resolved: https://github.com/facebook/react-native/pull/46604
Test Plan: Install pods
Reviewed By: cortinico
Differential Revision: D63335543
Pulled By: arushikesarwani94
fbshipit-source-id: 0470e54f0fc7aa962918c889855c52648d11e32d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46634
The PointerEventPointerOverOut.js test case is broken due to a changed assumption about the name of the native tag property (`_nativeTag` vs. `__nativeTag`). This fixes the broken assumption.
## Changelog
[General][Fixed] Fixed issue with W3C PointerEvents tests
Reviewed By: NickGerleman
Differential Revision: D63336621
fbshipit-source-id: b54270f1c1232de6845ef73cac52f06b9a85539c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46617
This changes fixes the Increment/Decrement accessibility actions on iOS with the New Architecture.
## Changelog
[iOS][Fixed] - Make sure that the Increment and Decrement accessibility actions works on iOS
Reviewed By: javache
Differential Revision: D63263830
fbshipit-source-id: 99dca14a002e098db2d3b0e268af32cdab6ce786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46603
Was debugging this test for the mounting instruction changes, and found some opportunities to clean this up.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63258342
fbshipit-source-id: f7e6be58474f112993232ce5859ccb160f050ae8
Summary:
A typo means TextLayoutManager will incorrectly measure text as if `LineBreaker.HYPHENATION_FREQUENCY_NORMAL` is set, instead of the correct default of `LineBreaker.HYPHENATION_FREQUENCY_NONE` which we use to display the `TextView`. This causes truncation if hyphenation would have caused text to be shorter than if not hyphenated. Fix the typo.
Changelog: [Android][Fixed] - Fix measuring text with incorrect hyphenationFrequency
Reviewed By: mellyeliu
Differential Revision: D63293027
fbshipit-source-id: baaf2ae2676548cf0815ae96e324af273be6f99e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46586
When Paint.strokeWidth is set to 0 its not actually 0 but "hairline mode" so the fix is just to make outline not draw at all when outlineWidth = 0 {F1879399325}
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D63136220
fbshipit-source-id: 81ef7ce0b72158c6b7c332191d332008c5a919b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46598
Changelog: [General][Changed] - Bring back shouldSkipStateUpdatesForLoopingAnimations feature flag
Facebook
Also bring back `skip_state_updates_for_looping_animations` MC. This will allow the experiment to participate in a holdout properly.
Reviewed By: GijsWeterings
Differential Revision: D63252185
fbshipit-source-id: 89bc9321b12f07bd9b3b52c4fc1021d34594ebc0
Summary:
On iPadOS, users can change the kind of keyboard displayed onscreen, going from normal keyboard, to split keyboard (one half on the left of the screen, one half on the right), or a floating keyboard that you can move around the screen.
When a non-normal kind of keyboard is used, `<KeyboardAvoidingView>` calculations are all wrong and, depending on the `behavior` prop, can make your screen completely hidden.
This PR attempts to detect that the keyboard is not the "normal displayed-at-bottom-of-screen" keyboard, and forces `enable={false}` if this happens.
The approach of comparing the keyboard width with the window width comes from this comment: https://github.com/facebook/react-native/issues/29473#issuecomment-696658937
A better fix might be to detect the kind of keyboard used, but this involves native code changes and I do not know iOS enough to do that. In addition, I have not found an easy way to do it using iOS APIs after a quick search.
I also chose to cache the window width as a class attribute. Maybe this is not needed as `Dimensions.get('window').width` is very fast and can be called on every keyboard event?
This fixes https://github.com/facebook/react-native/issues/44068 and https://github.com/facebook/react-native/issues/29473
## Changelog:
[IOS] [FIXED] - Fix `<KeyboardAvoidingView>` with floating keyboard on iPadOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44859
Test Plan:
Tested using RNTester and the "Keyboard Avoiding View with different behaviors" example.
Before:
https://github.com/facebook/react-native/assets/42070/111598a3-286c-464d-8db8-73afb35cd7f9
After:
https://github.com/facebook/react-native/assets/42070/0b3bc94f-8b67-4f42-8a83-e11555080268
Reviewed By: cortinico
Differential Revision: D62844854
Pulled By: cipolleschi
fbshipit-source-id: 577444be50019572955a013969d78178914b5b8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46590
This API should not be part of the ShadowView header, since the class is only used by Differentiator. The ShadowView header should contain public API's that the mounting layer can consume.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63148522
fbshipit-source-id: 0545777fd311424ccd2d66de8b47b5591e8175f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46589
This is a useful too for debugging ShadowTree mutations, but was broken due to some recent build changes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63099720
fbshipit-source-id: 9ae5ee062ef9a6a99b2517e4eedd286cd6259fbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46597
Changelog: [internal]
Adding explicit metadata to feature flags so they're easier to manage:
* Purpose: to indicate why the feature flags are added.
* Release: gating features we don't want to expose in certain environments yet (e.g.: Fabric).
* Experimentation: changes that we want to test before enabling them broadly. Should generally be short lived.
* Operational: flags that enable certain behaviors in certain environments (e.g.: debugging logs).
* Date added: only for experimental flags, so we know how long we've been waiting to fully roll out the change (without having to go through the repository history, which could've been changed due to refactors).
Reviewed By: javache
Differential Revision: D62972237
fbshipit-source-id: ab51e989a2cddb8dc52197238b638609d30002f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46567
Switch to a simpler data structure which avoids locking and doesn't require copies when iterating. This is more consistent with other listener arrays in React Native.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62872893
fbshipit-source-id: b0ce6a904d25057f0217f7de7ec2928c8b2d1f34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46542
If `bufferedRuntimeExecutor_` is referenced beyond the lifetime of the ReactInstance, it may point to invalid memory. RuntimeScheduler already holds weak references to the actual runtime, so it's safe to retain that instead.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D62748768
fbshipit-source-id: 1cd8fcb050dd561e7d54a11d91c89eda3a5ddaaa
Summary:
This PR is a quality-of-life improvement, adds colors to codegen output:

Makes it a lot easier to grasp what's going on in the actions taken by codegen.
## Changelog:
[GENERAL] [ADDED] - Add color formatting to codegen output
Pull Request resolved: https://github.com/facebook/react-native/pull/46557
Test Plan:
1. Run codegen
2. Expect colored output
Reviewed By: christophpurrer
Differential Revision: D63031248
Pulled By: cipolleschi
fbshipit-source-id: e86bc72f16582562dc9f1e3b55dc69af4c7838f5
Summary:
Add tests to simplify running Maestro e2e tests locally.
Thanks to these scripts, users can just, from the root folder:
```sh
yarn install
cd packages/rn-tester
# build android for testing
yarn e2e-build- android
# run tests on android
yarn e2e-test-android
# build iOS for testing
yarn e2e-build-ios
# run tests on iOS
yarn e2e-test-ios
```
This is a preliminary step for a future umbrella issue. We can also use these command in CI to simplify the scripts.
## Changelog:
[Internal] - add script to simplify e2e testing
Pull Request resolved: https://github.com/facebook/react-native/pull/46545
Test Plan: Tested the command locally
Reviewed By: cortinico
Differential Revision: D62879105
Pulled By: cipolleschi
fbshipit-source-id: 6f68aebb3f8112302a458ca9e118180d3dbaf180
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46576
We automatically add this handler in `addAnimatedEventToView` but we do not remove it in `removeAnimatedEventFromView`, which causes us to leak it. This is especially bad as we attach and detach the event handler multiple times while rendering.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D63029768
fbshipit-source-id: 9ef2bc6887fecb7ab448af4dee94463f8be27768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46544
Experiments with `completeReactInstanceCreationOnBgThreadOnAndroid` have shown a native crash in this code path, but it also existed previously.
I believe this is due to the ordering of ReactInstance teardown: we first destroy the ReactInstance, and only then destroy the reference to it in mCreateReactInstanceTaskRef. When using the immediate executor and completeReactInstanceCreationOnBgThreadOnAndroid, we read the react instance from the task, which may no longer be valid at this point. Resetting the task at the earliest point should mitigate the issue.
Changelog: [Internal]
Reviewed By: markv
Differential Revision: D62872625
fbshipit-source-id: 5aaccd53433ca806d2b93f7e3dd2bcf9bf8c09a8
Summary:
This change setups homebrew on Ubuntu. Due to https://github.com/actions/runner-images/issues/6283, brew is not in the PATH anymore.
## Changelog:
[Internal] - Setup homebrew in ubuntu machine
Pull Request resolved: https://github.com/facebook/react-native/pull/46575
Test Plan: Can't test before it lands. :(
Reviewed By: cortinico
Differential Revision: D63027253
Pulled By: cipolleschi
fbshipit-source-id: e0b3a3c1a2a7b0659f0c1f57c45d8d42a74734a1
Summary:
This change configure the Test All job to enable the E2E tests with an input parameter.
Then it adds another workflow that is triggered on PRs when someone posts the "/test-e2e" comment.
## Changelog:
[Internal] - Let users run E2E tests on a specific PR comment
Pull Request resolved: https://github.com/facebook/react-native/pull/46572
Test Plan: This kind of things can only be tested once the PR lands, as workflows that are triggered by comments runs only from the main branch.
Reviewed By: cortinico
Differential Revision: D63021786
Pulled By: cipolleschi
fbshipit-source-id: 95b271f6de658ca208c773429fedef2a36417752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46559
There is an edge case when we navigate away from a screen that contains a scroll view where one of the UISCrollViewDelegates does not implement the scrollViewDidEndDecelerating method.
This happens because the Macro used assumes that the event that we are forwarding is the actual method from where the macro is called. Which is not true when it comes to `didMoveToWindow`.
This change fixes that by explicitly expanding the macro in this scenario and passing the right selector.
## Changelog:
[iOS][Fixed] - Fixed a crash when navigating away from a screen that contains a scrollView
## Facebook
This should fix T201780472
Reviewed By: philIip
Differential Revision: D62935876
fbshipit-source-id: e29aadf201c8066b5d3b7b0ada21fa8d763e9af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46560
The `init` command should still keep on working till 2024-12-31
This handles this scenario as currently `npx react-native@next init` is broken.
Changelog:
[Internal] [Changed] - Clarify init behavior for 0.76
Reviewed By: huntie, cipolleschi
Differential Revision: D62958747
fbshipit-source-id: ce3d974df55162720d59a7ece7fcb816e257185d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46540
changelog: [internal]
avoid calling `runEventLoopTick` and execute task directly. runEventLoopTick is not designed to be called on re-entries.
Reviewed By: rubennorte
Differential Revision: D62871782
fbshipit-source-id: 259514d05eebed2e09d54233729994e56f2aa1a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46551
We crash if we pass a shadow color with 0 alpha due to some divide by 0 logic. This fixes that for inset and outset shadows and adds a test for that case.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62899047
fbshipit-source-id: 2aff1d016dd97bed024df1c3f89bcc62e49f0306
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46563
Changelog: [internal]
Our current implementation of view preallocation on Android runs very early in the frame (during the `animation` stage, after `input` and before `traversal`). In that implementation, we check the remaining time in the frame and we allocate half of that time for view preallocation.
This logic can make us drop frames unnecessarily, if the work that we need to do after this allocated time is longer than we expect. Because we don't know how long the `traversal` stage will be, we don't account for that time at all (or, at best, we do only use half of the remaining time).
This creates a feature flag to move view preallocation outside of the choreographer, so we can compute the remaining time considering all the work we did in the frame, and not just the work we did in the input stage.
Reviewed By: javache
Differential Revision: D62962341
fbshipit-source-id: 69aaeecc8596906e61b47af9adad23c1075a091a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46565
UIManager is initialized elsewhere in NativeAnimatedNodesManager so this is no longer required
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D62958646
fbshipit-source-id: af77ddbbc65124ed29d301340ad339d2a916f58c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46564
Changelog: [internal]
I incorrectly set up an experiment to fix reported scroll position during smooth scroll animations on Android in D59233069. It was incorrect because I fixed the issue in "control", and I re-enabled the bug in "test".
That means we actually shipped the fix the moment we set up the experiment.
We can just apply the fix ungated.
Reviewed By: Abbondanzo
Differential Revision: D62965254
fbshipit-source-id: edf855619ff9ede6fd406f7f19b3c504ce89f1d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46561
Changelog: [internal]
We have some logic in `MountItemDispatcher.tryDispatchMountItems` to recursively call itself for as long as there are new items to mount in the general queue. This queue is copied and processed every time `tryDispatchMountItems` is called, but it's possible that during this time new mount operations are added (either from JS or from the mount operations themselves).
This logic can cause frame drops, as we could be finish processing the current frame without processing new mount items (we could do that in the next frame, and in many cases it's just pre-rendering work and state updates that the user can't perceive anyway).
This creates a feature flag to test disabling this behavior and only process whatever mount items are queued at the start of the frame.
Reviewed By: sammy-SC
Differential Revision: D62958009
fbshipit-source-id: ca038c827715411375410215deb5d5e374f5fdb4
Summary:
Regarding the [issue](https://github.com/facebook/react-native/issues/44755) where the app sometimes crashes due to race condition when two reloads overlap in unfortunate way. This PR fixes it in some way by introducing throttling on reload command. For now I set it to 700ms as I was still able to reproduce it on 500-550ms for provided repro in the issue. The problem may still happen for bigger apps where reload may take more time to finish.
## 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
-->
[GENERAL] [FIXED] - throttle reload command
Pull Request resolved: https://github.com/facebook/react-native/pull/46416
Test Plan: I've tested on provided repro and a smaller app trying to brake it.
Reviewed By: huntie
Differential Revision: D62847076
Pulled By: cipolleschi
fbshipit-source-id: 6471f792d6b692e87e3e98a699443a88c6ef43cd
Summary:
This PR adds iOS ifdefs to `RCTUIManager` to subscribe to orientation changes on this platform.
The `UIDeviceOrientationDidChangeNotification` symbol is only available there.
## Changelog:
[IOS] [FIXED] - subscribe to orientation changes in RCTUIManager only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46531
Test Plan: CI Green
Reviewed By: philIip
Differential Revision: D62864013
Pulled By: cipolleschi
fbshipit-source-id: 341df9ac765735273378d017b63fcb7a4d8e98e5
Summary:
Analyze code was still using the CIRCLECI env variable to retrieve the PR number.
This change uses the github one and also removes a duplicated flow check
## Changelog:
[Internal] - Remove duplicated flow check and use gh PR number rather than CircleCI one
Pull Request resolved: https://github.com/facebook/react-native/pull/46548
Test Plan: Tested locally and in CI
Reviewed By: NickGerleman
Differential Revision: D62883758
Pulled By: cipolleschi
fbshipit-source-id: 0c7e97ea9caf4465972424e0b69a899ecfd07095
Summary:
This chang introduces a patch file that can be applied to run the E2E tests in CI.
From the root folder `react-native`, a user can just run:
```sh
git apply packages/rn-tester/scripts/enable-e2e-tests.patch
```
And then add a commit to their PR to see whether the newly added E2E tests are actually running
## Changelog:
[Internal] - add patch to simplify running E2E tests in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/46546
Test Plan: Tested locally
Reviewed By: NickGerleman
Differential Revision: D62880559
Pulled By: cipolleschi
fbshipit-source-id: 19d639b2641aaa50e4f3e0753018d426d2da81c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46525
While debugging I noticed that my setTimout was being cleared by someone else. Upon further inspection I found NativeAnimatedHelper which was mismatching setImmediate timer handle with a clearTimeout. This isn't safe and needs to be fixed.
I used this to rename the timer to be more clear to reduce the changes of mismatches.
Changelog:
[General][Fixed] - Fix setImmediate/clearTimeout mismatch in NativeAnimatedHelper that could clear an unrelated setTimeout.
Reviewed By: javache, yungsters
Differential Revision: D62775703
fbshipit-source-id: c1669c60bd08f13a59dd6159be2f471a6c1beebd
Summary:
There is a crash on iOS when trying to show an action sheet, but `RCTPresentedViewController` returns null. The code attempts to print an error but fails when casting values.
The issue is that some values, like _title_ or _message_ could be `nil`, which causes a failure when casting them to use in `RCTLogError`.
Fixes: https://github.com/facebook/react-native/issues/46549
## Stacktrace:
```
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[0]'
0 CoreFoundation 0x00000001804ae0f8 __exceptionPreprocess + 172
1 libobjc.A.dylib 0x0000000180087db4 objc_exception_throw + 56
2 CoreFoundation 0x000000018051c84c -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 660
3 CoreFoundation 0x00000001804ac9cc +[NSDictionary dictionaryWithObjects:forKeys:count:] + 48
4 AwesomeProject.debug.dylib 0x0000000106ed9138 __61-[RCTActionSheetManager showActionSheetWithOptions:callback:]_block_invoke_4 + 340
5 libdispatch.dylib 0x0000000103f3bec4 _dispatch_call_block_and_release + 24
6 libdispatch.dylib 0x0000000103f3d73c _dispatch_client_callout + 16
7 libdispatch.dylib 0x0000000103f4d3f8 _dispatch_main_queue_drain + 1228
8 libdispatch.dylib 0x0000000103f4cf1c _dispatch_main_queue_callback_4CF + 40
9 CoreFoundation 0x000000018040e960 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
10 CoreFoundation 0x0000000180409078 __CFRunLoopRun + 1936
11 CoreFoundation 0x00000001804084d4 CFRunLoopRunSpecific + 572
12 GraphicsServices 0x000000018ef2aae4 GSEventRunModal + 160
13 UIKitCore 0x00000001853d0a28 -[UIApplication _run] + 868
14 UIKitCore 0x00000001853d46b0 UIApplicationMain + 124
15 AwesomeProject.debug.dylib 0x0000000106d47bec __debug_main_executable_dylib_entry_point + 96
16 dyld 0x0000000102fbd544 start_sim + 20
17 ??? 0x00000001030620e0 0x0 + 4345700576
18 ??? 0x4e6d800000000000 0x0 + 5651313844908195840
```
## Changelog:
[IOS] [FIXED] - Fix ActionSheetIOS crash `attempt to insert nil object from objects`
Pull Request resolved: https://github.com/facebook/react-native/pull/46550
Test Plan:
I created an example project.
Example: https://github.com/RodolfoGS/react-native-fix-ios-actionsheet
### How to reproduce using the example above:
1. `git clone git@github.com:RodolfoGS/react-native-fix-ios-actionsheet.git`
2. `cd react-native-fix-ios-actionsheet`
3. `npm install`
4. `npm run ios`
5. Tap on _Show Action Sheet_ button on the app
6. Notice the crash
### Steps to create the example from scratch and reproduce the crash:
1. `npx react-native-community/cli@latest init AwesomeProject`
2. `cd AwesomeProject`
3. Install `patch-package` and add this patch to simulate a situation where `RCTPresentedViewController` returns null (https://github.com/RodolfoGS/react-native-fix-ios-actionsheet/blob/main/patches/react-native%2B0.75.3.patch)
4. `npm run ios`
5. Tap on _Show Action Sheet_ button on the app
6. Notice the crash
Reviewed By: caodoan
Differential Revision: D62897554
Pulled By: philIip
fbshipit-source-id: fb978c4648a6c4e36c609783e59367a5997e42cb
Summary:
Fix platform color on android with linear gradient.
## Changelog:
[ANDROID] [FIXED] - Linear gradient with platform colors
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46290
Test Plan: Added example and testcases
Reviewed By: mdvacca
Differential Revision: D62277253
Pulled By: NickGerleman
fbshipit-source-id: 376ee5ebde61f3cb1ed32e82f71ad5479ebc50a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46518
## Summary
When a view config can not be found, it currently errors with
`TypeError: Cannot read property 'bubblingEventTypes' of null`. Instead
invariant at the correct location and prevent further processing of the
null viewConfig to improve the error logged.
## How did you test this change?
Build and run RN playground app referencing an invalid native view
through `requireNativeComponent`.
Changelog: [General][Fixed] Improved error message when no view config is found.
DiffTrain build for commit https://github.com/facebook/react/commit/26855e4680dedb21f2c73a069ed691822a242db1.
Test Plan: Sandcastle tests
Reviewed By: jackpope
Differential Revision: D62760863
Pulled By: javache
fbshipit-source-id: c71dacc48fe8795b28840cfb3f53c1f9fc664a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46528
This is needed for a script that needs to switch over all possible type annotations in the codegen schema.
Reviewed By: GijsWeterings
Differential Revision: D62805189
fbshipit-source-id: 8fd113f4ad0b695b38e92b8d0fc45a991f597fb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46538
changelog: [internal]
When we run synchronous task, it was able to get into a state where RuntimeScheduler stopped executing tasks in the queue and it wouldn't get unstuck. This appeared as non-responsive app.
The problem was that `isEventLoopScheduled_` was not being restarted in case `syncTaskRequests_` was bigger than 0. There is a unit test covering this scenario.
Reviewed By: rubennorte
Differential Revision: D62756582
fbshipit-source-id: 878b8445baea05e8b9eddae05ca0d11d5e93acb6
Summary:
this PR fixes a few small ESLint issues that were showing up under PR diffs.
## Changelog:
[INTERNAL] [FIXED] - Fix various ESLint issues
Pull Request resolved: https://github.com/facebook/react-native/pull/46379
Test Plan: ran JS tests + linter; all passing
Reviewed By: cipolleschi
Differential Revision: D62385788
Pulled By: NickGerleman
fbshipit-source-id: b33d7ade4696bbaed2ac1a3fc2e0b3dff9bb04b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46547
While testing the 0.76 RCs, it was initially unclear to me that `npx react-native init` was both deprecated and **removed** (performs a noop). Update message for clarity.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D62881266
fbshipit-source-id: b9017e63360c7aee5483d437ce1510be9a14ef42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46533
Changelog: [internal]
When defining overrides for feature flags, it's common to have this pattern:
```javascript
myFeatureFlag: () => someCondition ? value : defaultValueForFlag
```
But it's not always obvious how to get the default value defined in the feature flag system. This modifies the API so we receive the default value as a parameter to simplify the logic:
```javascript
myFeatureFlag: (defaultValueForFlag) => someCondition ? value : defaultValueForFlag
```
Reviewed By: mdvacca, rshest
Differential Revision: D62853299
fbshipit-source-id: 9421e31d00662e2a23f1e3fb43bdc9f5cf03fdf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46530
Changelog: [internal]
There's nothing preventing these modules from being `flow strict` instead of `flow strict-local`, so we can just make the change.
Reviewed By: mdvacca
Differential Revision: D62763719
fbshipit-source-id: 1821ef9ad2e8dc67b754eccc77e35ef34400ca0a
Summary:
Following the discussion on https://github.com/facebook/react-native/issues/46505, this PR aims to allow mixte type configuration (String and/or Array of String) during the post installation of pods.
## 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
-->
[IOS] [FIXED] - allow pods mixte type settings on post-install
Pull Request resolved: https://github.com/facebook/react-native/pull/46536
Test Plan: `packages/react-native/scripts/cocoapods/__tests__/utils-test.rb` test suits was updated to support array and works as expected
Reviewed By: shwanton
Differential Revision: D62870582
Pulled By: cipolleschi
fbshipit-source-id: c0ace6d9d20e6609ceae5aafd236d97fc9e86ddf
Summary:
This pull request replaces the use of mkdirp with Node.js's built-in fs.mkdirSync({ recursive: true }) function, which is available in Node.js version 10.12.0 and above. This change reduces the number of external dependencies and simplifies the codebase by using the native capabilities of Node.js.
The motivation behind this change is to remove the unnecessary mkdirp dependency, as Node.js natively supports recursive directory creation since version 10.12.0. This streamlines the code and reduces the reliance on external libraries.
## Changelog:
[INTERNAL] [REMOVED] - Replaced mkdirp with fs.mkdirSync({ recursive: true }) in build scripts and codegen. Requires Node.js 10.12.0 and above.
Pull Request resolved: https://github.com/facebook/react-native/pull/46388
Test Plan: I ran the build and codegen scripts locally with Node.js version 10.12.0 and above after replacing mkdirp, ensuring the scripts work as expected. No issues were encountered, and all processes, including directory creation and file handling, function correctly.
Reviewed By: cortinico
Differential Revision: D62852488
Pulled By: huntie
fbshipit-source-id: 76f44102a80b499521c156308d276a17d279ce38
Summary:
This PR does some further cleanup on the flags passed to cocoapods.
I've moved `boost_compiler_flags` and `folly_dep_name` to `helpers.rb` file.
## Changelog:
[INTERNAL] [FIXED] - move boost compiler flags and folly dep name to centralized config
Pull Request resolved: https://github.com/facebook/react-native/pull/46513
Test Plan: CI Green
Reviewed By: cortinico
Differential Revision: D62846105
Pulled By: cipolleschi
fbshipit-source-id: dff07ddb49f1f4b559125f2ed8508b32f08d4975
Summary:
This PR is a small fix for the indentation of `tsconfig.json`
## Changelog:
[INTERNAL] [FIXED] - fix for the indentation of `tsconfig.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/46529
Test Plan: N/A
Reviewed By: cortinico
Differential Revision: D62845892
Pulled By: cipolleschi
fbshipit-source-id: 52a0309027350cd9bba8c2c158887b23ea093876
Summary:
Due to `set -e` shell option, missing `xcrun` may cause the setup script to fail on Linux.
Also makes the script continue even if the glog `./configure` call does not succeed.
### Related
- Follow-up to https://github.com/facebook/react-native/pull/44417
## Changelog:
- [Internal] [Fixed] - react-native: make missing xcrun not throw in `ios-configure-glog.sh`
- [Internal] [Fixed] - react-native: accept failing glog ./configure in `ios-configure-glog.sh`
Pull Request resolved: https://github.com/facebook/react-native/pull/46358
Reviewed By: cortinico
Differential Revision: D62851737
Pulled By: cipolleschi
fbshipit-source-id: 3ed76a81b6f428a1697c364698a0dfdd3bbb74f2
Summary:
In this PR https://github.com/facebook/react-native/issues/45560 the BUNDLE_COMMAND initialization was removed while it is still being used. Without it, building from Xcode throws unknown options error for Physical iOS devices.
I have just brought back the initialization from the PR before that, so the bundle phase is successful.
## Changelog:
[IOS][Fixed] - Add back the BUNDLE_COMMAND
Pull Request resolved: https://github.com/facebook/react-native/pull/46495
Test Plan: I have bundled release builds in Xcode. Everything seems to be fine.
Reviewed By: cortinico
Differential Revision: D62846877
Pulled By: cipolleschi
fbshipit-source-id: 3f07e8c0bc5acf98177582f1fee9a55ae77b31a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46527
Changelog: [Internal]
**Context**
- `DefaultTurboModuleManagerDelegate.kt` was being stripped by redex since there was no direct dependency.
- This was causing a crash in prod builds
```
Trace: java.lang.RuntimeException: Unable to create application com.facebook.mobilehome.MobileHomeAppShell: java.lang.ClassNotFoundException: Didn't find class "com.facebook.react.defaults.DefaultTurboModuleManagerDelegate" on path: DexPathList
```
**Change**
- Annotate `DefaultTurboModuleManagerDelegate.kt` with `DoNotStripAny`
- Don't strip `DoNotStripAny` annotated classes
Reviewed By: mdvacca
Differential Revision: D62766339
fbshipit-source-id: 7d9bfa04e252c392b94f739443bacf34f593e481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46166
## This Diff
This removes some of the legacy utilties used for background manipulation, no longer used anywhere (and very rarely used externally from some previous tests). These conflict with BackgroundStyleApplicator, which should be used instead.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog:
[Android][Breaking] - Remove ReactViewBackgroundManager and ReactViewBackgroundDrawable
Reviewed By: sammy-SC
Differential Revision: D61658084
fbshipit-source-id: 611f6d78fa4859574c063e9f0395c3dadc1588cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46168
## This Diff
This removes the legacy path from ReactScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658081
fbshipit-source-id: d6db43e25faf8e1ebd42d2816c7a915b3ed9404e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46161
## This Diff
This removes the legacy path from ReactHorizontalScrollView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61658082
fbshipit-source-id: 98cab5dfcad8beee6d131fcfe122313730a6f665
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46162
## This Diff
This removes the legacy path from ReactEditText and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658080
fbshipit-source-id: 6ac7c5ed230e44fe307640a730e076b903e0674a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46171
## This Diff
This removes the legacy path from ReactTextView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61658083
fbshipit-source-id: b753d4eb45091aa31ea870a684c35b71c1ee5036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46159
## This Diff
This removes the legacy path from ReactViewGroup and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61657251
fbshipit-source-id: 6d00a1cac79450d306cf28446e6397d31ceffb19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46167
## This Diff
This removes the legacy path from ReactImageView and its view manager.
## This Stack
This removes the non-Style-applicator background management paths of the different native components. There have been multiple conflicting changes, and bugs added bc harder to reason about, which motivates making this change as soon as possible. This also lets us formalize guarantees that BaseViewManager may safely manipulate background styling of all built in native components.
There is one still known issue, where BackgroundStyleApplicator does not propagate I18nManager derived layout direction to borders (compared to Android derived root direction). This is mostly an issue for apps that with LTR and RTL context, or force a layout direction, which I would guess is relatively rare, so my plan is to forward fix this later this by enabling set_android_layout_direction which will solve that problem mopre generically.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61657253
fbshipit-source-id: 96cf1160e466de78c2f133f0e4fb2d9b2e7cf478
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46524
There's an interesting behavior in Animated where we effectively perform an O(N + M) traversal of the Animated graph, calling `__makeNative` on each "input", which in turn tends to call `__makeNative` on each "output" (so we revisit the current node M times when calling `__makeNative` on the M inputs). In practice, the behavior is still O(N), because M is small and finite (most Animated nodes have 1 or 2 inputs).
All that said, some platforms (e.g., react-native-windows) rely on this revisiting behavior, where on the first visit, we recurse the node to its inputs, and on the subsequent visit, we update the `_platformConfig` value without recursion (see https://github.com/facebook/react-native/pull/32736 for the original change adding platformConfig).
A recent change to AnimatedWithChildren (https://github.com/facebook/react-native/pull/46286) eagerly invokes `__getNativeTag` on AnimatedWithChildren in the initial recursion step, which forces materialization of the NativeAnimated node *before* it's `_platformConfig` is set.
There is certainly some refactoring that needs to be done to improve all this, but for now, this change reverts to delay the call to `__getNativeTag` until after at least one `__makeNative` occurs on an input.
## Changelog
[General][Fixed]: Order of operations related to platformConfig propagation in NativeAnimated
Reviewed By: yungsters
Differential Revision: D62768179
fbshipit-source-id: ca9d911503e0630bc3a1309b21f9686aa77ac8b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46509
With ARG_DISABLE_HOST_LIFECYCLE_EVENTS it's possible to conditionally set mDisableHostLifecycleEvents when the ReactFragment gets created.
## Changelog:
[Android][Fixed] ARG_DISABLE_HOST_LIFECYCLE_EVENTS in ReactFragment to allow unmounting a surface without destroying ReactHost.
Reviewed By: rozele
Differential Revision: D62714185
fbshipit-source-id: b6518ff67a9644421b8fe9c7cdc2aa6d62a23651
Summary:
This PR adds an ifdef to declare `supportedInterfaceOrientations` only on iOS as this property does not affect other platforms causing a build issue.
## Changelog:
[IOS] [ADDED] - declare supportedInterfaceOrientations only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46512
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62754746
Pulled By: javache
fbshipit-source-id: e2ca5d96cba87e611c48a87f10bf7831e9051646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46508
Changelog: [internal]
This cleans up the "fixMissedFabricStateUpdatesOnAndroid" feature flag and enables the fix permanently.
This fixes some state updates in the Fabric shadow tree being missed in some edge cases.
See https://github.com/facebook/react-native/pull/45236 for context.
Reviewed By: rshest
Differential Revision: D62743019
fbshipit-source-id: c24ab8a49a97ca26e60efa2fa4bc6a21ccac52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46515
Changelog: [internal]
This reduces the depth of the Systrace/Perfetto blocks by 1 removing this unnecessary nesting. If for some reason `ShadowTree::tryCommit` runs more than once, it will still show up.
Reviewed By: bgirard, sammy-SC
Differential Revision: D62499855
fbshipit-source-id: 48cce7532a308221c22d04de874870be509fe315
Summary:
This PR removes `available` for `RCTKeyWindow` after minimum version bump to iOS 15 this check is not needed anymore.
## Changelog:
[IOS] [REMOVED] - remove available for RCTKeyWindow check
Pull Request resolved: https://github.com/facebook/react-native/pull/46510
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D62752434
Pulled By: javache
fbshipit-source-id: 7b7745d4f27128cdb66053f7fa1cc234435eac31
Summary:
Solves these issues:
- https://github.com/facebook/react-native/issues/18398
- https://github.com/facebook/react-native/issues/12478
Solves this proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/774
## 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
-->
[GENERAL] [ADDED] - added overlayColor prop to modal component for customisable background overlay
**Motivation:**
Currently, the React Native Modal component only allows the background to be set to either `transparent` or `white`. This limits the ability to dim the background or apply custom colors, which is essential for creating a more polished and user-friendly interface.
**Change Log:**
Modal Component Enhancements:
- Introduced a new optional prop `overlayColor` to the Modal component.
- Updated the background color logic to prioritize `overlayColor` when transparent is `false`.
- Ensured backward compatibility by defaulting to `white` when `overlayColor` is not provided.
Pull Request resolved: https://github.com/facebook/react-native/pull/46322
Test Plan:
- Test the changes on both iOS and Android devices/emulators to ensure consistent behavior.
- Added example in **rn-tester** app
**Sample screenshot with custom overlayColor passed as 'red'.**

Reviewed By: cipolleschi
Differential Revision: D62201559
Pulled By: alanleedev
fbshipit-source-id: e990d7f18f5edf61f0107026ea899c5f22d47bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46506
Changelog: [Android][Fixed] Fixed incorrect scroll event/position for scroll views when doing a smooth scroll animation.
We tested this in production and the fix is safe to land.
Reviewed By: rshest
Differential Revision: D62738925
fbshipit-source-id: e1198dac76cf850dfa76a5cee1ef205d5b367d19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46511
changelog: [internal]
task is not used after this line of code. Let's avoid copy shared_ptr's copy constructor.
Reviewed By: rubennorte
Differential Revision: D62751612
fbshipit-source-id: 92b0da44972b200870ef66f3a8482fbde55052ac
Summary:
This reverts commit 0cb97f0261.
Revert this commit that adds a `post install` script for a couple of reasons:
1. (EDIT: This turns out to be unrelated) The `postinstall` script causes `yarn install` to fail on React Native macOS, where we use Yarn 4. I'm not entirely sure why, but I probably won't debug it for the rest of the reasons.
2. `postinstall` scripts (at least inside Microsoft) are viewed as a security risk. Any package in your dependency tree can get compromised, add the phase, and run arbitrary code. This has happened in the past with React Native past if I recall correctly. As such, we disable `postinstall` scripts in many of our repos (including `rnx-kit` and `react-native-test-app`).
3. The issue this is trying to solve is to help newcomers avoid a stale cache when they switch branches in the React Native monorepo and only run `yarn install`. I think it would be sufficient to add some documentation somewhere that it is expected one runs `yarn && yarn build` to use this repo locally? That's a fairly common practice in monorepos, at least ones inside Microsoft.
## Changelog:
[INTERNAL] [SECURITY] - Remove post install script phase in the React Native monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46420
Test Plan: CI should pass
Reviewed By: christophpurrer, robhogan, cortinico, rshest
Differential Revision: D62755022
Pulled By: huntie
fbshipit-source-id: bf94ed33e3e451ea337ef7a6984f7ba964d0b212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46462
While adding D62583337, I noticed that `react-native` doesn't specify `babel-jest` as a dependency, despite referencing it in the included `jest-preset.js` — instead this would need to be installed by the template/project.
If we want to change this in future, we should consider a separate `react-native/jest-preset` package. However, I strongly believe this is the right location for this dependency: installing `react-native` = all parts of it work.
(Note that in the React Native monorepo, we are using `dependencies` for both dev and runtime deps in packages.)
Changelog: [Internal]
allow-executable-binary
## allow-executable-binary: Bypassed as this is a managed JavaScript dependency that is pre-existing in other parts of the codebase
Reviewed By: robhogan
Differential Revision: D62583665
fbshipit-source-id: 8bbcc8736e2740e45793d7b7e225ccfd1ca7f898
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46502
changelog: [internal]
At the moment, Linking module has undocumented restriction that if you call it twice when Android Activity is not available, it will return with an error.
This is unnecessary and can be handled more sensibly.
Reviewed By: javache, yungsters
Differential Revision: D62708123
fbshipit-source-id: 79a6beb70e834e631f7bedaf6a64076b050a7daa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46484
We recently realized that we don't have TS types for Codegen.
These are needed to let our users use these types when writing Specs in TS
## Changelog
[General][Added] - Add CodegenTypes for TS
Reviewed By: christophpurrer
Differential Revision: D62644516
fbshipit-source-id: 92bb7e8998d31806f6eb63319fb6d406fcd65ad8
Summary:
Following one of my previous PRs: https://github.com/facebook/react-native/pull/45176 I'm adding same conditionals to another module.
StatusBar API is supported on this platforms:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
## 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] [ADDED] - Conditionals for iOS only code in RCTStatusBarManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45896
Test Plan: CI Green / Make sure everything works as before
Reviewed By: cortinico
Differential Revision: D62579943
Pulled By: cipolleschi
fbshipit-source-id: 0c198c7732d253993638d825ca83be076bb09b90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46452
`babel-plugin-codegen` transforms `codegenNativeComponent`s by expending it with a whole set of many commands (~40 lines) that don't have a good equivalent on the source file.
Currently these lines are pointing to random parts of the due to a bug that causes the source maps to be incorrect and confusing.
Instead, I point all these generated lines of code to the default export as the only line that can represent them.
This way, if an error is thrown from that generated code it would point to that export.
If the users are confused by how it works, there's a comment in the function that is used in the default export in these that explains it:
```
// If this function runs then that means the view configs were not
// generated at build time using `GenerateViewConfigJs.js`. Thus
// we need to `requireNativeComponent` to get the view configs from view managers.
// `requireNativeComponent` is not available in Bridgeless mode.
// e.g. This function runs at runtime if `codegenNativeComponent` was not called
// from a file suffixed with NativeComponent.js.
function codegenNativeComponent<Props>(
componentName: string,
options?: Options,
): NativeComponentType<Props> {
```
The transformation is from all the types and exports after the imports:
[`MyNativeViewNativeComponent` for example](https://github.com/facebook/react-native/blob/773a02ad5d3cc38e0f5837b42ba9a5e05a206bf9/packages/rn-tester/NativeComponentExample/js/MyNativeViewNativeComponent.js#L4)
Which is roughly (ignoring all typing):
```
// types and exports
export const Commands: NativeCommands = codegenNativeCommands<NativeCommands>({
supportedCommands: [
'callNativeMethodToChangeBackgroundColor',
'callNativeMethodToAddOverlays',
'callNativeMethodToRemoveOverlays',
'fireLagacyStyleEvent',
],
});
export default (codegenNativeComponent<NativeProps>(
'RNTMyNativeView',
): MyNativeViewType);
```
to roughly:
```
var React = require('react');
var nativeComponentName = 'RNTMyNativeView';
var __INTERNAL_VIEW_CONFIG = {
uiViewClassName: 'RNTMyNativeView',
bubblingEventTypes: {
topIntArrayChanged: { /* */ },
topAlternativeLegacyName: { /* */ },
},
validAttributes: {
opacity: true,
values: true,
...require('ViewConfigIgnore').ConditionallyIgnoredEventHandlers({
onIntArrayChanged: true,
onLegacyStyleEvent: true
})
}
};
var _default = require('NativeComponentRegistry').get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);
var Commands = {
callNativeMethodToChangeBackgroundColor(ref, color) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToChangeBackgroundColor", [color]);
},
callNativeMethodToAddOverlays(ref, overlayColors) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToAddOverlays", [overlayColors]);
},
callNativeMethodToRemoveOverlays(ref) {
require('RendererProxy').dispatchCommand(ref, "callNativeMethodToRemoveOverlays", []);
},
fireLagacyStyleEvent(ref) {
require('RendererProxy').dispatchCommand(ref, "fireLagacyStyleEvent", []);
}
};
exports.default = _default;
exports.__INTERNAL_VIEW_CONFIG = __INTERNAL_VIEW_CONFIG;
exports.Commands = Commands;
```
Changelog: [Fix] Fixed source maps in Native Components JS files that use codegenNativeComponent
Reviewed By: robhogan, huntie
Differential Revision: D62443699
fbshipit-source-id: 522b4382736a8fed93a1bc687a78d6885fe7c9d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46473
This diff extends the renderer of react native to ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
This feature is controlled by the ReactNativeFeatureFlag: enableDeletionOfUnmountedViews
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559190
fbshipit-source-id: 1af6785fc57256d12750db64489c9ecc6cf98c9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46488
React.Ref includes string | number to support legacy string ref, which will be killed in React 19. Therefore, the type is deprecated in Flow. This diff changes the type to use React.RefSetter instead.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62649800
fbshipit-source-id: 81bcfbb052e2039b23829dac8de242bfb0fdca3a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46498
Looks like this is still necessary because we still run into this error when using the Components tab when using React DevTools:
> TypeError: cyclical structure in JSON object
This effectively reverts https://github.com/facebook/react-native/pull/46382.
Changelog:
[General][Changed] - AnimatedNode (and its subclasses) once again implement `toJSON()`.
Reviewed By: javache
Differential Revision: D62690380
fbshipit-source-id: d5b7c1d156b49838abefe48a7d7b61471cc3488a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46500
We're in the process of adding the required native component to all apps we maintain.
Until that is fully completed, fall back to using View if the native component
doesn't exist.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D62701331
fbshipit-source-id: d26c946af3a68231d0714e89d5e41be311399036
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46469
This causes VS Code to syntax highlight incorrectly, so let's use a type alias to workaround that limitation.
Changelog:
[Internal]
Reviewed By: tyao1
Differential Revision: D62595120
fbshipit-source-id: 97fc3caded51190a7840de91025eeb71c6290be8
Summary:
Before we were dividing proportionally and were noticing some truncation at the bottom. It seems that the truncation was disproportionately because of the way the metrics are calculated. Through guess and check, dividing equally between top and bottom seems to yield better results... 🤡
Changelog: [internal]
Reviewed By: NickGerleman, xunrongl
Differential Revision: D62665295
fbshipit-source-id: b1589c75251d68eaf75e32598ee84fbac457ae4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46487
Changelog: [General][Fixed] Fixed accuracy of FlatList estimations to determine what elements are visible in the rendering window.
This fixes a bug in FlatList where it thinks that some elements are visible in the rendering window, when they're not. Specifically, if a cell hasn't been laid out yet, it ignores all the information it already has on the ones that had, and estimates its position and offset based on the estimated size of the cells. In this case, if the first element has a larger offset because the list has a header, that offset is ignored in this case.
One observed result of this is that in a list where there's a header and a single cell that occupy the whole rendering window, FlatList thinks it needs to pre-render an additional element because the header is ignored.
Reviewed By: NickGerleman
Differential Revision: D62649060
fbshipit-source-id: 437bae79916707ca1d08784190508a9f7e36688e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46467
This diff introduces a new feature flag called ReactNativeFeatureFlag.enableDeletionOfUnmountedViews, which will ensure that pre-allocated views that were never mounted on the screen are deleted as soon as the shadow node is deleted from JS
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D62559188
fbshipit-source-id: 61f19a6dd38536de9f70fecc2937793681036f68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46478
These are all supported in the new arch (default as of 0.76), across all platforms. but were previously hidden from types, and undocumented.
I will make a pick request for this change, and we should then add these to documentation.
Changelog:
[General][Added] - Unhide new arch layout props
Reviewed By: cortinico
Differential Revision: D62616897
fbshipit-source-id: f6c2e71785284e667824a76918ccf2724adc4e98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46486
We probably don't need this extra log anymore as this information is already avaialbe from the start application log.
Changelog:
[General] [Changed] - Do not print Bridgeless Mode is enabled on console anymore
Reviewed By: fkgozali
Differential Revision: D62639866
fbshipit-source-id: 720bb1446a1e1be71bf27830fe4156ae64a1586f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46483
Original commit changeset: 631d741bd2ec
This is breaking the RedBox on React Native 0.76 on Android when not connected to Metro.
Original Phabricator Diff: D62213722
Changelog:
[Internal] [Changed] - Back out "[react-native] Remove some Tasks overhead"
Reviewed By: cipolleschi
Differential Revision: D62644614
fbshipit-source-id: a092614da78bef65546c2539a3ebc9bff5e807b2
Summary:
This PR is a follow-up after https://github.com/facebook/react-native/issues/46181 this change makes sure that if the `require.resolve` fails we still fall back to the old behavior.
The `require.resolve` was failing for local builds of OOT platforms (because in OOT platforms mono repo `react-native` is renamed to `react-native-platform-name`)
## Changelog:
[IOS] [FIXED] - Fallback to old resolve mechanism when node require fails to resolve react native path
Pull Request resolved: https://github.com/facebook/react-native/pull/46432
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D62577183
Pulled By: cipolleschi
fbshipit-source-id: d62d9c2a5eee3546a81d2aad52b7f73763315b18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46463
We had some basic warnings emitted by React Native components due to unused parameters or missing documentations.
This change fixes some of those
## Changelog:
[Internal] - Fix some build warnings
Reviewed By: NickGerleman
Differential Revision: D62583790
fbshipit-source-id: 329acc67ce64c00757a8568460ee68b85a62b6e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46464
React Native uses some 3P libraries that are emitting some warnings for which we can't do anything about.
This change suppress those warnings.
## Changelog:
[Internal] - Suppress 3p warnings
Reviewed By: cortinico
Differential Revision: D62582960
fbshipit-source-id: 79e8c28725177f5f47359da86f865e770dcf7c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46472
Currently, we are building the Debug symbols (dSYM) for hermes dSYM but we are not shipping them with the xcframework.
This is correct, because Debug symbols can increase the size of Hermes thus enalrging the iOS IPA and increasing the download time when installing pods.
We distribute the dSYM separatedly, in case users needs to symbolicate Hermes stack traces.
However the path to the dSYM still appears in the Info.plist of the universal XCFramework and this can cause issues when submitting an app to apple.
This change should remove those lines from the universal framework.
It fixes https://github.com/facebook/react-native/issues/35863
## Changelog
[Internal] - Remove dSYM path from Info.plist
Reviewed By: cortinico
Differential Revision: D62603425
fbshipit-source-id: 038ec3d6b056a3d6f5585c8125d0430f56f11bb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46454
The SVC Validator have no idea on how to process a simple NSArray *.
With this change, we are creating two named types for the NSArray:
* BoxShadowArray
* FilterArray
To create unique types that we can reference in JS.
We are then enhancing the `getProcessor` function to return the proper processor when those types are found in the NativeViewConfig
## Changelog:
[iOS][Fixed] - Fixed warnings when validating SVC
## Facebook:
This change is OTA safe: even when we ship the JS before the native code, the new cases in the switch will be never hit, similarly to the situation we have right now.
As soon as the native code is shipped, the new cases will start get hit and the wrning will disappear
Reviewed By: NickGerleman
Differential Revision: D62574612
fbshipit-source-id: d173bf5534ee5e436f23a4bc6e2fb25e72a4b06d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46439
The SVC for some components on iOS got out of sync.
This was creating warnings in the React Native DevTools and it was affecting the release of 0.76.
With this change, I updated the manually written SVC so that we don't have warnings anymore.
We still have to fix the `boxShadow` and `filter`. This will happen in a later change.
## Changelog
[iOS][Fixed] - Solved SVC warnings for RNTester
Reviewed By: NickGerleman
Differential Revision: D62501704
fbshipit-source-id: 3c02f7615c3511a97eba73a2ddaa713d2e4e30f0
Summary:
AppRegistry was not treated as a Callable Module in bridgeless mode. This is breaking headless tasks on Android.
Fixes:
- https://github.com/facebook/react-native/issues/46050
## Changelog:
[ANDROID] [FIXED] - Made AppRegistry callable from Native code in Bridgeless (fixes headless tasks)
Pull Request resolved: https://github.com/facebook/react-native/pull/46480
Test Plan: Used repro from linked issue
Reviewed By: javache
Differential Revision: D62637486
Pulled By: cortinico
fbshipit-source-id: 756527003ac6d712e76c02c188e280d15c010068
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/46276
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [ADDED] - fire onMomentumScrollEnd when UIScrollView is removed from window
**Why the issue is happening?**
The `onMomentumScrollEnd` event is typically triggered by the `UIScrollView` delegate methods `scrollViewDidEndDecelerating` and `scrollViewDidEndScrollingAnimation`. However, if the scroll view is removed from the window while navigating away, these delegate methods are not called, resulting in the event not being dispatched.
This behaviour was particularly problematic in scenarios where a scroll view is in motion, and the user navigates away from the screen before the scrolling completes. In such cases, the `onMomentumScrollEnd` event would never fire, which further make scroll area un touchable or un responsive.
**What we changed?**
In the didMoveToWindow method, we added logic to handle the scenario where the UIScrollView is being removed from the window (i.e., when the component is unmounted or the user navigates away). Here’s a breakdown of the changes:
- **Added a Check for Scroll State:** We check if the UIScrollView was decelerating or had stopped tracking (_scrollView.isDecelerating || _scrollView.isTracking == NO).
- **Manually Triggered onMomentumScrollEnd:** If the scroll view was in motion and is being removed from the window, we manually trigger the `onMomentumScrollEnd` event to ensure that the final scroll state is captured.
**_I had fixed this issue on both Old and New arch._**
Pull Request resolved: https://github.com/facebook/react-native/pull/46277
Test Plan:
Attaching a video with working solution:
https://github.com/user-attachments/assets/1a1f3765-3f11-46c3-af18-330c88478db8
Reviewed By: andrewdacenko
Differential Revision: D62374798
Pulled By: cipolleschi
fbshipit-source-id: 014be8d313bab0257459dc4e53f5b0386a39d5e0
Summary:
This enables projects to have multiple bundles built during the Xcode bundling phase (e.g. for projects where you might have a PhoneScene and a CarPlayScene each with their own RootView and bundle, if you're using [react-native-carplay](https://github.com/birkir/react-native-carplay)).
## Changelog:
[IOS] [ADDED] - User-configurable BUNDLE_NAME when building bundles
Pull Request resolved: https://github.com/facebook/react-native/pull/46339
Test Plan:
Built my project with the following Xcode "Bundle React Native code" build step:
```sh
set -e
export SOURCEMAP_FILE="$(pwd)/../main.jsbundle.map";
SOURCEMAP_FILE="$(pwd)/../main.jsbundle.map"
WITH_ENVIRONMENT="../node_modules/react-native/scripts/xcode/with-environment.sh"
REACT_NATIVE_XCODE="../node_modules/react-native/scripts/react-native-xcode.sh"
/bin/sh -c "BUNDLE_NAME=main $WITH_ENVIRONMENT $REACT_NATIVE_XCODE"
/bin/sh -c "BUNDLE_NAME=carplay $WITH_ENVIRONMENT $REACT_NATIVE_XCODE"
```
Then launched the app with a modified `AppDelegate.swift` which loaded main.jsbundle into one RootView and carplay.bundle into another RootView.
Reviewed By: cortinico
Differential Revision: D62577314
Pulled By: cipolleschi
fbshipit-source-id: 22312ca144146da6c71a8533a1883e720aff1e85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46461
This bumps SoLoader to 0.12.1 inside React Native and cleans up the extra
`com.facebook.soloader.enabled` metadata which are not necessary anymore.
Changelog:
[Internal] [Changed] - Bump SoLoader to 0.12.1 and remove unnecessary extra manifest metadata
Reviewed By: cipolleschi
Differential Revision: D62581188
fbshipit-source-id: ff990c0af1f0f51070037fcb4c7c13fbe6bae234
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46471
Changelog: [iOS][Breaking] Delete partialBatchDidFlush
this is an extremely old method on RCTBridgeModule similar to batchDidComplete that was special cased for UIManager. however, UIManager ended up deleting its implementation of partialBatchDidFlush. we had this janky logic that would iterate through all of the modules to call this partialBatchDidFlush when we really just wanted to do this for the UIManager. this logic is risky because the _moduleDataByID array is not thread safe.
i feel we can skip the deprecation cycle for this method, because i searched through GH and i did not find any callsites of this: https://github.com/search?q=partialBatchDidFlush&type=code&p=1.
Reviewed By: realsoelynn
Differential Revision: D62600722
fbshipit-source-id: d889bad54170a267e938b588e2fd6f558583a904
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46470
Changelog: [iOS][Deprecated] - Deprecating RCTBridgeModule batchDidComplete and adding configuration to disable it
batchDidComplete is used for the UIManager to initiate a layout and mount after a callback has been initiated by the bridge. however, we iterate through the whole module array in order to get this single UIManager, which is unnecessary. this also increases risk of a crash because the module array is shared between threads.
Reviewed By: realsoelynn
Differential Revision: D62600034
fbshipit-source-id: 6c98df7d5ab282015181fb07764121693bcc141e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46474
Changes `useAnimatedPropsLifecycle_passiveEffects` (the experimental lifecycle management in `useAnimatedProps`) to `useInsertionEffect` instead of `useEffect`. This has a few benefits:
1. Prevents any Activity detach and attach events from triggering Animated lifecycle work (which adds to effect mounting and unmounting time).
2. Fixes batching of native Animated operations across components. (Since we flush the operation queue in a passive effect, enqueueing operations in a passive effect causes weird interleaving of enqueuing and flushing.)
3. Enables animations to be started in layout effects.
Changelog:
[Internal]
Reviewed By: bvanderhoof
Differential Revision: D62602336
fbshipit-source-id: 3f6412387d87d4ea4135a29893135b4a64638809
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46475
fm.top is negative, so we want to add in order to decrease the absolute value, but fm.bottom is positive, so we need to subtract instead here
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D62612192
fbshipit-source-id: fc942abcb5a1ddedd6547aca66a188736e4ec029
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46425
It's entirely plausible that one would want to run a ReactFragment that does not tear down the ReactHost when it is destroyed. This adds a protected constructor that can be used to disable host lifecycle events in a ReactFragment. When disabled, the `onDestroy` method of the ReactFragment simply stops the surface attached to it using `ReactDelegate.unloadApp`.
## Changelog
[Android][Added] Flag in ReactFragment to allow unmounting a surface without destroying ReactHost.
Reviewed By: philIip
Differential Revision: D62449779
fbshipit-source-id: a443ed004ced45e0adc95bd43b36d1b80f9f392f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46424
It's not isomorphic for `ReactDelegate` to have a `loadApp` method to initialize a surface, but only allow unloading of a surface by calling `onHostDestroy`, which also destroys the ReactHost. This change adds an `unloadApp` method to `ReactDelegate` so it can be used in, e.g., `ReactFragment` to stop a surface without tearing down the host.
## Changelog
[Android][Added] ReactDelegate `unloadApp` methods for unmounting surfaces without destroying ReactHost
Reviewed By: mdvacca
Differential Revision: D62448543
fbshipit-source-id: e99b880f48e857935ee856c37b881bcc8bd22ad0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46440
ReactDelegate does not properly annotate the ReactRootView field as Nullable. This fixes that.
## Changelog
[Android][Fixed] Use appropriate Nullable attribute for ReactRootView field in ReactDelegate
Reviewed By: philIip
Differential Revision: D62514424
fbshipit-source-id: e9f10899007dfe794aa081717f5a5aa7d0038181
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46428
X-link: https://github.com/facebook/yoga/pull/1696
We do not validate the aspect ratio to ensure it is non zero and non inf in a lot of places. Per the spec, these values should act like auto. There is no auto keyword, but it is the default so I just set the style to a default FloatOptional in this case
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62473161
fbshipit-source-id: 6857de819538a7a87ce0a652e99f5a49992921ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46459
After the SoLoader 0.12.0 bump I've noticed RNTester is instacrashing due to us not having enabled it
explicitely in the Manifest:
Changelog:
[Internal] [Changed] - Unblock RNTester instacrashing due to SoLoader not being enabled
Reviewed By: cipolleschi
Differential Revision: D62580751
fbshipit-source-id: 3b291e7f82daf1a6bd61bc9588c2d49a389801ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46406
As title
Second attempt at landing the new name. There were 2 issues previously which led us to revert.
1. **Error on workrooms tests.** This ended up not being caused by us but rather by D61896776. After renaming the error changed which might've caused the renaming to be blamed for the issue. It has since been resolved
2. **FB crash** FB was crashing when using drop-shadow after renaming. For some reason after renaming `filter` an invalid stylex property was making FB crash. We don't know why renaming uncovered the issue but the the code was using unsupported features on RN (`calc` & `stylex`) which then led to passing a raw unsupported value for `filter` and crashing on the `processFilter` function.
FB was fixed here D62407454 to prevent crashing after landing this diff
Changelog: [General] [Changed] - Add official `filter` CSSProperty.
Reviewed By: NickGerleman
Differential Revision: D62401985
fbshipit-source-id: 14422603c40b7ddf8300029165a85655354075c3
Summary:
This PR fixes an issue with PrivacyInfo files.
When generating a new project for using the latest RC 0.76.0.rc0 I got two privacy manifests references in Xcode.
This is because `PrivacyManifestUtils` look for build phase reference:
```ruby
reference_exists = target.resources_build_phase.files_references.any? { |file_ref| file_ref&.path&.end_with? "xcprivacy" }
```
Which doesn't exist for the generated template.
Here is how Xcode file tree looks like after installing pods:

## Changelog:
[IOS] [FIXED] - don't reference PrivacyInfo.xcprivacy twice for new projects
Pull Request resolved: https://github.com/facebook/react-native/pull/46457
Test Plan:
1. Generate a new project
2. Execute pod install
3. Check if only one PrivacyInfo file exists
Reviewed By: cortinico
Differential Revision: D62580116
Pulled By: cipolleschi
fbshipit-source-id: 1224a41307ae6c9b862832f145baf0edc92476d6
Summary:
This change bumps the React Native version in main to 0.77
bypass-github-export-checks
## Changelog:
[General][Changed] - Bump main to 0.77-main
## Facebook:
generated by running `js1 publish react-native 0.77.0-main`
Reviewed By: cortinico
Differential Revision: D62575939
fbshipit-source-id: 6d239fca2eed6cfe51f8c37f78d8dc8730c18b8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46418
changelog: [internal]
introduce a small performance optimisation on Android.
When Paragraph is preallocated, it does not have valid C++ state. But we still send it to Android layer because it is part of a more generic pipeline. This has a cost because Android will end up using the state to update internal state on ReactTextView. To avoid this, simply add a special case to view preallocation and prevent it from sending C++ state.
Reviewed By: javache
Differential Revision: D62435529
fbshipit-source-id: 36b5b00a7a390432721d28d53ff8d4af76169e08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46422
Stubbing SoLoader comes with a couple of breaking changes (e.g. users in OSS are using `com.facebook.common.logging.FLog` which is exposed by Fresco).
In order to reduce those breaking changes, here I'm moving React Native to use SoLoader 0.12.0.
This new version comes with a constructor that accepts a MergedSoMapping implementation which we provide only for OSS apps.
Please note that the CI on this Diff will be red till SoLoader 0.12.0 releases.
Changelog:
[Internal] [Changed] - Do not stub SoLoader and use version 0.12.0
Reviewed By: cipolleschi
Differential Revision: D62447566
fbshipit-source-id: 6ff38799ed0c9f40cf3ab84be8a05979def63dc2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46445
Similarly to onTouchEvent, we should return true from onHoverEvent to signal to Android that the hover event is "handled" (because we've dispatched the event to JS). This is important to be able to distinguish multiple stacked React roots on top of each other.
Changelog: [Android][Fixed] Hover events were dispatched incorrectly when multiple ReactRoots were layered.
Reviewed By: mdvacca
Differential Revision: D62529586
fbshipit-source-id: d007c44b8ef56989888eb9a993e1428bd0b72a7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46404
As title
Second attempt to rename the prop. BoxShadow caused no issues after renaming but it was batched with `filter` which we reverted.
Changelog: [General] [Changed] - Add official `boxShadow` CSSProperty.
Reviewed By: NickGerleman, cyan33
Differential Revision: D62400814
fbshipit-source-id: ad721f6d11d614e987048e55556b05ff74a4747d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46386
Currently, `useAnimatedProps` attempts (and fails) to memoize the `AnimatedProps` instance by using `props` in the dependency array:
https://www.internalfb.com/code/fbsource/[de6bf108ae11fad0e8516617cde6f0cf3152d129]/xplat/js/react-native-github/packages/react-native/Libraries/Animated/useAnimatedProps.js?lines=56-59
However, `props` is very easily invalidated whenever the component is updated by its parent. The only time when it will not be invalidated is if the component that directly uses this hook — `createAnimatedComponent`'s return value — updates state… which never happens.
This changes `useAnimatedProps` so that we memoize `AnimatedProps` using only the nested property values that actually require a new `AnimatedProps` object to be created, which are `AnimatedNode` subclasses.
A minor detail is that in order for `AnimatedProps.prototype.__getValue` to continue working, we must supply `props` when we're actualizing the `AnimatedNode` instances into real values. This is accomplished by introducing a new method to select `AnimatedNode` subclasses: `__getValueFromStatic{Props,Object,Style,Transforms}`
Changelog:
[General][Added] - Created an experimental optimization to improve memoization within `Animated` to improve product performance
Reviewed By: javache
Differential Revision: D61997128
fbshipit-source-id: 2ca3cfb1038ba9a0abd82904acbc5cb4eb41a45d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46438
When hiding a view with React.Activity, React will "detach" all the views in teh subtree (call all their effect cleanups) and then upon showing it again will attach them (call all their effects again).
This was previously causing problems with useAnimatedProps and https://github.com/facebook/react-native/pull/46205 was intended to fix it (cc javache), but it's still a perf drain to have to detach all of this and then re-attach it upon show. Worse, it makes it so that we can't actually do any animations upon re-showing a view until all the passive effects have run to re-attach the views to the animations.
So instead, what this diff does is lean on the fact that useInsertionEffect *does not* clean up and rerun when Activity goes from hidden to visible and vice versa. Thus, we can rely on it to only detach the animated node when we're *actually* unmounting - rather than when we're simply hiding/showing.
Changelog:
[General][Changed] - Improved the performance of unmounting (and updating, when an enclosing Activity becomes hidden) Animated components
Reviewed By: yungsters, sammy-SC
Differential Revision: D62398039
fbshipit-source-id: af286e428188b5104f6cfd3fd4d8c9f791dedb8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46362
Changelog:
[Android] [Fixed] - improve text line height calculation
## Context
There is a recurring issue in React Native where text containing accented characters, non-latin scripts, and special glyphs experiences truncation when line height is set too small, even when the line height equals or exceeds the font size. This problem has a significant impact, particularly when rendering complex text in multiple languages or special character sets.
See: https://docs.google.com/document/d/1W-A80gKAyhVbz_WKktSwwJP5qm6h6ZBjFNcsVbknXhI/edit?usp=sharing for more context
## Investigation
Previously, when font metrics (ascent, descent, top, bottom) exceeded the line height, the logic arbitrarily prioritized descent over ascent and bottom top. This led to vertical misalignment and text clipping at the top of the text.
## Proposed Implementation:
1. Descent Exceeds Line Height:
Descent is capped to fit within the line height, setting ascent and top to 0, similar to the current behavior.
2. Shrink ascent and descent equally:
When the combined ascent and descent exceed the line height, the vertical deficit is split proportionally between them, ensuring even distribution of the space.
3. Proportionally shrink top and bottom:
If the top and bottom together exceed the line height, reductions are now applied proportionally based on the delta between top and ascent and bottom and descent.
Reviewed By: NickGerleman
Differential Revision: D62295350
fbshipit-source-id: 81381e8ea18ba9059488468295778c21781e4e7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46408
## Changelog:
[Android] [Added] - new feature flag for line height calculation
## Context
Adding feature flag for line height calculation centering.
There is a recurring issue in React Native where text containing accented characters, non-latin scripts, and special glyphs experiences truncation when line height is set too small, even when the line height equals or exceeds the font size. This causes issues in rendering complex text in multiple languages or special character sets.
See: https://docs.google.com/document/d/1W-A80gKAyhVbz_WKktSwwJP5qm6h6ZBjFNcsVbknXhI/edit?usp=sharing for more context
## Investigation
Previously, when font metrics (ascent, descent, top, bottom) exceeded the line height, the logic arbitrarily prioritized descent over ascent and bottom top. This led to vertical misalignment and text clipping at the top of the text.
## Implementation:
1. Descent Exceeds Line Height:
Descent is capped to fit within the line height, setting ascent and top to 0, similar to the current behavior.
2. Shrink ascent and descent equally:
When the combined ascent and descent exceed the line height, the vertical deficit is split proportionally between them, ensuring even distribution of the space.
3. Proportionally shrink top and bottom:
If the top and bottom together exceed the line height, reductions are now applied proportionally based on the delta between top and ascent and bottom and descent.
Reviewed By: NickGerleman
Differential Revision: D62421775
fbshipit-source-id: 6b0542426d7ee575f4986e60ddf92247542b65cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46429
Right now if I create a `Animated.loop(Animated.parallel(...))`, `config.__isLooping` for nested animations are not `true`. The reason is Animated.parallel doesn't pass down `isLooping`. This change is fixing that.
Changelog: [General][Fixed] - correctly pass down isLooping in parallel animation
Reviewed By: cipolleschi
Differential Revision: D62473189
fbshipit-source-id: 405dd36aa008cc965599ff82333b5552df1eb41f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46435
On main, we want to run CI as fast as possible to catch failures as soon as possible.
Currently, if two commits arrives on main (say commit A and commi B) CI will run on commit B only when it is finished on commit A.
Instead, we would like for CI to run in parallel.
## Changelog
[Internal] - Run CI in parallel on main
Reviewed By: cortinico
Differential Revision: D62496842
fbshipit-source-id: 03dc910deab42af98d92ea8e8e5b90049940dba1
Summary:
This introduces a new issue template for Debugger related issues.
bypass-github-export-checks
Changelog:
[Internal] [Changed] - Add an issue template for React Native DevTools bug reports
Reviewed By: cipolleschi, hoxyq
Differential Revision: D62440315
fbshipit-source-id: c7437d9787a910a2886df50171c86c9ed2412dd6
Summary:
This PR exposes `jsctooling` prefab that contains `facebook::jsc::makeJSCRuntime` used by Reanimated and other third-party libraries previously accessed via `libjscexecutor.so`.
Based on https://github.com/facebook/react-native/pull/46423.
## Changelog:
[Android] [Changed] - Expose jsctooling via prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/46430
Test Plan: Tested on Reanimated paper-example app built from source on RN 0.76.0-rc.0 with JSC enabled
Reviewed By: cipolleschi
Differential Revision: D62492763
Pulled By: cortinico
fbshipit-source-id: 53b6c0d9bb88559c40b5b8796bf6a1513bd388d9
Summary:
This PR fixes the following error when building third-party libraries that `#include <react/fabric/Binding.h>` which includes `react/timing/primitives.h` which is not included in `reactnative` prefab.
```
FAILED: CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o
/Users/tomekzaw/Library/Android/sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/darwin-x86_64/bin/clang++ --target=aarch64-none-linux-android24 --sysroot=/Users/tomekzaw/Library/Android/sdk/ndk/26.1.10909125/toolchains/llvm/prebuilt/darwin-x86_64/sysroot -DFOLLY_NO_CONFIG=1 -Drnscreens_EXPORTS -I/Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/../cpp -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/jsi/include -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include -isystem /Users/tomekzaw/.gradle/caches/8.10.1/transforms/b0878eb14f826ac5f04db98523604de2/transformed/fbjni-0.6.0/prefab/modules/fbjni/include -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fno-limit-debug-info -fPIC -std=c++20 -MD -MT CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o -MF CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o.d -o CMakeFiles/rnscreens.dir/src/main/cpp/NativeProxy.cpp.o -c /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp
In file included from /Users/tomekzaw/RNOS/react-native-reanimated/node_modules/react-native-screens/android/src/main/cpp/NativeProxy.cpp:2:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/fabric/Binding.h:17:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/jni/JRuntimeScheduler.h:11:
In file included from /Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/renderer/runtimescheduler/RuntimeScheduler.h:11:
/Users/tomekzaw/.gradle/caches/8.10.1/transforms/eb5443cef7868b6c3cc54bbf3f161a63/transformed/react-android-0.76.0-rc.0-debug/prefab/modules/reactnative/include/react/performance/timeline/PerformanceEntryReporter.h:10:10: fatal error: 'react/timing/primitives.h' file not found
#include <react/timing/primitives.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
```
## Changelog:
[ANDROID] [FIXED] - Expose `react_timing` headers in `reactnative` prefab
Pull Request resolved: https://github.com/facebook/react-native/pull/46427
Test Plan: Tested on Reanimated fabric-example app with react-native-screens installed built from source on top of RN 0.76.0-rc.0 with new arch enabled
Reviewed By: cipolleschi
Differential Revision: D62492707
Pulled By: cortinico
fbshipit-source-id: 94ed7044457bea53660a6ca6d5342cf8ea20a8b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46376
Ideally we would use Fusebox directly but it's not supported in release build. This is a clever work around that:
1) Allows us to use Perfetto to start/stop a trace, otherwise we'd need to build another way to do that which would be either hacky and/or complex.
2) Implements tacking Hermes JS samples and putting them inside of Fusebox traces.
3) Manually taking the trace and opening them in an instance of devtools.
Reviewed By: rubennorte
Differential Revision: D62263012
fbshipit-source-id: 49468914d2b7e5da4761329b176f140b917a404d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46421
Changelog: [Internal]
Avoid using the Context as a cache key, using only the asset name.
Reviewed By: Abbondanzo
Differential Revision: D62445718
fbshipit-source-id: 4161e6ef1bbc396c8ab815cdc0362159411f6a68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46423
This is used by Reanimated as they were previously accessing `libhermes_executor.so`
Changelog:
[Android] [Changed] - Expose hermestooling via prefab
Reviewed By: cipolleschi
Differential Revision: D62447875
fbshipit-source-id: e863c56bc5a801ee7de8a4e5d45f95481d3497f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46415
Changelog: [Internal]
Cache the results checking for vector content. This check is decompressing the asset content and parsing XML to check for vector graphics. Caching the result per context/asset name removes the need to parse the content on each image assignment.
Reviewed By: Abbondanzo
Differential Revision: D62436412
fbshipit-source-id: 9e1fe9f0747c9a30ac0d89124b6909d4260a2a2f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46356
# Changelog:
[Internal]-
Currently TextInput does not expose `editable` and `readOnly` (only `editable` is exposed as Android-specific prop).
This change is to add them to BaseTextInputProps so they can be supported cross-platform.
Reviewed By: rshest
Differential Revision: D62180722
fbshipit-source-id: 6cb82589f1d36b61167761f5a2e70e8d4b31b01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46405
Creates a feature flag for enabling the `Animated` code paths utilizing the new allowlist features. This enables us to validate the impact on product performance and developer experience before fully rolling it out.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62405286
fbshipit-source-id: be4a4786d4d2f44504f7788e473c12ed432ef1cd
Summary:
This is a pick on main of a fix necessary to release 0.76.x
## Changelog:
[INTERNAL] - Fix wrong command for publishing of external-artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/46417
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D62440193
Pulled By: cortinico
fbshipit-source-id: 57ea0736c1b6e3e60b048a46770356901de74024
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46170
This PR expose to JS a few missing text content types on iOS (available from iOS 15)
- dateTime
- flightNumber
- shipmentTrackingNumber
## Changelog
[General][Added] - Expose missing text content type to JS
Reviewed By: blakef
Differential Revision: D61657788
fbshipit-source-id: 1a0ea0e76efaf715d88bcbf249f7cb20b5f3607b
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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
-->
[IOS] [ADDED] - Line break mode for TextInput components. **This includes JS APIs for the new mode.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46128
Test Plan:
- Added unit tests to cover the new JS APIs.
- Verified that the new mode functions as expected through manual testing.
Reviewed By: andrewdacenko
Differential Revision: D61657004
Pulled By: cipolleschi
fbshipit-source-id: 9fc5c40fc077bee8e1abc51b6eae2e0f0fcd9b8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46413
When testing RNTester for Android during a release, we downloads the APKs from CI to save time.
Sadly, we were downloading the Release APKs instead of the Debug ones, so we could not test te integration with Metro.
This change fixes the testing scripts to download the debug APK
## Changelog
[Internal] - Download the debug APK instead of the Release one
Reviewed By: cortinico
Differential Revision: D62436023
fbshipit-source-id: 08a568caf3e5c85b9da933bc01623587bd36affe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46385
Changes `NativeAnimatedAllowlist` to export a "default allowlist" for use with "native animated components" (i.e. components that are only used with `Animated` values with `useNativeDriver`).
This required some minor internal implementation changes in order to make the allowlist conform to `{[string]: true}`, so I also added some unit tests to ensure the functionality remains the same.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62351434
fbshipit-source-id: e92b7245c0d61da87a0d149ffeb967f1ebb888a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46374
Creates an experimental `allowlist` parameter that can be supplied to a new `unstable_createAnimatedComponentWithAllowlist` method for use in new experiments to evaluate the impact on product performance and developer experience.
When it is provided, only the props and styles in `allowlist` will be inspected for `AnimatedNode` values. The hypothesis for this change is that restricting the search space for `AnimatedProps` to an allowlist will significantly reduce the runtime overhead of using `Animated` components.
Changelog:
[General][Added] - Created an experimental (unstable) method for allowlisting props when using `Animated`
Reviewed By: javache
Differential Revision: D62117424
fbshipit-source-id: bdd656be1fdc7454360035627644606cb00d33c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46384
Minor refactor to reduce duplicated logic when traversing props and styles in `AnimatedProps` and `AnimatedStyle`, respectively.
This refactor also makes a future optimization (in which we want to skip processing certain props) more straightforward to implement.
Changelog
[Internal]
Reviewed By: javache
Differential Revision: D62351078
fbshipit-source-id: 63c06462c99ef83f3b511456a3281b940b7a3ac0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46383
Minor refactors to the internal types of `AnimatedProps` and `AnimatedStyle` to avoid using `Object` and `any`.
This also migrates private properties prefixed with `_` to instead use `#` (ECMAScript private properties). This has the desired benefit of minimizing thrash in the `public-api-test.js` snapshot, too.
There are no behavior changes associated with this commit.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62351005
fbshipit-source-id: bb69d4db50aef5e0b3193971dac581686e359a95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46382
Deletes the `AnimatedNode.prototype.toJSON` method.
It was originally introduced by [facebook/react-native#7442](https://github.com/facebook/react-native/pull/7442) as a means to resolve [facebook/react-native#7441](https://github.com/facebook/react-native/issues/7441), where an error occurs attempting to serialize `AnimatedNode` instances.
However, this is no longer needed for that purpose because our inspector implementation is now more resilient. (It correctly reports the current style value instead of the `AnimatedNode` instance.)
The impetus for this change is that this `toJSON` method prevents a future performance optimization for all `Animated` components.
Changelog:
[General][Changed] - AnimatedNode (and its subclasses) no longer implement `toJSON()`.
Reviewed By: javache
Differential Revision: D62350726
fbshipit-source-id: c68edc98878e58d48bc677c4f1299bb1bd15c9c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46317
Changes `AnimatedProps` to avoid allocating `AnimatedStyle` (and `AnimatedTransform`, `AnimatedObject`) unless necessary.
This not only reduces memory and traversal overhead, but it enables us to implement allowlist strategies to prune unnecessary traversals.
Changelog:
[General][Changed] - Animated now omits `style` if the supplied value is null, undefined, or not an object. Previously, it would emit an empty `style` object.
[General][Changed] - Animated now resolves `style` to the original prop value if it contains no `AnimatedNode` instances. Previously, it would resolve to a flattened style object.
Reviewed By: javache
Differential Revision: D62117423
fbshipit-source-id: 34b0c9940be5b6f5d94467993a5344406cc56f93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46373
Currently, the logic for managing the native subscription in `AnimatedNode` is scattered and difficult to follow. This refactors the code to make the subscription's state easier to understand and harder to break in future refactors.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62268695
fbshipit-source-id: 098cc6413db2abffa80983116dd0a5f440ba6fce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46400
Since React 19 is not yet stable, we cannot publish a release of React Native depending on it, yet. As such, we have to revert our dependency on React 19 and bring back patterns such as `forwardRef`.
This is a spiritual revert of https://github.com/facebook/react-native/pull/45197.
Changelog:
[Internal]
Reviewed By: cipolleschi
Differential Revision: D62384482
fbshipit-source-id: 880ad1166e0b449ad5be6f914907661adb5f458d
Summary:
## Summary
This PR bumps Flow all the way to the latest 0.245.2.
Most of the suppressions comes from Flow v0.239.0's change to include
undefined in the return of `Array.pop`.
I also enabled `react.custom_jsx_typing=true` and added custom jsx
typing to match the old behavior that `React.createElement` is
effectively any typed. This is necessary since various builtin
components like `React.Fragment` is actually symbol in the React repo
instead of `React.AbstractComponent<...>`. It can be made more accurate
by customizing the `React$CustomJSXFactory` type, but I will leave it to
the React team to decide.
## How did you test this change?
`yarn flow` for all the renderers
DiffTrain build for commit https://github.com/facebook/react/commit/e210d08180a63f42079b91acaa7f6af15eef6d32.
Reviewed By: yungsters
Differential Revision: D62384646
Pulled By: SamChou19815
fbshipit-source-id: 727794f2d4091f37d771854b8e8a52f070309213
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46402
JS code for importing SafeAreaView is causing error in windows due to import being used.
Fix it by using conditional require instead
Changelog:
[Internal] - Fixed mis-used import of core only SafeAreaView in JS
Reviewed By: fkgozali
Differential Revision: D62392588
fbshipit-source-id: 65c4728ff73b43cc54543ec2d141a88fce1275ca
Summary:
This PR fixes animating controlled `Switch` component when it's initial value is set to `false`
When initial value was set to `false`, `_isInitialValueSet` flag wasn't changed to `YES`, because `oldSwitchProps.value` &`newSwitchProps.value` were equal, which resulted in controlled `Switch` component being updated without animation on first value change
This PR fixes it by moving setting `_isInitialValueSet` flag to the end of `updateProps` method
## Changelog:
[IOS] [FIXED] - Fix animating Switch component value change in Fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/46173
Test Plan:
1. Open `Switch` example in `RNTester`
2. In `Change events can be detected` section press switch that is `off` by default
3. Switch under it should change with animation
Reviewed By: javache
Differential Revision: D62377771
Pulled By: cipolleschi
fbshipit-source-id: 0213287c935db79a199b086ebb36a6979df03913
Summary:
X-link: https://github.com/facebook/metro/pull/1348
Pull Request resolved: https://github.com/facebook/react-native/pull/46371
## Internal
Vector drawable image support was added in D59530172 but importing vector drawable asset types was not supported out of the box. It required custom source transformers like the one added in D60021474. This is because Android cannot load vector drawable XML over the network. Vector drawables are compiled by AAPT as part of the build process. Even though Metro can serve XML, it would never load.
## Summary
This adds some minor checks in the `AssetSourceResolver` to only attempt loading XML asset types from disk on the Android platform. XML assets like vector drawables are precompiled and cannot be served over the network by Metro.
## Changelog
[Android] [Added] - Adds support for importing XML assets as images
Reviewed By: javache
Differential Revision: D62302929
fbshipit-source-id: 01e49ac5b0429d291318984128dfca2dc058149d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46398
Bump Metro packages to the version stablising for RN 0.76
Changelog:
[General][Changed] - Bump Metro dependencies to 0.81.0-alpha.0
Reviewed By: cortinico
Differential Revision: D62377929
fbshipit-source-id: 0808b11ad534e6a649c28f32b19f95f691645be4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46399
This is a patch release for Gradle. Let's include it inside main/0.76.
Changelog:
[Android] [Changed] - Gradle to 8.10.1
Reviewed By: tdn120
Differential Revision: D62377887
fbshipit-source-id: e8a5acaa48c15c9a12a09504c33c2a0d2834d92c
Summary:
Hey.
The react-native gradle plugin didn't properly filter out [Pure](https://github.com/react-native-community/cli/pull/2387) C++ TurboModules for autolinking, which caused build failures as a non-existing gradle dependency would be emitted.
This makes Pure C++ TurboModules work again for Android.
## 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
-->
[ANDROID][FIXED] Fix autolinking issues for Pure C++ TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/46381
Test Plan:
https://github.com/hsjoberg/rn75autolinkregression
Try running this repro project to observe the error:
```
1: Task failed with an exception.
-----------
* Where:
Build file '/Users/coco/Projects/Blixt/rn75autolinkregression/example/android/app/build.gradle' line: 54
* What went wrong:
A problem occurred evaluating project ':app'.
> Project with path ':react-native-cxx-turbomodule' could not be found in project ':app'.
```
Simply add the 1-line code from this PR to make the build succeed.
Cheers.
Reviewed By: cipolleschi
Differential Revision: D62377757
Pulled By: cortinico
fbshipit-source-id: 9e3fa3777b4e6e4d3f2eb0f996ac0ac7676eedbe
Summary:
Bumps the CLI to the next version
## Changelog:
[General][Changed] - Bump cli dependencies to 15.0.0-alpha.2
Pull Request resolved: https://github.com/facebook/react-native/pull/46394
Test Plan: CI
Reviewed By: huntie
Differential Revision: D62375405
Pulled By: cipolleschi
fbshipit-source-id: fec99216bc7ad6decfd83840091d807f603184da
Summary:
This PR exposes the `newArchEnabled` flag and deprecates all of the separate methods to enable new architecture.
As discussed with cipolleschi here: https://github.com/react-native-community/template/pull/45#discussion_r1732522705
## Changelog:
[IOS] [DEPRECATED] - Deprecate turboModuleEnabled, fabricEnabled, bridgelessEnabled
[IOS] [ADDED] - Add newArchEnabled method to RCTAppDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/46228
Test Plan: Test if switching newArchEnabled flag from AppDelegate works.
Reviewed By: cortinico
Differential Revision: D61849385
Pulled By: cipolleschi
fbshipit-source-id: 8acf718386882679f00d2d5000b4432a523b34ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46391
**Issue:**
RedBox displays early error before JS Error handling is properly setup.
On Android 15, targetSdk 35 (forced edge-to-edge), dialog overlaps with system bars making it difficult to use.
**Solution**
Add inset based margins so content does not overlap with system bars.
Changelog:
[Android][Fixed] - RedBox content overlapping with system bars on Android 15 forced edge-to-edge
Reviewed By: fkgozali
Differential Revision: D62362105
fbshipit-source-id: 57f60222914d407ebdcfd0359dbdf3ac36bde8f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46390
As React Native's minSdkVersion is not 24, clean up version checks and code that is using deprecated version from OSS
Changelog:
[Internal] - code cleanup for minSdkVersion 24
Reviewed By: philIip
Differential Revision: D62362059
fbshipit-source-id: a851d0908d4175269524f41955acca5f2da69cad
Summary:
When creating Hermes in CI, we build it for MacOS and Mac Catalyst as well.
The slices for these platforms requires symlinks to work properly.
The upload artifacts action on github, when applied to folders, follows the symlinks and copies the destination folder. The result is that Hermes for macOS and Catalyst does not work as expected.
This should fix https://github.com/facebook/react-native/issues/46213.
## Changelog:
[Internal] - Build Hermes in CI properly
Pull Request resolved: https://github.com/facebook/react-native/pull/46387
Test Plan: Tested already in 0.75
Reviewed By: robhogan
Differential Revision: D62355050
Pulled By: cipolleschi
fbshipit-source-id: 7abb85c8a2a88f13e06a49c6cb0caccbdad4551a
Summary:
In a react native project where USE_FRAMEWORKS is not nil, every time when running `pod install`, duplicate lines are added to `HEADER_SEARCH_PATHS` section of `project.pbxproj`:
```
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/ReactCommon/ReactCommon.framework/Headers",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-Fabric/React_Fabric.framework/Headers/react/renderer/components/view/platform/cxx",
" ${PODS_CONFIGURATION_BUILD_DIR}/React-graphics/React_graphics.framework/Headers",
```
Note: a popular library that needs `use_frameworks` is react-native-firebase.
See https://rnfirebase.io/#altering-cocoapods-to-use-frameworks
## Analyse
- `react_native_post_install` calls `ReactNativePodsUtils.update_search_paths(installer)`
- when `ENV['USE_FRAMEWORKS'] != nil` then `update_search_paths` calls `add_search_path_if_not_included`
- `add_search_path_if_not_included` checks if `"#{new_search_path}"` is already there
- if not found it adds `" #{new_search_path}"` _with an extra space_
- next time, it can't find `"#{new_search_path}"` because of the extra space, and adds `" #{new_search_path}"` again
## Changelog:
[IOS] [FIXED] - react_native_post_install script no longer adds duplicate entries to HEADER_SEARCH_PATHS
Pull Request resolved: https://github.com/facebook/react-native/pull/46262
Test Plan:
- create a react native project
- add `use_frameworks! :linkage => :static` to `ios/Podfile` (just before `use_react_native`)
- run `pod install`
- assert no duplicate lines are added to HEADER_SEARCH_PATHS of file `project.pbxproj`
Reviewed By: cipolleschi
Differential Revision: D61982680
Pulled By: shwanton
fbshipit-source-id: 61b566893c551d0813edd6eec2f8352c041c748f
Summary:
This PR bumps Socket Rocket to 0.7.1, this release brings some new improvements and visionOS support. I've also moved the version to a constant.
## Changelog:
[INTERNAL] [CHANGED] - Bump SocketRocket to 0.7.1
Pull Request resolved: https://github.com/facebook/react-native/pull/46300
Test Plan: CI Green
Reviewed By: cortinico, cipolleschi
Differential Revision: D62294833
Pulled By: blakef
fbshipit-source-id: 0e45c7de041710fb1f500b0ac23898b68a8a8936
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46359
Remove unneeded code around size calculation and old arch support
- updateState was getting called unnecessarily in multiple places --> only call from onSizeChanged()
- this is a reliable source for getting the content size area of the dialog used for Modal
- remove code checking duplicated update
- Old architecture cleanup
- Remove Java implementation of ShadowNode
- we already have logic to set the node size via UIManagerModule::updateNodeSize(). This code is now group together in updateState() for both new and old architecture
This fixes issues with resulting from wrong size calculation:
- having gaps at bottom when we set `statusBarTranslucent` to `true`
- Modal cut off at bottom on Android 15 (drawn under bottom nav bar)
Changelog:
[Android][Fixed] - Modal statusBarTranslucent bug, Modal at bottom being cut off in Android 15 (without forced edge-to-edge)
[Android][Deprecation] - Deprecating ModalHostShadowNode and ModalHostHelper classes
Reviewed By: mdvacca
Differential Revision: D62286026
fbshipit-source-id: 03b64a7783c12bebd1457c86a9a2657adc882c79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46326
- renaming variabled to make intent more clear
- `dialog` -> `dialogWindow` to distinguish with `activity.window`
- `hostView` -> `dialogRootViewGroup` as name was confusing.
- `ReactModalHostView` creates and manages `DialogRootViewGroup` but it used as contentView for the Dialog.
- bug fixes
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62177564
fbshipit-source-id: f81b167c1a234c02617ec2a3d63979628e01063b
Summary:
Reverts the PR https://github.com/facebook/react-native/pull/45967 from philIip to bring back the `registerCxxModuleToGlobalModuleMap(..)` function, which I use in Nitro Modules and MMKV.
Ontop of that, this also removes the "experimental" `RCT_EXPORT_CXX_MODULE_EXPERIMENTAL` macro, which I think was the original intent of this PR as this macro is a bit unsafe.
I also added some small docs to `registerCxxModuleToGlobalModuleMap` while I'm at it.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [CHANGED] - Bring back CxxTurboModule autolinking function, but remove `RCT_EXPORT_CXX_MODULE_EXPERIMENTAL` macro
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/46360
Test Plan: Build Nitro Modules. Worked for me! :)
Reviewed By: realsoelynn
Differential Revision: D62310637
Pulled By: philIip
fbshipit-source-id: 2caa2b8ea094dda5e13c81431a9a645cbcf8f807
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46370
Add a function to write the current trace contents to a file. To be used by the upcoming Perfetto data source while we wait for devtools to work in a profiling build.
Reviewed By: rubennorte
Differential Revision: D62262985
fbshipit-source-id: 04789f5312721434c773e51b3da333498bf0e786
Summary:
Currently, `AnimatedNode.prototype.getListeners` creates an array with `Object.keys()` to determine the number of listeners.
This is a relatively hot code path for animation-intensive user interfaces. Although `Object.keys()` is fast, every unnecessary memory allocation is an unnecessary opportunity to create garbage that requires collection.
Using an object as a dictionary performs worst than using a `Map` anyway, so this switches `AnimatedNode` to use a `Map`.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62267352
fbshipit-source-id: 8629861a64109a3a711c0f66a345029d0bfcd440
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46312
Refactors `NativeAnimatedHelper` to make it easier to read, reduce runtime overhead, and no longer export `queueOperation` (which was not useable externally anyway).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62139993
fbshipit-source-id: ce75e530887da6290f26060ecfe36049cf81879a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46366
This diff adds a Systrace section to the `SurfaceMountingManager::createViewUnsafe` method.
This will allow us to see more detail within the `MountItemDispatcher::mountViews preMountItems` that was previously almost blank.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D62247235
fbshipit-source-id: 3765c15e3e24e3231a30294938c725e82d100542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46348
`continueWithTask` skips an extra invocation layer that `onSuccess` adds. Switch to Task<Void> as the task can already represent failure or success without needing a boolean.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62213722
fbshipit-source-id: 631d741bd2ec4917eab69a20978ab2ace737c459
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46340
**Issue:**
InspectorPanel is hidden behind 3 button nav bar on Android 15 forced edge-to-edge
**Solution:**
Apply SafeAreaView to avoid overlap with system bars
(CAUTION: SafeAreaView here is for internal RN Core usage only and should not be used elsewhere)
Changelog:
[Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D62225374
fbshipit-source-id: e762288386d4f1d210bd26b8f28e73c652c7ba4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46341
Issue: LogBox Notification (or toast) is partly hidden behind 3 button nav bar on Android 15 targetSdk 35 build
Solution: surround with SafeAreaView to avoid overlap with system bars
(CAUTION: SafeAreaView here is for internal RN Core usage only and should not be used elsewhere)
Changelog:
[Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D62224584
fbshipit-source-id: 0662b1be9822bf51dadec2dd4879c915a47dfc65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46368
This bumps AGP to the latest stable.
Release notes are here https://developer.android.com/build/releases/gradle-plugin
No relevant changes for React Native, other than the requirement on minimum Gradle version.
Changelog:
[Android] [Changed] - Bump AGP to 8.6.0
Reviewed By: tdn120
Differential Revision: D62296897
fbshipit-source-id: c34a18ab15dbacd6e5d69003b9e192d7f76d9f8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46347
Calculate a frame deadline, and compare the current time against that.
This will also allow us to make frame timing more dynamic in the future, based on the display's frame rate.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D62213710
fbshipit-source-id: 1c7fc4b67d08c1eda4f3b9612a4506b33c44f626
Summary:
This diff cleans up the `use_debounced_effects_for_animated` experiment. It is not shipped because it breaks semantics of Animated.
It also removes the implementation of now unused `useDebouncedEffect` hook.
bypass-github-export-checks
Facebook
Details here https://fb.workplace.com/groups/3611662615830335/permalink/3666119690384627/
Changelog: [Internal]
Reviewed By: bvanderhoof
Differential Revision: D62188361
fbshipit-source-id: ce215cf7dd57e41e02c33760e91808d774bbd919
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46338
**Issue:**
With forced edge-to-edge on Android 15, LogBox bottom tab bar is hidden behind 3 button nav bar and is unusable.
**Solution:**
LogBox is using Android Dialog so update it to set margins based on inset values. With this change we can get rid of android header logic from JS.
Changelog:
[Android][Changed] - Modify LogBox to be usable on Android 15
Reviewed By: mdvacca
Differential Revision: D62224124
fbshipit-source-id: 4721753bf340bd813bcd560052c52b63fa58ad4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46354
**Issue:**
With forced edge-to-edge on Android 15, RNTester title at top overlaps with the status bar and bottom tab bar overlaps with bottom nav bar
**Solution:**
Add margins based on inset values to the ReactRootView which is the contentView for RNTesterActivity which acts as global padding within RNTester
Changelog:
[Android][Changed] - Adding padding for RNTester on Android 15 forced edge-to-edge
Reviewed By: mdvacca
Differential Revision: D62247910
fbshipit-source-id: 7b35d0c2016b6897b5de436a4245c9e910559541
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46346
Noticed that we could sometimes have multiple instances of DispatchUIFrameCallback in a single frame, which would cause us to execute more view preallocations or other work scheduled by Fabric. Root cause for this is on the new architecture, onHostResume seems to be invoked multiple times.
Make this code more resilient by explicitly tracking the state of the frame callback and avoiding multiple subscriptions. Longer-term we should consider having ReactChoreographer support repeating FrameCallbacks, since most of them are.
Changelog: [Android][Fixed] Fixed multiple Fabric dispatch callbacks being executed in a single Android frame
Reviewed By: sammy-SC
Differential Revision: D62213721
fbshipit-source-id: ac6fa5483ea38d9a15824af233fd23f1f6f3c891
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46295
X-link: https://github.com/facebook/metro/pull/1343
Updated all **babel** packages in all `package.json` across the repo and ran `npx yarn-deduplicate yarn.lock --scopes babel`. Afterwards, fixed the following issues appearing as a result of that (squashed the following initially separate diffs to make this packages update work atomically):
### (D61336392) updated jest snapshot tests failing
### (D61336393) updated babel types and corrected typings accordingly
The latest babel 7 introduces the following features we need to adjust our types to:
* `JSXNamespacedName` is removed from valid `CallExpression` args ([PR](https://github.com/babel/babel/pull/16421))
* `JSXNamespacedName` is used for namespaced XML properties in things like `<div namespace:name="value">`, but `fn(namespace:name)` doesn't make any sense.
* Dynamic imports are enabled behind a new flag `createImportExpressions` ([PR](https://github.com/babel/babel/pull/15682)), introducing calls such as `import(foo, options)`. These complicate the expected values passed to `import` to be more than just strings.
* Since these are behind a flag that is not expected to be enabled, we can throw an error for now and whoever uses it can add a support to it if needed later.
### Added a new metro ENV ignore
`BROWSERSLIST_ROOT_PATH` is set to `""` explicitly in `xplat/js/BUCK`
and then ignored in
`js/tools/metro-buck-transform-worker/src/EnvVarAllowList.js`
Reviewed By: robhogan
Differential Revision: D61543660
fbshipit-source-id: abbcab72642cf6dc03eed5142eb78dbcc7f63a86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46345
Deriving transforms can be expensive on Android. When using NativeAnimated with transforms, especially with an EventBasedDriver, we may update the transform every frame, even if it's unchanged. Ideally, we'd fix this in Animated, and diff the previous and next values, but this closes the gap somewhat in the short-term.
Both JavaOnlyArray and ReadableNativeArray implement equals, but will not compare equality correctly with each other. That's not an issue, as it just means we'll redo the transform once more than necessary.
Changelog: [Android][Fixed] Optimize BaseViewManager#setTransform to ignore duplicate values
Reviewed By: NickGerleman
Differential Revision: D62213726
fbshipit-source-id: 5df026030c66e31eb6a5fe6353de3706b5b7b799
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46333
This pull request introduces enhancements to the view controller presentation logic in React Native, allowing for multiple sheets to be presented on top of each other. The current implementation restricts the presentation to a single view at a time, which limits the flexibility needed in complex applications.
The proposed changes modify the presentation behavior to always utilize the top-most view controller for presentations. This adjustment ensures that multiple sheets can be managed more effectively, without disrupting the existing application flow.
Key changes include:
Modification of the presentation logic to reference the top-most view controller.
Utilization of a recursive method to determine the top-most controller.
The changes have been thoroughly tested with both old and new interfaces and have shown to work seamlessly across different scenarios
Changelog: [Internal] Allow multiple sheets to be presented on top of each other
Reviewed By: jessebwr
Differential Revision: D62202475
fbshipit-source-id: daa0cf95edb23ea52a26441337f9a16f5475b211
Summary:
## Context
The error message in folly dynamic has been updated in D62136190. Updating related tests to reflect the change.
## Diff
Only test code is changed. No business logic change.
## Changelog:
[Internal] [Fixed] - Fix broken unit test due to folly error message change
Pull Request resolved: https://github.com/facebook/react-native/pull/46329
```
Shows details about the selected run from the run history
Run result
java.lang.AssertionError: Test failure
Test Case RecoverableError
* Running RecoverableError.RunRethrowingAsRecoverableRecoverTest
* Running RecoverableError.RunRethrowingAsRecoverableFallthroughTest
2/2 tests passed.
Test Case JsArgumentHelpersTest
* Running JsArgumentHelpersTest.args
***** Failure in xplat/js/react-native-github/packages/react-native/ReactCommon/cxxreact/tests/jsarg_helpers.cpp:108
Expected equality of these values:
ex.what()
Which is: "Error converting javascript arg 4 to C++: TypeError: expected dynamic type 'int/double/bool/string', but had type 'array'"
std::string("Error converting javascript arg 4 to C++: " "TypeError: expected dynamic type `int/double/bool/string', but had type `array'")
Which is: "Error converting javascript arg 4 to C++: TypeError: expected dynamic type `int/double/bool/string', but had type `array'"
0/1 tests passed.
Test Case JSBigFileString
```
Reviewed By: yfeldblum
Differential Revision: D62184078
fbshipit-source-id: 6ae0a33f58e0e10f14166084b80a997e59a008ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46318
Configures the Metro by default to use the Hermes parser so that React Native can fully leverage all modern Flow language syntax.
NOTE: This does not affect `*.ts` and `*.tsx` files which will continue to use Babel. Metro has logic to enforce this regardless of the transform options.
Changelog:
[General][Changed] - Changed Metro default config to use Hermes parser, enabling the use of advanced Flow syntax in React Native.
Reviewed By: robhogan
Differential Revision: D62161923
fbshipit-source-id: 0f4c069d429517be16abcc6a2187cd23c6bd52d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46324
For listener sets that change infrequently, `CopyOnWriteArrayList` is a better trade-off compared to copying the list to iterate on it, especially in perf-sensitive paths like scrolling. Using `WeakReference` is also significantly simpler than `Collections.newSetFromMap(WeakHashMap`.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D62178024
fbshipit-source-id: bfc4f7389683b15be673dd7731094d52199d1c66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46311
A straightforward move of `NativeAnimatedHelper` into the private directory, so that it does not impact our Public API.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62142349
fbshipit-source-id: c93979e26e290d13e2a19fbe40d8f460ebea15fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46316
This pull request introduces enhancements to the view controller presentation logic in React Native, allowing for multiple sheets to be presented on top of each other. The current implementation restricts the presentation to a single view at a time, which limits the flexibility needed in complex applications.
The proposed changes modify the presentation behavior to always utilize the top-most view controller for presentations. This adjustment ensures that multiple sheets can be managed more effectively, without disrupting the existing application flow.
Key changes include:
Modification of the presentation logic to reference the top-most view controller.
Utilization of a recursive method to determine the top-most controller.
The changes have been thoroughly tested with both old and new interfaces and have shown to work seamlessly across different scenarios
Changelog: [Internal] Allow multiple sheets to be presented on top of each other
Reviewed By: cipolleschi
Differential Revision: D62143463
fbshipit-source-id: 53667cf1a75e4514156780574bf604aee6b3fefc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46287
Changes `Animated` to avoid validating certain values in production builds to improve performance.
In order to maintain consistent behavior between development and production builds (so that we reduce the likelihood of bugs that only appear in one of the environments), this also changes the validation errors to use `console.error` instead of error throwing.
Changelog:
[General][Changed] - Changed `Animated` props validation to soft errors instead of thrown errors
Reviewed By: sammy-SC
Differential Revision: D62055674
fbshipit-source-id: 8e5732d00ab06e14ba8562f5190ce79ca240e374
Summary:
The following fixes were needed to restore a clean build of React Native Windows downstream.
- LayoutableShadowNode.cpp: Value must be cast to a float to avoid type conversion error.
- ValueUnit.h: Must add a default return statement. Switch statement alone produces compiler error that function may end with no return value.
## Changelog:
[GENERAL] [FIXED] - Upstream fixes for build errors in React Native Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/46315
Test Plan: React Native Windows CI runs clean.
Reviewed By: javache, alanleedev
Differential Revision: D62149228
Pulled By: realsoelynn
fbshipit-source-id: 0d85455a22fbc0066076a50adee6b2d4409cd628
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46314
In Bridgeless's version of the Hermes JVM init path, we defaulted an internal GC option to allocate memory in Hermes' OldGen, and revert that behaviour once an internal API was called which marked the app as loaded.
This is an unsuitable default behaviour, since we can't rely on that internal API to be called on every launch. We're also moving to implicit performance instrumentation, which makes it harder to reliably call this API at the right time.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61937427
fbshipit-source-id: 95e43fc093b56aee6362f43b6b0832d1f439fb3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46249
Add internal only version of SafeAreaView.
This should be only used within RN Core or RNTester as there are a few places where this is needed and cannot have dependency on 3rd party
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61896413
fbshipit-source-id: 03fc263a9341f9b93b696d88a77a6501cd490177
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46302
Changelog:
[General][Fixed] - Removed noisy ENOENT error message upon launching the debugger
As described in T200199544, Metro terminal in open-source would show an error message for the missing embedder script.
In this diff, we add a response of an empty file to open-source (no-op)
Reviewed By: hoxyq
Differential Revision: D62103015
fbshipit-source-id: 219bc398b7786527db00528cca175adc13a527a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46282
We intended to enable Fusebox on `main` since https://github.com/facebook/react-native/pull/45469 — this worked when building under Buck, however was not working for builds under Xcode/Android Studio. This is because the `HERMES_ENABLE_DEBUGGER` preprocessor flag is not equivalently defined in these build configurations.
This diff genericises these checks to `!defined(NDEBUG)` (i.e. *any debug build*), meaning we are correctly able to evaluate the `ReactNativeFeatureFlags::fuseboxEnabledDebug()` setting.
Changelog: [Internal]
NOTE: `NDEBUG` should be the as-generic-as-possible choice to select a debug build in both OSS and fbsource. Having `HERMES_ENABLE_DEBUGGER` set remains significant (AFAIK) **within the Hermes codebase** (there are no other references in `jsinspector-modern`). Evaluation of whether the lack of this flag works in OSS continues in T200241280.
Reviewed By: hoxyq
Differential Revision: D61966685
fbshipit-source-id: d30950172420a0afd6c137dbf014794f3353bb7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46271
Improves the error thrown when an invalid value is supplied to `processFilter`. Without this, the error thrown would look something like:
> TypeError: … is not iterable
Changelog:
[General][Changed] - Improved error message for invalid filter values
Reviewed By: jorge-cab
Differential Revision: D62011191
fbshipit-source-id: 5594eeaf2b9174af14cc9e4daa275ae72974e597
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46281
In CSS newlines are considered equal to whitespaces which is why when receiving strings from RSD we could get \n characters which we were not handling
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D62034706
fbshipit-source-id: df2342b89156a131fecd0b0babeb478a6962b108
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46251
The diff D21124739 introduced this as a workaround for some faulty logic we used to have.
It seems like we no longer need it and it was actually causing issues with small border radii. Its barely noticeable but Outline looks weird in some cases if we leave it as is
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61938725
fbshipit-source-id: cf7ee7417e1085d01e2e307e780ff5d1db499e69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46273
The implementation of `AnimatedObject` should recurse through its structure and consistently treat `ReactElement` objects as opaque.
It wasn't consistent. This makes it consistent.
Changelog:
[General][Fixed] - Fixed undefined behavior in certain scenarios when `ReactElement` objects are supplied to Animated components
Reviewed By: javache
Differential Revision: D62012006
fbshipit-source-id: e6c3ac472945af8070735f1df856ff88b30a5624
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46264
React-native was not in sync with metro changes that RN relies on
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61982240
fbshipit-source-id: 63b1f53174ab0ec663a537569a032c62c431eb83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46191
Borders should not have to deal with clipping logic, that is fairly independent.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61418470
fbshipit-source-id: 762dbf30d50b5ce9b2b73720e58625447d8bf00e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46190
Right now the background color is tightly coupled with border drawing. For starters, I find this a bit confusing as one would not assume they are very closely related. But this also causes a bug around not being able to properly clip to the padding box, because if we did this we would clip the background color and transparent borders would look wrong.
This would also block a fix related to how borders display with clipped content that is coming in the later diffs. If we decide to use the border image, then we cannot properly display things like images since they would be on top of this image (otherwise background color shows through).
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61248625
fbshipit-source-id: ad398bbcfb69edc7d61362920773b51abea81d08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46189
A lot of the style decorators we have (filters, box shadows, borders, etc) use a separate sub-CALayer to accomplish what they want. This becomes an issue if we are clipping the content to the bounds and if these decorators extend beyond the bounds of the view as they are typically unaffected by this clipping. The main things here are `box-shadow` and `outline`. However, this implementation will let us fix some issues w.r.t content rendering under borders. See later diffs for that.
To fix this, if needed, we insert a `_containerView` to contain all of our subviews, and actually apply the clipping to. If this exists, our UIView will only have one subview, this one. But it may have multiple sublayers.
NOTE: This diff does not actually redirect the clipping. It just inserts the subview to test if this breaks anything in and of itself.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61414649
fbshipit-source-id: ddc2bfa47199909274c44da96a16e008290f9d2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46270
Changelog: [internal]
When analyzing traces, I noticed that we were using the choreographer to batch events in the native layer on Android. This approach isn't very efficient for 2 reasons:
1. The choreographer runs in specific intervals and there could be some delay between receiving the events and dispatching them from the choreographer.
2. A slow mount operation in the choreographer after receiving the event would completely block the dispatch for the whole duration of the operation. This could take as long as 100s of ms, so it can be very significant.
This is especially relevant with layout events, which are dispatched using the same mechanism as input events. In this case, there are instances where we delay rendering in JS because we're doing an expensive mount in the UI thread.
It makes sense to batch events in native so we don't do unnecessary work in JS to process them, but there's a better mechanism to do this. Instead of posting a frame callback in the choreographer, we can batch events using a new task in an Android handler running on the UI thread. This would run immediately after the job where the events are dispatched, after all the events are dispatched.
This implements that mechanism behind a feature flag.
Reviewed By: sammy-SC
Differential Revision: D62004018
fbshipit-source-id: d8b78a75cf05d0d8c9dd867a82a776f8d293a683
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46269
Changelog: [internal]
I'm planning some changes to this class and it was kinda hard for me to understand what some of these methods were meant to do. Doing a small refactor to rename them with more meaningful names.
Reviewed By: sammy-SC
Differential Revision: D62004020
fbshipit-source-id: 1e28e7e80f12a3a56ff16ace8794887b2f46495c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46268
Changelog: [internal]
`mReactEventEmitter` is final and initialized with a non-null value in the constructor, so this check is redundant.
Reviewed By: sammy-SC
Differential Revision: D62004021
fbshipit-source-id: bb8719c286cd04005370f2cdef89928c0d01007a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46267
We can propagate opacity, already part of AttributedString, to alpha channel of paint used to draw text and background on canvas.
This does not support propagating to views, and contrary to the iOS example added which originated with legacy arch, does not correctly support nesting opacity. This is a limitation of new arch more generally, where an AttributedString fragment only contains inner-most opacity.
Bg and foreground are drawn separately with alpha as well, instead of rendering overlapping content offscreen to properly apply it (this is an issue on RN Android more generally, and existing color alpha support, but is pretty noticeable here).
This impl targets new arch only.
Changelog:
[Android][Added] - Support simple opacity in nested text
Reviewed By: alanleedev
Differential Revision: D61999163
fbshipit-source-id: adb99834e94e00cb84a98d56f422c15b1bd849db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46242
This is transitively included, but should be explicitly included.
Changelog:
[Internal] commander is a dependency when bundling from Xcode
Reviewed By: cipolleschi
Differential Revision: D61916607
fbshipit-source-id: 1466d38d959970e5bd56576f8a7a22697d2eec4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46253
Changelog: [internal]
This is still internal because this API hasn't been publicly released yet.
## Context
This fixes a problem in our implementation for Event Timing API with paint time reporting (currently gated behind `ReactNativeFeatureFlags::enableReportEventPaintTime`) where events that don't trigger UI changes would wait for the next (unrelated) UI change to finish the event timing information.
## Implementation
We had this issue because we were relying on mount hooks to finish pending events. The problem is that if the event itself didn't cause a commit, the mount hook will not execute immediately, and we'll wait for the mount notification of whatever is the next change (in an arbitrary point in time in the future).
The fix for this has several parts:
1. Modify `RuntimeScheduler` to start tracking which surface IDs are the rendering updates applying to. It makes sense to do this regardless because `RuntimeScheduler` implements the Event Loop, and the Event Loop is aware of "documents" on Web (and the equivalent are surfaces in RN).
2. Create a new hook in `RuntimeScheduler` to report events after the task has finished executing (which is already a step in the Event Loop on Web). This will pass the list of surface IDs with pending changes, so the listener can determine if the events should be finished already or they should wait for mount for those changes.
3. Integrate `EventPerformanceLogger` with `RuntimeScheduler` and add the proper logic to handle this.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939260
fbshipit-source-id: 505bd41db8d3f62e5065424e62f9ed540832eed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46254
Changelog: [internal]
Right now it's very hard to access the surface ID from the target when dispatching events, and we need that to determine if the event we dispatched produced any updates its surface ID.
This adds surfaceId to EventTarget so we can access it without an unnecessary large amount of indirection in the current code.
This is a dependency for https://github.com/facebook/react-native/pull/46253 / D61939260, split to simplify reviewing.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939910
fbshipit-source-id: 6dd6bc55fc6d4aa6cf8a535080c14a7a5b573b71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46252
Changelog: [internal]
The long task API should only account for work specifically done by the task. Updating the rendering shouldn't be considered for that, so this moves the determination of long tasks before doing that work.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939261
fbshipit-source-id: 6d2573d561d507dff60b9703e4cc90ce4d131960
Summary:
When not drawing a border, the mGapBetweenPaths adjustment can create noticable pixelation when drawing curves through a low number of pixels. This is noticable mostly on buttons and such on low-dpi devices. This fix only applies the fix if clipping for the border radius is done.
When drawing small radius rounded backgrounds (e.g. to draw a circle or button) we see visible pixelation (see [GH-41226](https://github.com/facebook/react-native/issues/41226)) This is particularly noticable on low DPI devices.
## Changelog:
[ANDROID] [FIXED] - Don't use mGapBetweenPaths if not drawing a border
Pull Request resolved: https://github.com/facebook/react-native/pull/46239
Test Plan:
Built an android app that directly uses CSSBackgroundDrawable to draw a background and verified repro of this issue.

Then modified the code according to this PR and verified that anti-aliasing is appropriately applied

Reviewed By: NickGerleman
Differential Revision: D61925281
Pulled By: jorge-cab
fbshipit-source-id: 93014629d031bd0d716cd3bb11e2c294dedad639
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46237
I can't find any uses of this, it's not referenced in any fixtures, and flow and typescript both pass without it.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61892355
fbshipit-source-id: 8ebb4da3e104109c740d90c2495dbcc89d3978e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46222
This value was typed as always being a string, even though it was containing both strings and numbers in the fixtures. This was because on this line https://fburl.com/code/9j7gh4av the input type is $FlowFixMe (from the source AST), which wasn't catching that it couldn't flow into just `string`.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61830075
fbshipit-source-id: 0d5a0239d7c0209049184ca858a7ceb1ada02f79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46221
Previously the schema special cased unparseable elementType with elementType just being undefined. This causes issues for logic that requires recursively matching types. Instead of being implicit, this makes them explicitly an AnyTypeAnnotation
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61825742
fbshipit-source-id: 47bf70d32d21647896d8f5319087378cc8ac8d4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46241
Our test for rebuilding the `autolinking.json` file currently rebuilds everytime if the cached json file ISN'T empty. This means users who have an empty entry get stuck there.
I've also added more validation that the contents of the cached config have at a minimum the `.project.android.packageName` entry in it, otherwise it rebuilds.
Changelog: [Internal]
Closes 46134
Reviewed By: cortinico
Differential Revision: D61911114
fbshipit-source-id: 188c7f975ce05802c8ea06eaa48345c2bc96f2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46224
- Extract functions from StatusBarModule so they can be reused
- WindowUtil was created as a container for the extracted Window related helper functions
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61834841
fbshipit-source-id: a40f6b95ab7569bbe7680b5ca314eb0844114d1d
Summary:
Fix linear gradient borders with BackgroundStyleApplicator.
### After fix
<img width="200" alt="Screenshot 2024-08-18 at 3 44 56 PM" src="https://github.com/user-attachments/assets/79ae7c9c-3b64-43e0-bbbe-ddc930c73648">
## Changelog:
[ANDROID] [FIXED] - Linear gradient border styles
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/46084
Test Plan: Test border examples in LinearGradientExample.js
Reviewed By: rshest
Differential Revision: D61798132
Pulled By: NickGerleman
fbshipit-source-id: a8cf1d84166044e09fb573995cac3d3f31c2187b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46145
Filters clip children by default due to using `RenderEffect` we are keeping this behavior but we were clipping to the border box while Web clips to padding box.
To keep the clipping consistent we are enforcing `Overflow.HIDDEN` when a view contains a filter.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D61630698
fbshipit-source-id: dcc3fd680546793096d8996f405724df0a834079
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46231
Removes this option from `npx react-native start`. Flipper will no longer be the default launch flow in 0.76.
The debugger frontend variant remains controlled by `target.reactNative.capabilities?.prefersFuseboxFrontend`. This will always be Fusebox, since D60893243.
Changelog:
[General][Changed] Remove `--experimental-debugger` option from start command
Reviewed By: robhogan
Differential Revision: D61852415
fbshipit-source-id: 3351f0e12c24717916a70dd1ea28f8690bb5509f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46223
Changelog: [internal]
This introduces a new feature flag to fix some problems with `IntersectionObserver` on Android.
## Context
Our current implementation works as follows:
1. When observing a new target, we synchronously check if there are pending transactions in the mounting layer for that surface.
a) If there are, then we don't dispatch an initial notification for the current state of that target and we wait for those transactions to the applied. When they are, mount hooks are executed and the notifications are dispatched.
b) If there aren't, then we cannot rely on receiving a notification via mount hooks, so we dispatch the notification immediately.
This works well to ensure that when observing a target that was just mounted by React we'll receive a notification with the paint time for that target.
The problem we currently have on Android is that that platform uses a "push" model for the mounting layer, which means we consume transactions immediately after commit. Because of that, when we check whether there are pending transactions, the mounting layer would report "no" but the consumed transactions haven't actually been mounted. In that case, we dispatch the notification immediately.
The result of that behavior is that we don't wait for the transactions that will paint a new target and instead report its intersection immediately, providing incorrect data about when it was first mounted.
## Changes
The way the new feature flag fixes the problem is by adding a new parameter in `MountingCoordinator::pullTransaction` to tell the coordinator that it should continue reporting pending transactions if there were any when that was called. We also add a new method to clear pending transactions when we execute mount hooks for that surface.
Reviewed By: javache
Differential Revision: D61831209
fbshipit-source-id: ed6e5a3d27bd3e802c79a203e920d247b1715c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46234
We were seeing some cases of these not working and that was because CoreFeatures::enablePropIteratorSetter was set to true and we need to add this line for it to parse with that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61861547
fbshipit-source-id: 47356671dc61e99ffa3df9834eb5856f29b07c59
Summary:
RN Android has historically delegated any responsibilities for background and border rendering to individual view managers.
When we enforced that SVCs didn't allow more properties than native view configs, it meant that unlike for iOS, we needed to structure these SVCs to only apply to single view managers, to avoid warnings.
This creates issues for third-party view managers extending ReactViewGroupManager, which don't seem to get these attributes added to their SVCs under current setup. RNSVG also uses `codegenNativeComponent` on TS `ViewProps`, but for historically reasons around hiding props from the new arch, that does not include these props (and would not have a way to associate with the right process function if it did).
After we clean up an old experiment path (waiting a little bit longer for safety), BaseViewManager on Android will be able to influence rendering, and we can put these in BaseViewManager (see D61658737).
In the meantime, D60575253 allows us to make SVCs a superset of native view config, which means we can declare this for `BaseViewConfig`, before Java view managers catch up, without creating warnings.
Changelog:
[Android][Changed] - Move `experimental_boxShadow` and `experimental_backgroundImage` to BaseViewConfig
Reviewed By: RSNara
Differential Revision: D61744706
fbshipit-source-id: dcf3511ee6f826ef260f557703c182b361b7a2d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46043
# Changelog: [Internal]
Defined JavaScript interface, which can be used by other modules, such as LogBox, which will be migrated in the next diff
Reviewed By: robhogan
Differential Revision: D61301333
fbshipit-source-id: 63bb8581b893d0fdcb36e1fa16d243f1a5b08ac4
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/29763
## 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
-->
[ANDROID] [ADDED] - Added a conditional check in the `resolveThemeAttribute` function to reattempt resource resolution with the "android" package name if the resource ID is 0.
**Reason why app is getting crashes?**
The crash was occurring due to an issue with resolving certain color attributes in the Android theme. Specifically, when attempting to resolve attributes like textColorPrimary, the getIdentifier method returned a resource ID of 0, indicating that the resource could not be found. This issue resulted in the resolveThemeAttribute function failing, as it attempted to resolve a non-existent resource ID, which led to a crash.
**Key Points:**
**Problem**: Resource ID returned as 0 for specific attributes like textColorPrimary.
**Cause**: The resource ID of 0 indicates that the attribute was not found in the app's resources.
**Impact**: The resolveThemeAttribute function attempted to resolve an invalid resource ID, leading to crash because of this line: https://github.com/facebook/react-native/blob/6cfe51ded006e55617a6f4f2587ca2026306c58d/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/ColorPropConverter.java#L227
The introduced fix includes a fallback mechanism to attempt resolution with the "android" package name when the initial lookup returns 0. This helps in correctly resolving theme attributes that might be part of the Android system's default resources, thereby preventing the crash.
Pull Request resolved: https://github.com/facebook/react-native/pull/46202
Test Plan: - Tested the app with above colors mentioned. Ensured that app is not getting crashed.
Reviewed By: cipolleschi
Differential Revision: D61847357
Pulled By: cortinico
fbshipit-source-id: 50895a8fd7956e001dbbad9a505ae65151209bd9
Summary:
Replicates https://github.com/react-native-community/cli/commit/48d4c29bba4e8b16cbc8307bd1b4c5349f3651d8, which landed inside `cli-plugin-metro` inside RNC CLI, but because of migration of code to `community-cli-plugin` it looks like apparently the fix wasn't replicated.
## Changelog:
[GENERAL] [FIXED] - Ensure `--build-output` destination exists
Pull Request resolved: https://github.com/facebook/react-native/pull/45182
Test Plan:
Specify a new directory that doesn't exists inside `--build-output`:
`npx react-native bundle --build-output dist/new-dir/index.bundle`
and this command shouldn't fail.
Reviewed By: christophpurrer
Differential Revision: D61850942
Pulled By: huntie
fbshipit-source-id: 90e57f19c661ace8206162d6fa2e6a27acb31e20
Summary:
This PR solves a small issue I've encountered when working with the repo.
When changing branches we often run `yarn` to reinstall dependencies (let's say we change from 0.74-stable to main).
There are lots of changes between those two versions in the `react-native-codegen` package. This causes an issue when we install pods in `packages/rn-tester` the old version of codegen is used (the one cached from 0.74-stable) leading to a big error that's hard to solve at first.
This PR solves this by building codegen on `postinstall`. I've seen many newcomers blocked by this issue (and rerunning `yarn` is the natural thing to do in this situation)
## Changelog:
[INTERNAL] [ADDED] - Build codegen on postinstall when working with the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46227
Test Plan: Run `yarn`
Reviewed By: cipolleschi
Differential Revision: D61849150
Pulled By: huntie
fbshipit-source-id: 24fc5cf9b6a2510298f7bcdce59043e5dcfbfdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46229
When running codegen from `pod install`, something affects `require.resolve`, and it starts looking for codegen-enabled dependencies from the workspace root, not the current RN project root.
This is bad if we have different versions of same dependency across multiple workspaces. One of them will be hoisted to the workspace root, and will be used for all the workspaces.
This issue is described in details here https://github.com/facebook/react-native/issues/46196
This diff is supposed to fix this by adding the project root path to the `require.resolve` call.
Changelog: [iOS][Fixed] - Codegen will start looking for codegen-enabled dependencies from the project root.
Reviewed By: cipolleschi
Differential Revision: D61850219
fbshipit-source-id: d60a0e72e9c60e862c0d64e227ea3652d1be5a90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46216
Regarding [issue](https://github.com/facebook/react-native/issues/45817) with incorrect layout when `left` is set to `auto`. This PR introduces handling `auto` whenever inline or flex position is checked to be defined and it fixes above issue.
Changelog:
[General][Fixed] - Fix handling 'auto' checks in absolute layout
## Tests:
I have run the provided unit tests and everything passes.
X-link: https://github.com/facebook/yoga/pull/1689
Reviewed By: cipolleschi
Differential Revision: D61737876
Pulled By: NickGerleman
fbshipit-source-id: 531199a91c5e122b930b49725ea567cbb1d592ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46215
These cause a build error in RN and need to be updated any time a thick Yoga API changes. This change replaces them with mocking the factories with Mockito instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61804855
fbshipit-source-id: 24fbf10a12102de2975ba3aee45efe7350e294ec
Summary:
This PR modifies hermes-engine.podspec to resolve the path to `react-native` dynamically.
In OOT platforms case we often have slightly different versioning, let's say `react-native` is at 0.75.1 and `react-native-visionos` is at 0.75.2. This causes an issue while resolving the prebuilt version of Hermes. We should always get the Hermes tied to the `react-native` package version, not the OOT platform.
## Changelog:
[IOS] [FIXED] - Resolve Hermes prebuilt version based on react-native packge
Pull Request resolved: https://github.com/facebook/react-native/pull/46181
Test Plan: Install pods
Reviewed By: blakef
Differential Revision: D61720652
Pulled By: cipolleschi
fbshipit-source-id: a99c3261ae8738979f30e831ac6cb494a5c06e31
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46220
We'll want to eventually combine the module and component capabilities more, but these are at least the trivially shared ones.
More work is required to merge the more complex object types.
This change also makes it more clear where capabilities are different between native modules and components
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61740140
fbshipit-source-id: 9e7bf740cf6cd2431be8cad822ec69903dbbc71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46218
Changelog: [internal]
https://github.com/facebook/react-native/pull/42975 added some logic to fix modal on iOS for Paper but introduced a state update in `componentWillUnmount`. Doing this is incorrect and we've seen cases where it leads to forcing passive effects synchronously, which can affect performance.
This removes that unnecessary call to update the state, because the component will be unmounted anyway.
Reviewed By: bgirard
Differential Revision: D61813988
fbshipit-source-id: bb203578376d86a907544fa62a0d04e93ca132ef
Summary:
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
related to https://github.com/facebook/react-native/issues/45285
## Changelog:
[GENERAL] [FIXED] - fixed fontWeight number value error for text optimized
Pull Request resolved: https://github.com/facebook/react-native/pull/45932
Reviewed By: NickGerleman
Differential Revision: D61773721
Pulled By: javache
fbshipit-source-id: c5e23becf3af0b4303dda7b9d48628b2bca3285a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46214
This tries to represent a few operations which have previously been observed to be costly in a sampling profiler (showing more granularity than the trace events):
1. TextView getting measurements via `onMeasure()` when updating layout metrics during mount, which may [trigger UI-thread text layout](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/widget/TextView.java;l=11217).
2. Text drawing, which may do layout as well
3. State updates, where we construct a new Spannable and set content to it
Changelog: [Internal]
Reviewed By: tdn120, mdvacca
Differential Revision: D61705770
fbshipit-source-id: 199a6c65c18296f2ff948642701a331ba656e9d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46205
When React.Activity unmounts and remounts effects, we fail to re-attach the native view to the NativeAnimated nodes, which causes animations to stop working.
Changelog: [Internal]
Reviewed By: sammy-SC, bvanderhoof
Differential Revision: D61662164
fbshipit-source-id: 8e86502f7258beba02d5e60b31864974d7288af5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46179
Changelog: [Internal]
**Context**
- When debugging E2E tests, we found RNTester Legacy Arch builds were rendering border radius w/ percentages in a strange way
- The issues was only noticeable on production e2e builds
- Support for percentage on borderRadius ViewStyle props was added in D56198302
- This should be fabric only, but the same props are parsed on Paper
**Change**
- Add Custom Conversion for BorderRadius on Paper
- Only Parse integer border radius values
Reviewed By: philIip
Differential Revision: D61686841
fbshipit-source-id: cc24d3dbdb82b1dcb90f18fc44d5d13d3e6465b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46188
UBSAN identified undefined behavior when argCount == 0 (defining a variable array of zero length).
Plus variable arrays in C++ are a clang extension.
[ChangeLog]: [General] [Fixed] - Undefined behavior fix in MethodInvoker
Reviewed By: nlutsenko
Differential Revision: D61725776
fbshipit-source-id: 3729080eae8e78b65a558305f68782ae99edbc0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46143
Before `drop-shadow` was not creating a stacking context causing its children to get flattened and not receive the shadow effect.
This was due to incorrect parsing on C++. We didn't notice since we don't support `drop-shadow` on iOS and Android gets the parsed prop directly
Changelog: [Internal]
Reviewed By: NickGerleman, joevilches
Differential Revision: D61617699
fbshipit-source-id: a8bfbb0043fcd2b2867923eb937a6be8e9004f13
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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
-->
[IOS] [ADDED] - Line break mode for TextInput components. **This includes iOS updates to consume new cpp functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46129
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656969
Pulled By: cipolleschi
fbshipit-source-id: 4c6ed983ad15841ce52443bba13962d45c04e756
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/44107
## 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
-->
[IOS] [ADDED] - Line break mode for TextInput components. **This includes cpp changes and new functions.**
This PR is a breakdown of [this](https://github.com/facebook/react-native/pull/45968) PR.
Pull Request resolved: https://github.com/facebook/react-native/pull/46130
Test Plan: - Tested builds in new and old architecture mode.
Reviewed By: andrewdacenko
Differential Revision: D61656894
Pulled By: cipolleschi
fbshipit-source-id: 9a25387cb27cded072e76575e6d2fca01963c621
Summary:
A previous attempt at fixing this issue used a relative path (https://github.com/facebook/react-native/issues/45208), this doesn't work if the user runs bundle install outside of the `ios/`
folder, using the `--project-directory=ios` argument.
## Changelog:
[iOS][Fixed] support bundle install from outside the ios folder using --project-directory
Pull Request resolved: https://github.com/facebook/react-native/pull/46186
Test Plan:
Ran the command in a project with `react-native-firebase/app` using the
`--project-directory`, confirmed that it's fixed when using the absolute
path.
closes: reactwg/react-native-releases#341
Reviewed By: cipolleschi
Differential Revision: D61719821
Pulled By: blakef
fbshipit-source-id: d83429dd29c9e8cc066ab9843ad95fdfc0af8dea
Summary:
This PR adds few missing text content types on iOS (available from iOS 15)
- dateTime
- flightNumber
- shipmentTrackingNumber
## Changelog:
[IOS] [ADDED] - Add support for missing text content types
Pull Request resolved: https://github.com/facebook/react-native/pull/42788
Test Plan: Make sure that `RNTester` builds and runs successfully
Reviewed By: robhogan
Differential Revision: D61656748
Pulled By: cipolleschi
fbshipit-source-id: e960eded5f049d3c4bf76a5a4e3159b240546288
Summary:
I couldn't find a reference nor a reason for this method. It's a bit hard to grep, so let me know if I missed something.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61558809
fbshipit-source-id: d977440ff98b2a5bf115d19bfa4acbcf6d216b2a
Summary:
FIXES https://github.com/facebook/react-native/issues/45858
When working with UIRefreshControl in a custom React Native component, we encountered a problem where the refresh control did not behave correctly if it was offscreen. Specifically, attempts to programmatically begin or end refreshing were ignored if the control was not visible. This typically manifested as the refresh control not updating its state properly when it was re-rendered or moved in the view hierarchy.
Happening only on old-arch.
**Problem Details**
**Offscreen Refresh Control Ignored:** The UIRefreshControl would ignore calls to beginRefreshing and endRefreshing if it was not currently visible on the screen.
**Inconsistent State:** The internal state _currentRefreshingState might not match the actual state of the UIRefreshControl, leading to unexpected behavior.
**Steps to Fix**
**Track Visibility with didMoveToWindow:**
Implement the didMoveToWindow method to track when the refresh control is added to or removed from the window.
Use a flag _hasMovedToWindow to keep track of this state.
And check this flag should be true whenever we start or end refreshing
## Changelog:
[IOS] [FIXED] - Fixed an issue where the refresh control would not behave correctly if it was offscreen.
Pull Request resolved: https://github.com/facebook/react-native/pull/45996
Test Plan:
Issue Screen recording
https://github.com/user-attachments/assets/73b45c27-19c2-4eeb-991e-33b45f0a6d97
Fix Screen Recording :
https://github.com/user-attachments/assets/ffc6b6e6-fc68-498c-abdf-3144c31caa86
Reviewed By: realsoelynn
Differential Revision: D61657472
Pulled By: cipolleschi
fbshipit-source-id: 7a369f8e3ca902536a7608fbe1b89cec7734c418
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46176
Noticed that ModalHostView's event dispatching would sometimes fallback to RCTEventEmitter, which is not supported in the new architecture. Instead, we should propagate the reactTag to the inner content view so we can correctly associate the right UIManager and host component with events emitted.
Changelog: [Android][Fixed] PointerEvents from Modal would not be dispatched correctly in new architecture.
Reviewed By: bvanderhoof
Differential Revision: D61671005
fbshipit-source-id: 6aad1ff609da81cf5e8f71c4e91be30713494679
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45966
JSI performs the check itself, no need to do it here. Plus, bytecode
bundles must not be zero terminated.
## Changelog:
[IOS] [FIXED] - Fixes NSDataBigString length calculation
Reviewed By: realsoelynn
Differential Revision: D61058869
fbshipit-source-id: 15b99ef13f9aebd11ff410d02c21db8e46cc6ac3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46156
Changelog: [internal]
This improves the handling of disconnected nodes in `IntersectionObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61656597
fbshipit-source-id: 6a39c878acc976ddc0789260106da104a3f2a57f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46157
Changelog: [internal]
This improves the handling of disconnected nodes in `MutationObserver`. Specifically:
* When observing a node, if the node is disconnected (unmounted) this is just a no-op (without logging errors). We can't observe an unmounted node.
* When disconnecting the observer, if the observed nodes are disconnected, we get the target shadow node from an internal map, which we always have access to if we successfully started observing the node. If this logs an error now, it's something to look into but it won't generally log it if the target is just disconnected. That will work correctly.
Reviewed By: bvanderhoof
Differential Revision: D61655856
fbshipit-source-id: d18a885350ef000fc563c85f6775ba864d184ad1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46138
jorge-cab noticed that filters on iOS do not fit the shape of the layer if we have rounded corners. Fix is pretty straight forward.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61612655
fbshipit-source-id: 91785ed10a039e031c5440bde131c1583ba3992a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46146
Changelog: [Internal]
`unit` is of type `UnitType`, so there's no reason to have a default case here.
i found this because my build failed when pulling in this dependency, there was a compiler flag that enforced that all cases must be enumerated. this seems like the right practice anyways.
Reviewed By: NickGerleman
Differential Revision: D61635463
fbshipit-source-id: b84b5518f2a17e792309f85ae91514a17abad295
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46103
Reducing the boundary of rerender of virtual lists. Previously with prop: "strictMode={true}" the VirtualizedList still re rendered each CellRenderer component. Because method getDerivedStateFromProps generated every time a new uniq state and the cells didn’t have a PureComponent. It helps to improve react performance for lists which have 5+ elements.
I reused recomended approach from react doc https://legacy.reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html#what-about-memoization
changelog: [internal]
Optimizing CellRenderer of VirtualizedList
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D61493434
fbshipit-source-id: 917a33e48bd2f18e8ac150e5701d2e7c45dbe879
Summary:
Clean up some dead code after some refactoring of RCTParagraphComponentView. cc cipolleschi
## Changelog:
[IOS] [FIXED] - Clean up RCTParagraphComponentView & RCTParagraphTextView
Pull Request resolved: https://github.com/facebook/react-native/pull/46125
Test Plan: CI green.
Reviewed By: christophpurrer
Differential Revision: D61603193
Pulled By: cipolleschi
fbshipit-source-id: a357e8c5355707b2296462de513010acda4ee6ea
Summary:
In the recent 0.75 release I've noticed new `CONFIG_CMD` option in `react-native-xcode.sh`. But this option was not used. Insted when set `CONFIG_APP` was used.
This seems like a bug. As the usage before this PR would be as follow:
```bash
export CONFIG_CMD=true
export CONFIG_APP="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
After this PR
```
export CONFIG_CMD="/path/to/node /path/to/node_modules/react-native/cli.js config"
```
This PR also removed unused explicite `--config-cmd "$CONFIG"` flag, as this is always overwriten by the code above, by default to `--config-cmd" "$NODE_BINARY $NODE_ARGS $REACT_NATIVE_DIR/cli.js config`.
## 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
-->
[iOS][Fixed] - Use CONFIG_CMD if set
Pull Request resolved: https://github.com/facebook/react-native/pull/46112
Test Plan: I've set `CONFIG_CMD` and run Xcode Release build to check that the set command is executed.
Reviewed By: christophpurrer
Differential Revision: D61545010
Pulled By: blakef
fbshipit-source-id: ebbf8ebc08404bc6816277518a3b86c6f7e41e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46131
React native 0.75.0, 0.75.1 and 0.75.2 has been published to NPM without the latest tag, despite the tag being on the commit.
When debugging why that's happened, I realized that we were not downloading the tags when checking out the repo.
This change fixes that.
{F1816667285}
## Changelog:
[Internal] - Publish React native as latest when the latest tag is specified on git
Reviewed By: cortinico
Differential Revision: D61593398
fbshipit-source-id: 96bf8346207f0bd0b01f60ee09879210d12d30af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46132
Temporaily disable the `nativeSourceCodeFetching` capability — which reverts this to the legacy handling in the Inspector Proxy.
This is because we've noticed performance issues when loading large bundle source maps, particularly on Android, with a nontrivial path to optimising this ([raising the frontend `IO.read` size](https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/97) further is leading to WebSocket disconnections on Android 😐).
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61543480
fbshipit-source-id: ee66b4cebd40f8cc6466270c5875df744d2b588a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46113
changelog: [internal]
This showed promised in local tracing but that failed to translate to real perf improvement. Unshipping.
Reviewed By: christophpurrer
Differential Revision: D61537744
fbshipit-source-id: 03a2a69a6fed32a6b493bc17372e3783b9db2d1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46122
Implements a JavaScript cache for `colorScheme` in the `Appearance` module, so that we avoid potentially expensive and unnecessary native property accesses.
Changelog:
[General][Changed] - Improved `Appearance.getColorScheme` performance
Reviewed By: rickhanlonii
Differential Revision: D61567880
fbshipit-source-id: ca316946d68114b05239daa17105c85e637efe07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46120
Currently, the implementation of `Appearance` duplicates the validation logic of string `colorScheme` values multiple times.
This leads to more complicated code and also unnecessary work in certain edge cases (e.g. when `NativeAppearance` is not registered).
This refactors `Appearance` to be simpler and to do less work. I've also configured `NativeAppearance.setColorScheme` to be non-nullable because it has existed since 2023.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567881
fbshipit-source-id: 61cb51709dc716ad97ae1397105414e74fe57a28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46121
Updates `Appearance` on Android to supply the native module to `NativeEventEmitter` so that the native listener count can be managed like it is on iOS.
This was previously required by macOS and iOS. Android and Windows also already implement:
```
interface NativeModule {
addListener(eventType: string): void;
removeListeners(count: number): void;
}
```
So we should start passing `NativeAppearance` into the `NativeEventEmitter` constructor across all platforms.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D61567883
fbshipit-source-id: 1b3b76de9be3f35cacba1acbc43f6dcc0b41fde5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45859
"Fabric without SVCs" configuration is nearly gone, and so it doesn't make sense to need to add no-op methods, on normally Paper only code, etc to satisfy native viewconfig. These particular warnings are then more often noise, than things we need to action on.
Checking for native code to be present can also break development where users are using distributed native app, slightly older than JS.
This keeps the warning, only if static viewconfigs are missing native view config attributes (i.e. new prop would only be exposed to Paper, instead of only exposed to Fabric)
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60575253
fbshipit-source-id: 1c118274b92eb7922c0dd92df060b24e44fceb3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46116
If your app raises an early js exception, and you cold start it, often you'll see this error:
```
SurfaceRegistryBinding::startSurface failed. Global was not installed.
```
{F1807125099}
The reason why is because two different threads race to redbox:
* The nativemodule thread: the early js error (reported [here](https://fburl.com/code/vcrqzsdp))
* The javascript thread: the SurfaceRegistryBinding error (a subsequent native -> js call)
After this diff, the early js error will **not jump onto the nativemodule thread** to report this error.
This ensures that we "always" (to the best of my knowledge) see the early js error first.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D61339213
fbshipit-source-id: f1b9ab30150b87377817c2fd93ca349c406db48b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46104
We want to use `PrecomputedText` to store glyph-level measurements on underlying Android Spannable. This means we need to consistently reuse the same Spannable, instead of recreating them on measurement.
We have an opaque cache ID used by Android, for spannables originating from uncontrolled TextInput on UI-thread side. We also have `AttributedStringBox`, for a kind of similar purpose on iOS, which allows passing opaque pointer to the `TextLayoutManager`. This is only used for the `measure` function.
This change makes us consistently use `AttributedStringBox` at the TextLayoutManager boundary, to let us migrate calls across TextLayoutManager to all pass opaque handle to underlying Spannable we will store, instead of passing the AttributedString each time. For now, every place previously passing an AttributedString value still passes one.
There were also some egregious cases of accepting very large structures by value, causing unneeded copies. I changed the APIs to accept anything potentially larger than two pointers to pass by reference instead.
This change is technically breaking, to any 3p code calling into TextLayoutManager (IIRC live-markdown exposed prefabs for this, but should be able to adapt fairly easily).
Changelog:
[General][Breaking] - Always use AttributedStringBox instead of AttributedString in TextLayoutManager
Reviewed By: joevilches
Differential Revision: D61484999
fbshipit-source-id: 07c5600cd917f2dab3d24559a25f27e0872ebddc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46080
1. Force the examples to be alphabetized, where the hand-maintained list has some examples that are not
2. Remove reundant/not useful UI
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61430910
fbshipit-source-id: 1f3e116fe81502faa7a72f2720912e26c9f04bb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46076
This will add the shadows to iOS as well. let's see if anyone notices 🙂. I also removed dead styles, and removed some of the extra (excessive) padding specific to Android where the previous shadows would overlap.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D61421903
fbshipit-source-id: 887fa5aa96e3b0b4f81114ee814897c218db2b76
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46117
Currently in large cursive blocks like layout effect we can't tell what the slow leaf function is. With this fixed I'm able to root cause more complex issues in layout effects.
Reviewed By: NickGerleman
Differential Revision: D61486415
fbshipit-source-id: 5a4043b35eedcabcbea86953aac2173f66d7257b
Summary:
Fixes these issues:
- https://github.com/facebook/react-native/issues/46070
- https://github.com/facebook/react-native/issues/39362
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fixed black strip coming when hiding status bar
`setHidden` function is responsible for hiding status bar
https://github.com/facebook/react-native/blob/25d6a152cc720e0d5f860dab228ac2e43321d9e4/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/modules/statusbar/StatusBarModule.kt#L122
**What real issue is?** **_For android devices with camera area on top a black strip is coming after hidding status bar._**
Previous Implementation:
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
Log.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
It seems that FLAG_FULLSCREEN flag are not enough to draw content in camera area.
**Solution:**
In order to tackle this, android exposes 2 flags:
- [layoutInDisplayCutOutMode](https://developer.android.com/reference/android/view/WindowManager.LayoutParams#layoutInDisplayCutoutMode): The window is always allowed to extend into the [DisplayCutout](https://developer.android.com/reference/android/view/DisplayCutout) areas on the short edges of the screen. [Android 9.0 and above]
- [setDecorFitsSystemWindows](https://developer.android.com/reference/android/view/Window#setDecorFitsSystemWindows(boolean)): allows content to be able to extend into the cutout area. [Android 10.0 and above]
By adding this flag we are now able to hide status bar properly.
```
override fun setHidden(hidden: Boolean) {
val activity = currentActivity
if (activity == null) {
FLog.w(
ReactConstants.TAG,
"StatusBarModule: Ignored status bar change, current activity is null.")
return
}
UiThreadUtil.runOnUiThread(
Runnable {
val window = activity.window ?: return@Runnable
if (hidden) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
// Ensure the content extends into the cutout area
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES
window.setDecorFitsSystemWindows(false)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
} else {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
window.attributes.layoutInDisplayCutoutMode =
WindowManager.LayoutParams.LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT
window.setDecorFitsSystemWindows(true)
}
window.addFlags(WindowManager.LayoutParams.FLAG_FORCE_NOT_FULLSCREEN)
window.clearFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN)
}
})
}
```
**_Note: This will work above Android 11 and above_**
Pull Request resolved: https://github.com/facebook/react-native/pull/46086
Test Plan:
- Tested by author of this issue
- Sharing here the videos of before and after fix
Device Detail:
Oneplus9 5G OS 11
**Before fix:**
https://github.com/user-attachments/assets/589098ff-a3fa-4962-a15b-ceacbfd03d2d
**After fix:**
https://github.com/user-attachments/assets/a87dd8e4-3624-4e09-99da-a14f9e19fcc6
Reviewed By: cipolleschi
Differential Revision: D61509889
Pulled By: alanleedev
fbshipit-source-id: 733962a3bed2efba71588a4d2fdf7c9c386bc3b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46101
Remove overriding thread priority for RN Main Thread as it is not possible to update main thread.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D61448536
fbshipit-source-id: 44ec28a875e3208df042ac11bdd17a7287836ebb
Summary:
Our app is using the react-native v0.74.2 with the `react-navigation` lib for screen navigation, we're facing an issue in the built iOS app that when we try to navigate to a new app screen with the `react-navigation`'s `reset` or `replace` method and meanwhile there's a react native modal displaying, then the iOS app always crashes.
I saw there is already a relevant [PR](https://github.com/facebook/react-native/pull/38491) and discussion targeting this issue, but I still think it would be better if this kind of crash can be suppressed in the framework level, currently I guess it's common in the iOS apps based on react native.
## Changelog:
[IOS] [FIXED] - app crash happening when navigate to a new app screen with a displaying modal
Pull Request resolved: https://github.com/facebook/react-native/pull/45313
Test Plan: More issue details and the reproduction steps can be found in this [PR](https://github.com/facebook/react-native/pull/38491) :)
Reviewed By: christophpurrer
Differential Revision: D61537167
Pulled By: cipolleschi
fbshipit-source-id: 3c0474d794b4216ebc073dd6558d2b6ae27492d2
Summary:
Setting a variable called `REACTNATIVE_MERGED_SO` so libraries/apps can selectively decide to depend on either libreactnative.so or link against a old prefab target (this is needed for React Native 0.76 on).
## Changelog:
[INTERNAL] - Set REACTNATIVE_MERGED_SO for React Native 0.76
Pull Request resolved: https://github.com/facebook/react-native/pull/46114
Test Plan: CI
Reviewed By: hezi
Differential Revision: D61541372
Pulled By: cortinico
fbshipit-source-id: b16fa29ce6dd1670b452848e37cfcd7be15861e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46068
This change adds some internal E2E tests to verify that the text is rendered properly on top of a solid background color when borderWidth is set
## Changelog
[Internal] - Add E2E tests
Reviewed By: cortinico
Differential Revision: D61392253
fbshipit-source-id: 76e11821eba96ac75b055c5fe94365197c0f9be2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46081
This change fixes an issue that has been reported by OSS where a Text with both background color and borderWidth is not rendered properly.
The reason is that `RCTParagraphComponentView` uses the `drawRect` method which draws the text in the main view layer, while the parent `RCTViewComponentView` can apply an extraLayer on top of the base layer, drawing on top of the text.
This change moves the drawing of the text to an auxiliary view, `RCTParagraphTextView`, that is set as contentView of the `RCTParagraphView`. In this way, the text is drawn in a different view and can't be covered by the `_borderLayer`
## Changelog:
[Internal] - Introduce a RCTParagraphTextView to draw the text
Reviewed By: joevilches
Differential Revision: D61431369
fbshipit-source-id: 05467167186411fe42312f2ed956f5b5336de019
Summary:
This diff adds an example in RNTester to verify that we can draw text on top of a colored background and non uniform border radius.
As you can see from the test plan, the current code works well when:
* There is only the background color
* There is a background color and uniform cornerRadius
* There are non uniform border radius but the background is transparent.
The current code **does not** work when:
* there is a background and non-uniform border radius
* there is a background, uniform border radius and borderwidth
The reason why this happens is because:
* `RCTParagraphComponentView` draws the text in the View's main layer in the `drawRect` method
* `RCTViewComponentView` has a method `invalidateLayer` that, when there are non-uniform border radii o there is a borderWidth, it creates an extra `CALayer` with an image as content and that layer is put on top of the base layer, covering the text.
## Changelog
[Internal] - Add example to RNTester
Reviewed By: cortinico
Differential Revision: D61389317
fbshipit-source-id: 3e0a9e6c611190f90198a1b0b5855431b9f6ed12
Summary:
bypass-github-export-checks
Covers the case of an immediately-resolved breakpoint in `JsiIntegrationTest`, complementing the existing `ResolveBreakpointAfterReload` case.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61468055
fbshipit-source-id: 0f68656a2558166f1302163d14722c17c590044b
Summary:
- Color stops needs to follow [fix up spec](https://drafts.csswg.org/css-images-4/#color-stop-fixup)
- Adds multiple stops syntax support. e.g. linear-gradient(red 30% 50%, green).
- Rename `position` to `positions` in object style API. Optional string array here makes more sense. We'll add number array support once `px` support is added. Will do it as a follow up to this PR.
TODOs: transition hint syntax support `linear-gradient(red, 50%, green)` (Done locally, dependent on this PR). `px` support.
## Changelog:
[GENERAL] [FIXED] - Linear gradient color stop spec.
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45969
Test Plan: - Added testcases in processBackgroundImage-test.js
Reviewed By: javache
Differential Revision: D61309203
Pulled By: NickGerleman
fbshipit-source-id: 884052c6841320048933361f38e6478ff4192736
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45965
X-link: https://github.com/facebook/yoga/pull/1687
We are seeing some crashes that are hard to wrap our head around. Lets add more logs. I chose these values based on what could make the height/width undefined from looking at the code. We might need more but this should give us some more direction.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61054392
fbshipit-source-id: 654ff96f94aa89605a603e2e36335bb48b61f4a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46006
Adding some extra examples for mix-blend-mode
And added E2E tests for each mix-blend-mode example
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60605636
fbshipit-source-id: 553f3a2c3b971c918530bdee5a73108c22bd936e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46097
I've noticed we still have some tests here and there that were not migrated to AssertJ. This finishes them all.
Changelog:
[Internal] [Changed] - Finalize AssertJ migration
Reviewed By: javache
Differential Revision: D61473682
fbshipit-source-id: 3d51bfeb0e5ba3fd8cd4f3667dc88de3d88a3dbc
Summary:
## Summary
There are old references to the react-native/template. This code has
moved to react-native-community/template.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/46082
Test Plan:
CI
closesfacebook/metro#1324
Reviewed By: cipolleschi
Differential Revision: D61472439
Pulled By: blakef
fbshipit-source-id: fc40145c03002a7c3117b72d07981a96aa3d8760
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46074
This brings over the changes made to OutsetBoxShadowDrawable. Namely
1. Removing reliance on CSSBackgroundDrawable for drawing paths
2. Using BlurMaskFilter instead of RenderEffect
3. Removing RenderNode usage
This should make the implementation, more reliable less memory intensive for large boxes, and compatible down to Android API 29. I changed previous gating to allow outset shadows for 28+, and inset for 29+.
Changelog:
[Android][Changed] - Revamp InsetBoxShadowDrawable
Reviewed By: joevilches
Differential Revision: D61348615
fbshipit-source-id: 97b63b5dce65224ca54b76c5318c219973fc09fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46055
Changelog: [Android][Breaking]
BaseReactPackage is a 1:1 replacement for the deprecated TurboReactPackage. TurboReactPackage has been deprecated since 0.74. let's move the codebase to the recommended standard.
Reviewed By: cortinico
Differential Revision: D61329022
fbshipit-source-id: cef69e37bb2be7f6dccbab70d0996c33a8abf091
Summary:
## Summary
Flow will eventually remove the specific `React.Element` type. For most
of the code, it can be replaced with `React.MixedElement` or
`React.Node`.
When specific react elements are required, it needs to be replaced with
either `React$Element` which will trigger a `internal-type` lint error
that can be disabled project-wide, or use
`ExactReactElement_DEPRECATED`.
Fortunately in this case, this one can be replaced with just
`React.MixedElement`.
## How did you test this change?
`flow`
DiffTrain build for commit https://github.com/facebook/react/commit/85fb95cdffdd95f2f908ee71974cae06b1c866e1.
bypass-github-export-checks
Reviewed By: poteto
Differential Revision: D61397212
Pulled By: SamChou19815
fbshipit-source-id: c0aa5a4ed3922f88b7e557738f76f872c02a9d07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46059
This merges all the remaining dynamic libraries into libreactnative.so.
Sadly I couldn't split this in smaller diffs as all the libraries are connected with each other.
I also had to introduce 2 other SOs: `libhermestooling.so` and `libjsctooling.so` which contains
all the necessary libs used when loading either JSC or Hermes. They need to be isolated
as RNGP will remove those libraries based on the library the user decides to pick.
Changelog:
[Android] [Breaking] - Merge all the remaining .so libraries into libreactnative.so
Reviewed By: hezi
Differential Revision: D61376496
fbshipit-source-id: ab9e725b7acbebdfd8fa3ff36ad34d080044bf0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46057
We have a bunch of prefab targets which are no longer necessary. I'm removing them all in this first round of cleanup
Changelog:
[Android] [Breaking] - Remove several unnecessary android prefab targets. Use ReactAndroid::reactnative instead
Reviewed By: cipolleschi
Differential Revision: D61376497
fbshipit-source-id: e2e3cb38b1db712890f8bd58abadbdcb5cfaeec7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46010
X-link: https://github.com/facebook/hermes/pull/1474
Changelog:
[General][Added]: support for rendering Error object previews in Chrome DevTools console
On web, an array of Error objects have previews. This diff brings the parity to RN DevTools
Reviewed By: huntie
Differential Revision: D61243518
fbshipit-source-id: d9c6af4b44cef44cb63c4462eee649a8e498a429
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45883
Isolate property lets us easily define when a <View> should set a stacking context.
This is particularly useful when used with `mix-blend-mode`
Changelog: [Internal]
Reviewed By: christophpurrer, NickGerleman
Differential Revision: D60604683
fbshipit-source-id: 449079abe45ae57e98315bdf27b54ec5cf9d6fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45867
Before mix-blend-mode was blending with everything in the background, now we make it blend with just stacking context parent as spec by doing off-screen rendering.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60597403
fbshipit-source-id: 3af0c1266fde4ca32846785879d616316349369c
Summary:
Referring to the [iOS Large Content Viewer](https://developer.apple.com/videos/play/wwdc2019/261/):
iOS Tab Bars can't grow with dynamic text, but the Large Content Viewer helps them to be seen by people with low vision.
Currently on React Native we don't expose the properties that can help implementing iOS [UILargeContentViewerItem](https://developer.apple.com/documentation/uikit/uilargecontentvieweritem) protocol.
The goal of this PR is to expose the necessary props.
In this PR, I'm exposing 2 props:
- `accessibilityShowsLargeContentViewer`: to enable the large content viewer
- `accessibilityLargeContentTitle`: to define the large content viewer title
I plan to use this to open a PR on react-navigation so that bottom tabbars can implement largeContentViewer.
Should fix https://github.com/facebook/react-native/issues/30892
## Changelog:
[IOS] [ADDED] - Support LargeContentViewer on iOS for better accessibility
Pull Request resolved: https://github.com/facebook/react-native/pull/45903
Test Plan: <img width="300" src="https://github.com/user-attachments/assets/d8f1dc46-66e7-4945-bc3b-f1d29044441b" />
Reviewed By: cipolleschi
Differential Revision: D61148361
Pulled By: joevilches
fbshipit-source-id: 86dd92f4f79534a58e6e015febdaf217ea291eb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45985
As title.
We can now create ellipses when using percentages. The algorithm for this is still flawed and to get it to be a 1:1 to web it will probably require a re-write of some of the logic but this should get us closer for now.
Some examples:
1. Border thinning on large single corner radii (100%)
{F1798145800}
2. Thinning gets worse when having irregular border colors (100%)
{F1798148002}
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61025927
fbshipit-source-id: 218d44af014bc8351c329ff1bca82658aebac38c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46039
Broke during Kotlin conversion I assume
Image onSubmit events were failing with
```
FdingControllerListener E InternalListener exception in onSubmit
E java.lang.NullPointerException: Parameter specified as non-null is null: method com.facebook.react.views.image.ReactImageView$setShouldNotifyLoadEvents$1.onSubmit, parameter
callerContext
E at com.facebook.react.views.image.ReactImageView$setShouldNotifyLoadEvents$1.onSubmit(Unknown Source:9)
E at com.facebook.drawee.controller.ForwardingControllerListener.onSubmit(ForwardingControllerListener.java:75)
E at com.facebook.drawee.controller.AbstractDraweeController.reportSubmit(AbstractDraweeController.java:832)
E at com.facebook.drawee.controller.AbstractDraweeController.submitRequest(AbstractDraweeController.java:578)
E at com.facebook.drawee.controller.AbstractDraweeController.onAttach(AbstractDraweeController.java:468)
E at com.facebook.drawee.view.DraweeHolder.attachController(DraweeHolder.java:252)
E at com.facebook.drawee.view.DraweeHolder.attachOrDetachController(DraweeHolder.java:269)
E at com.facebook.drawee.view.DraweeHolder.onAttach(DraweeHolder.java:87)
E at com.facebook.drawee.view.DraweeView.doAttach(DraweeView.java:208)
E at com.facebook.drawee.view.DraweeView.onAttach(DraweeView.java:194)
E at com.facebook.drawee.view.DraweeView.onAttachedToWindow(DraweeView.java:168)
E at android.view.View.dispatchAttachedToWindow(View.java:20812)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
E at android.view.ViewGroup.addViewInner(ViewGroup.java:5290)
E at android.view.ViewGroup.addView(ViewGroup.java:5076)
E at com.facebook.react.views.view.ReactViewGroup.addView(ReactViewGroup.java:591)
E at android.view.ViewGroup.addView(ViewGroup.java:5016)
E at com.facebook.react.views.view.ReactClippingViewManager.addView(ReactClippingViewManager.java:41)
E at com.facebook.react.views.view.ReactClippingViewManager.addView(ReactClippingViewManager.java:21)
E at com.facebook.react.fabric.mounting.SurfaceMountingManager.addViewAt(SurfaceMountingManager.java:412)
E at com.facebook.react.fabric.mounting.mountitems.IntBufferBatchMountItem.execute(IntBufferBatchMountItem.java:119)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.executeOrEnqueue(MountItemDispatcher.java:387)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems(MountItemDispatcher.java:294)
E at com.facebook.react.fabric.mounting.MountItemDispatcher.tryDispatchMountItems(MountItemDispatcher.java:127)
E at com.facebook.react.fabric.FabricUIManager$DispatchUIFrameCallback.doFrameGuarded(FabricUIManager.java:1362)
E at com.facebook.react.fabric.GuardedFrameCallback.doFrame(GuardedFrameCallback.kt:22)
E at com.facebook.react.modules.core.ReactChoreographer$frameCallback$1.doFrame(ReactChoreographer.kt:59)
E at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1035)
E at android.view.Choreographer.doCallbacks(Choreographer.java:845)
E at android.view.Choreographer.doFrame(Choreographer.java:775)
E at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1022)
E at android.os.Handler.handleCallback(Handler.java:938)
E at android.os.Handler.dispatchMessage(Handler.java:99)
E at android.os.Looper.loopOnce(Looper.java:214)
E at android.os.Looper.loop(Looper.java:304)
E at android.app.ActivityThread.main(ActivityThread.java:7918)
E at java.lang.reflect.Method.invoke(Native Method)
E at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1010)
```
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D61332854
fbshipit-source-id: 48409e2b93abf15e846620580d1f0d07a2e75025
Summary:
Removed UIReturnKeyDefault as it caused bug when there wasn't any type.
## Changelog:
[IOS] [REMOVED]: UIReturnKeyDefault
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/46020
Reviewed By: christophpurrer
Differential Revision: D61277058
Pulled By: cipolleschi
fbshipit-source-id: 18349c49b05d492a2c2ed5713af3ceb6d3728e70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46034
The create release workflow was not working properly for 0.75:
* the latest tag was not pushed because we were using the wrong input
* the latest tag was not deleted because we were not fetching all the tags
* the create release job 'dry-run' defaults to false, which is a bit dangerous
This change is a backport from 0.75 to main of these changes.
## Changelog
[Internal] - Make sure that the Latest tag is properly pushed to github while releasing
Reviewed By: cortinico
Differential Revision: D61331247
fbshipit-source-id: 89bf0698c45ec6c766e25b11599dbe926d8a6297
Summary:
If a fatal error is caught in js, and the js pipeline isn't ready, route it through the c++ pipeline.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D60138414
fbshipit-source-id: 333e38e2b904d6434a88469816e39bf1b9d0bc3f
Summary:
If any fatal js error is caught in c++, just route it through js error handler.
Then, make js error handler call into the right pipeline:
1. After the js pipeline is ready: Route the errors through the js pipeline
2. Otherwise: Route errors through the c++ pipeline.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60138417
fbshipit-source-id: 24c466ffadbd14a9e9a5571548f3d34d2f406a8d
Summary:
## History
1. Originally landed in D60138415
2. Reverted in D60232011 (it broke ios oss builds)
## Motivation
In bridgeless, we want to configure the error handling of runtime scheduler. So that we can route those errors to the C++ error handling pipeline, when necessary.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D60477342
fbshipit-source-id: f14e20d7aff39e0fee42918567ccc6e685674134
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46023
Minimizing and restoring a Mac Catalyst app causes an `interfaceOrientationDidChange` which causes a downstream crash on `application.delegate.window`.
There doesn't seem to be a clean way to get if an app is fullscreen in Mac Catalyst, so just no-oping for now.
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D61253706
fbshipit-source-id: 73d260366adcc74e88f43f256cc5aff8a6e3ef71
Summary:
This PR solves [issue](https://github.com/facebook/react-native/issues/45958) with displaying irregular borders on Fabric. The same issue appears on the old architecture, but I am having a problems there, so I am pushing this fix for now.
The problem is solved by decoupling `backgroundColor` from `borderLayer` and setting `zPosition` on `borderLayer` to `1024.0f`, so that the border is always in front of the layer. The `zPosition` is compared within a layer, so it shouldn't impact outside components. I would love to hear your opinion if there is a case in which this could break.
## Changelog:
[IOS] [FIXED] - changed border display
Pull Request resolved: https://github.com/facebook/react-native/pull/45973
Test Plan:
I've checked that on RNTester Images.

Reviewed By: joevilches
Differential Revision: D61119409
Pulled By: cipolleschi
fbshipit-source-id: a88912061c7a8d72eec4f4092adb076dd6ae511e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45927
This was attempted earlier in the year, and was unsuccessful because HelloWorld had a hidden dependency on this.
Changelog: [General][Breaking] Projects that intend to use the community CLI will now have to declare that dependency instead of transitively having the react-native package handle this.
Reviewed By: GijsWeterings
Differential Revision: D60898346
fbshipit-source-id: 1d62615f718e06caf684f48ecfaf610bf1f51f8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45982
Changelog: [Internal]
Recently `src/private/renderer/errorhandling/ErrorHandlers.js` started showing up in some error stack traces, making LogBox less readable. This diff ensures we collapse these extra stack frames by default (as well as hide them in Fusebox, etc).
Reviewed By: hoxyq
Differential Revision: D61128294
fbshipit-source-id: 2ebcb47265aaf3281b669ed022c29978167f3e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45873
I'm removing the Gradle dependency on OSS SoLoader and stubbing it with our own implementation.
This will allow us to implement merging of further .so libraries and
As Fresco also depends on SoLoader, I had to stub the `NativeLoader` dependency as well.
Changelog:
[Android] [Breaking] - Do not depend on OSS SoLoader anymore and do not expose Fresco `api` dependency.
Reviewed By: mdvacca
Differential Revision: D60652007
fbshipit-source-id: 6e70a5c37ba9337fbe8772e192b886ba4693c7f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46005
The RCTDevLoadingView is clipped in Mac Catalyst, hiding half of it under the toolbar. This change maintains the behavior on iOS of extending past the dynamic island.
{F1803665273}
Changelog: [Internal]
Reviewed By: shwanton
Differential Revision: D61209780
fbshipit-source-id: 6c9c572a9e47a8caf191c40fb53c4a7d43b64281
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45984
A few methods were not synchronized, exposing members like `mTagsToViews` to potential out-of-sync access.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61151447
fbshipit-source-id: 696dbec559968cdfc7c6d2e662f4c8f3471039e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45998
The exact `React.Element` type is deprecated and will be removed in a future version of Flow.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D61205640
fbshipit-source-id: a029a3a46c7d8d9f94b0b931b991b2ce461151b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45974
This change fixes the E2E tests on the template on main.
There were two issues:
1. we were forcing the project on the 0.75 branch. We now use the current branch name
2. we were replacing all the versions for the dependencies that starts with `react-native` to the monorepo version. The problem is that also `react-native-community` packages starts with `react-native`. We now changes the versions if the dependency name starts with `react-native/`.
## Changelog:
[Internal] - Fix E2E tests on main
Reviewed By: cortinico
Differential Revision: D61122154
fbshipit-source-id: 07210fc9f63e99eac46894f13c7ca5359e186e6c
Summary:
`RCTSharedApplication().delegate.window.safeAreaInsets.bottom;` causes a crash in Mac Catalyst.
There is already precedent of a `#if TARGET_OS_MACCATALYST` in the same file. This just defaults it to 0 in that case, which looks fine.
## Changelog:
[iOS] [Fixed] - Mac Catalyst crash in RCTRedBox
Reviewed By: shwanton
Differential Revision: D61160503
fbshipit-source-id: 5771ebff88242d9dd4b892d8823e15d1f2307728
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45986
This uses SkBlurMaskFilter under the hood, to draw geometry of a solid color with alpha blur, without going the route of full image filter/rasterization. It was not supported under hardware accelerated canvases for a while, but seems to fully work as of API 29.
Requiring Android 10 instead of 12 makes box shadows a lot more palatable (80% support vs 50%), and we see drastically better performance in one case with many large shadows, where creating many large hardware layers previously drastically hurt framerates.
{F1801807696}
At this point, the RenderNode may be redundant, though I think it can technically save us some work on redraws still. It is kept around for now. I simplified some of the math around here as well.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D61162637
fbshipit-source-id: 8f6ff486e655e64a0665c31391359c499c374c8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45987
This is a confusing public API, because styles layer deals with DIPs, conversion only happens when parsing dynamic, and `POINT` (the `LengthPercentageType`) also maps to DIPs instead of physical pixels.
This moves conversion to physical pixels to drawing layer, so everything above `BackgroundStyleApplicator` works with `style` types which are all in DIPs.
To preserve compatibility with existing APIs using raw radii, we keep it so that (most) views operate in pixel units, while view managers operate under DIPs.
Changelog: [Android][Breaking] Do not implicitly convert parsed LengthPercentage to pixels
Reviewed By: rshest
Differential Revision: D60507151
fbshipit-source-id: b90066af7b221304aded374627fc0e2165dfc08f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45947
This adjusts logic to be similar to InsetBoxShadowDrawable to keep the full ink within RenderNode bounds. This avoids a tiny bit of overdraw, but also means we get correct rendering if RenderNode is promoted to a compositing layer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60972085
fbshipit-source-id: 0916733c6abae37e30dd1f64a36c0e211e41917e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45963https://chromedevtools.github.io/devtools-protocol/tot/HeapProfiler/#method-takeHeapSnapshot
As per `HeapProfiler.takeHeapSnapshot` documentation, there are a few
more configurable options to what is contained in the snapshot. Adding
a struct and the `captureNumericValue` bool to the interface since
that's what we need right now. In the future, there is the
`exposeInternals` parameters that's currently experimental for Chrome.
Changelog: [Internal]
Reviewed By: neildhar
Differential Revision: D60989352
fbshipit-source-id: fcd269f0db5b24983631206a1b738dea29566f0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45944
This diff adds support having (Legacy) Native Modules with functions with parameters of type `Dynamic`.
This is currently blocking some libraries making it harder for them to migrate to New Architecture.
I've implemented it by adding a `DynamicNative` implementation of `Dynamic` which holds a reference of
the payload as a `folly::dynamic`.
Changelog:
[Android] [Added] - Add support for handling `com.facebook.react.bridge.Dynamic` as parameter type in TurboModules
Reviewed By: mdvacca, cipolleschi
Differential Revision: D60966684
fbshipit-source-id: 2e63bc53ede5277a9c12f1b19f05f6099f5f35f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45736
This was an internally used class that was made irrelevant by Kotlin conversion. Appears to be unused in OSS, no breakages expected.
Changelog:
[Android][Breaking] - Deleted LongArray
Reviewed By: sammy-SC
Differential Revision: D60292651
fbshipit-source-id: cebb3d41113ad9f3247c3189889337d6e3e4ebab
Summary:
I maintain the `react-native-svg` library, where our elements extend `ReactViewGroup`. Currently, `ReactViewGroup` only exposes the getter for `mPointerEvents` publicly, so we cannot set it. To properly handle `pointerEvents`, we would have to duplicate all methods related to `mPointerEvents`, which results in maintaining a separate state. This duplication can lead to desynchronization between the state in our class and the state in the superclass.
PR with a workaround that we can avoid with this change https://github.com/software-mansion/react-native-svg/pull/2395
## Changelog:
[ANDROID] [CHANGED] - make `setPointerEvents` public
Pull Request resolved: https://github.com/facebook/react-native/pull/45975
Test Plan: This change was tested manually by making the field public, allowing dependent classes to override or reference it.
Reviewed By: cortinico
Differential Revision: D61124293
Pulled By: javache
fbshipit-source-id: 389d0a670375a8a68c975294f98c33c28ef41ffe
Summary:
When integrating react-native into react-native-windows, we got the following build warning (which we treat as an error) when building ReactCommon: `C4715 not all control paths return a value`
This PR adds defaults to the switches to make sure every path returns a value.
See https://github.com/microsoft/react-native-windows/issues/13516
## Changelog:
[GENERAL] [FIXED] Fix "C4715 not all control paths return a value" warning in MSVC when building ReactCommon
Pull Request resolved: https://github.com/facebook/react-native/pull/45827
Test Plan: The switches are checking enums this code should never be hit unless new enum values are added.
Reviewed By: robhogan
Differential Revision: D61103286
Pulled By: NickGerleman
fbshipit-source-id: 2028cb60e0b438b9ac17a828f5e1b690052a0bec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45345
When React diffs props, it can can short-circuit nested objects if their object identity hasn't changed. Whenever we use `flattenStyle` we prevent this optimization from taking place.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D59518281
fbshipit-source-id: e88ca781ab4622b5342169f8f27b09f0515513b3
Summary:
When using `TSan` while running the Unit tests of `RNTester`, there are a few data races picked up. One is described [here](https://github.com/facebook/react-native/issues/45280), while this PR deals with a race related to concurrent read/write of `ReactMarker::logTaggedMarkerImpl`. Here is the `TSan` output:
```
WARNING: ThreadSanitizer: data race (pid=5236)
Read of size 8 at 0x00011a602690 by thread T34:
#0 std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator bool[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x18cd49c)
https://github.com/facebook/react-native/issues/1 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator bool[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x18cd2bc)
https://github.com/facebook/react-native/issues/2 facebook::react::JSIExecutor::initializeRuntime() <null> (RNTesterUnitTests:arm64+0x1c96818)
https://github.com/facebook/react-native/issues/3 facebook::react::NativeToJsBridge::initializeRuntime()::$_0::operator()(facebook::react::JSExecutor*) <null> (RNTesterUnitTests:arm64+0x1a7a074)
https://github.com/facebook/react-native/issues/4 decltype(std::declval<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&>()(std::declval<facebook::react::JSExecutor*>())) std::__1::__invoke[abi:ue170006]<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*>(facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79fbc)
https://github.com/facebook/react-native/issues/5 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*>(facebook::react::NativeToJsBridge::initializeRuntime()::$_0&, facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79e5c)
https://github.com/facebook/react-native/issues/6 std::__1::__function::__alloc_func<facebook::react::NativeToJsBridge::initializeRuntime()::$_0, std::__1::allocator<facebook::react::NativeToJsBridge::initializeRuntime()::$_0>, void (facebook::react::JSExecutor*)>::operator()[abi:ue170006](facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a79d84)
https://github.com/facebook/react-native/issues/7 std::__1::__function::__func<facebook::react::NativeToJsBridge::initializeRuntime()::$_0, std::__1::allocator<facebook::react::NativeToJsBridge::initializeRuntime()::$_0>, void (facebook::react::JSExecutor*)>::operator()(facebook::react::JSExecutor*&&) <null> (RNTesterUnitTests:arm64+0x1a75250)
https://github.com/facebook/react-native/issues/8 std::__1::__function::__value_func<void (facebook::react::JSExecutor*)>::operator()[abi:ue170006](facebook::react::JSExecutor*&&) const <null> (RNTesterUnitTests:arm64+0x1abac9c)
https://github.com/facebook/react-native/issues/9 std::__1::function<void (facebook::react::JSExecutor*)>::operator()(facebook::react::JSExecutor*) const <null> (RNTesterUnitTests:arm64+0x1aba9d0)
https://github.com/facebook/react-native/issues/10 facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8::operator()() const <null> (RNTesterUnitTests:arm64+0x1aba8d4)
https://github.com/facebook/react-native/issues/11 decltype(std::declval<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>(facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&) <null> (RNTesterUnitTests:arm64+0x1aba6d4)
https://github.com/facebook/react-native/issues/12 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&>(facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8&) <null> (RNTesterUnitTests:arm64+0x1aba4f8)
https://github.com/facebook/react-native/issues/13 std::__1::__function::__alloc_func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8, std::__1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x1aba45c)
https://github.com/facebook/react-native/issues/14 std::__1::__function::__func<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8, std::__1::allocator<facebook::react::NativeToJsBridge::runOnExecutorQueue(std::__1::function<void (facebook::react::JSExecutor*)>&&)::$_8>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x1ab4918)
https://github.com/facebook/react-native/issues/15 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/16 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/17 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x4af18c)
https://github.com/facebook/react-native/issues/18 facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x51595c)
https://github.com/facebook/react-native/issues/19 facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1::operator()() const <null> (RNTesterUnitTests:arm64+0x529df0)
https://github.com/facebook/react-native/issues/20 decltype(std::declval<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529b54)
https://github.com/facebook/react-native/issues/21 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529978)
https://github.com/facebook/react-native/issues/22 std::__1::__function::__alloc_func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x5298dc)
https://github.com/facebook/react-native/issues/23 std::__1::__function::__func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x524518)
https://github.com/facebook/react-native/issues/24 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/25 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/26 invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) <null> (RNTesterUnitTests:arm64+0x515384)
https://github.com/facebook/react-native/issues/27 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ <null> (CoreFoundation:arm64+0x8dc0c)
https://github.com/facebook/react-native/issues/28 __NSThread__start__ <null> (Foundation:arm64+0x645c60)
Previous write of size 8 at 0x00011a602690 by main thread:
#0 std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::swap[abi:ue170006](std::__1::__function::__value_func<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>&) <null> (RNTesterUnitTests:arm64+0x43b078)
https://github.com/facebook/react-native/issues/1 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::swap(std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>&) <null> (RNTesterUnitTests:arm64+0x433100)
https://github.com/facebook/react-native/issues/2 std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>& std::__1::function<void (facebook::react::ReactMarker::ReactMarkerId, char const*)>::operator=<registerPerformanceLoggerHooks(RCTPerformanceLogger*)::$_1, void>(registerPerformanceLoggerHooks(RCTPerformanceLogger*)::$_1&&) <null> (RNTesterUnitTests:arm64+0x432d50)
https://github.com/facebook/react-native/issues/3 registerPerformanceLoggerHooks(RCTPerformanceLogger*) <null> (RNTesterUnitTests:arm64+0x4170fc)
https://github.com/facebook/react-native/issues/4 -[RCTCxxBridge initWithParentBridge:] <null> (RNTesterUnitTests:arm64+0x416504)
https://github.com/facebook/react-native/issues/5 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf6f4)
https://github.com/facebook/react-native/issues/6 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/7 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/8 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7de8)
https://github.com/facebook/react-native/issues/9 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Location is global 'facebook::react::ReactMarker::logTaggedMarkerImpl' at 0x00011a602678 (RNTesterUnitTests+0x438a690)
Thread T34 (tid=11229216, running) created by main thread at:
#0 pthread_create <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2bee4)
https://github.com/facebook/react-native/issues/1 -[NSThread startAndReturnError:] <null> (Foundation:arm64+0x6458f0)
https://github.com/facebook/react-native/issues/2 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf748)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/4 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/5 -[RCTImageLoaderTests testImageLoaderUsesImageDecoderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0xbe8c)
https://github.com/facebook/react-native/issues/6 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
```
The proposed solution is to wrap `logTaggedMarkerImpl` in a class that has a static getter and setter wherein a read/write lock is employed. It is my understanding that `logTaggedMarkerImpl` is read several times, but only assigned rarely, and thus it seems appropriate with a read/write lock. The getter and setter functions are also inlineable, such that one should not need to make an extra function call when obtaining the `logTaggedMarkerImpl` instance.
In order to reproduce my findings and verify fix:
* Clone this branch
* Run setup code as described in README
* Execute `git revert -n 65998835c2198b9d626160a6883744801fa056a9 83a2a3c9b4e5ea588a6cc3a9281ad385a388b84a`
* Enable TSan for both `RNTester` and its test scheme.
* Enable Runtime issue breakpoint for TSan
* Run unit tests
* Observe the `TSan` breakpoint is hit (possibly other places in the codebase as well) when accessing `logTaggedMarkerImpl`. Continue execution if other breakpoints are hit before this breakpoint.
* Execute `git revert --abort`
* Run the tests again and observe the `TSan` breakpoint does _not_ hit said code again.
## Changelog:
[iOS][Fixed] Data race related to read/write on `ReactMarker::logTaggedMarkerImpl`
Pull Request resolved: https://github.com/facebook/react-native/pull/45557
Test Plan: I believe there are existing tests that will cover the proposed changes.
Reviewed By: cipolleschi
Differential Revision: D60525080
Pulled By: dmytrorykun
fbshipit-source-id: 78b0ce2a660af0e29909ff68c018698a9a1e29f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45837
Some Internal tests in the old architecture were failing after landing [#45414](https://github.com/facebook/react-native/pull/45414) because the `RCTNativeAnimatedModule` in the old architecture was not declaring the event.
This change fixes it by declaring the event that is never fired in the Old Architecture as it is not needed.
## Changelog
[iOS][Added] - Declare the `onUserDrivenAnimationEnded` in the old Architecture
Reviewed By: sammy-SC
Differential Revision: D60499584
fbshipit-source-id: 581a30a88dbd6d8d67078a11699157c55ed19e58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45839
Pull Request resolved: https://github.com/facebook/react-native/pull/45414
This change completes the fix for broken pressable when animations were applied to components with native driven animations.
When creating the AnimatedProps, if they are natively drive animation, we look for the AnimatedValue involved and we register a listener. This is needed to make sure that the NativeModule will send te updated value upon calling the `update` function.
Then, when observing the props lifecycle, it register a listener to the new `OnUserAnimationEnded` event, fired by the NativeAnimation module.
When the `OnUserAnimationEnded` event is fired, the AnimatedProps will update the props that depends on the user driven animation.
## Changelog
[General][Fixed] - reallign the shadow tree and the native tree when the user finishes interacting with the app.
Reviewed By: sammy-SC
Differential Revision: D60499583
fbshipit-source-id: 02d25e7ca31b91f4d6e4ec1654350e2d84117eda
Summary:
Fixes this issue: https://github.com/facebook/react-native/issues/45880
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [CHANGED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Replaced `mLastHeight` with `mVisibleViewArea.height()` since mLastHeight value is not getting updated. For `width` we are already using `mVisibleViewArea.width()`
Pull Request resolved: https://github.com/facebook/react-native/pull/45928
Test Plan: - Tested the fix in new and old architecture both
Reviewed By: christophpurrer
Differential Revision: D61023998
Pulled By: cortinico
fbshipit-source-id: df67616330effb7b9e6724d94b3be92c0dbd6190
Summary:
React-native 0.75 RC7 gradle sync is currently broken due to the fact that the `shared-testutil` folder is missing from the `react-native/gradle-plugin` npm package
## Changelog:
[INTERNAL] [ADDED] - Add shared-testutil folder to NPM files to be published
Pull Request resolved: https://github.com/facebook/react-native/pull/45936
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D60969631
Pulled By: cortinico
fbshipit-source-id: 850edfe0cf6b0e8174a1df9ea962d207d2ce0112
Summary:
This PR implements the missing `automicallyAdjustsKeyboardInsets` for new architecture. It's a fixed version of reverted: https://github.com/facebook/react-native/issues/45819
We now check if the view intersects with the keyboard's end frame and if it doesn't we just do nothing.
Here is the app running on new arch:
https://github.com/user-attachments/assets/673f0587-6a67-47e3-8050-d6ee33a45724
## Changelog:
[IOS] [FIXED] - implement automicallyAdjustsKeyboardInsets for new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/45939
Test Plan:
1. Test out ScrollViewKeyboardInsets example
2. See if it works the same with old and new arch
Reviewed By: cortinico
Differential Revision: D60958475
Pulled By: cipolleschi
fbshipit-source-id: 8650064af84bc79b6b89e07293640e5d010154c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45946
This code is forked on iOS, where we have been, as a policy, avoiding Paper-specific changes. This code is shared between renderers on Android, but it is confusing developer experience to have it work on Android Paper, to then fail on iOS unless it is on new arch.
This change disables support on Android Paper for consistency.
Changelog:
[Android][Removed] - Gate off % translate on Android Paper
Reviewed By: joevilches
Differential Revision: D60970266
fbshipit-source-id: 5df73b948464f5093941528b0af2e694827a9460
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45948
This change effectively reverts D59489788 which fixed Image implementation of `hasOverlappingRendering()`. When this is true, Android will draw offscreen, then composite the rasterized layer with alpha in one pass, instead of drawing each element with alpha (which results in incorrect rendering).
The unforseen downside is that this prevents drawing overflow, which means images with non-full opacity break box shadows and outline in the future.
This deserves a fuller fix... but in the meantime, I discovered we disable offscreen alpha in many of the core components already, with `<View>` as a major example requiring explicit opt-in. This is... kinda terrible, since `opacity` rendering is pretty broken on RN Android, but the status quo lets us avoid a pretty bad boxShadow bug for now.
Changelog:
[Android][Changed] - Avoid image ofscreen render
Reviewed By: Abbondanzo
Differential Revision: D60972846
fbshipit-source-id: 403714d6bb0527a7426feba3dafee05b6aefbb7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45950
Changelog:
[iOS][Deprecated] Deprecated StatusBar.setNetworkActivityIndicatorVisible
The status bar network activity indicator is deprecated in iOS 13. Setting its visibility has no effect in iOS 13 and later. It will be completely removed in a future release.
Reviewed By: philIip
Differential Revision: D60977517
fbshipit-source-id: 31e79113fffd0201c4393b61236d3911e82b40d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45805
After recent changes where we dive into paths ourselves, we really don't have a good reason to use the heavy CSSBackgroundDrawable. Accept a box shadow style in place of a reference to the original drawable, and then draw using calculated round rect path instead of new whole Drawable. This lets us avoid a lot of conversions as well (with the last diff already removing some).
This should also resolve a crash we started seeing:
```
androidx.core.util.Preconditions.checkNotNull (Preconditions.java:136) [inlined]
- com.facebook.react.uimanager.drawable.CSSBackgroundDrawable.drawRoundedBackgroundWithBorders (CSSBackgroundDrawable.java:386)
[inlined]
- com.facebook.react.uimanager.drawable.CSSBackgroundDrawable.draw (CSSBackgroundDrawable.java:142)
- com.facebook.react.uimanager.drawable.OutsetBoxShadowDrawable.draw (OutsetBoxShadowDrawable.kt:137)
- android.graphics.drawable.LayerDrawable.draw (LayerDrawable.java:1019)
```
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60401423
fbshipit-source-id: 693d9bf5e85956290db932cdb18f15ba26446894
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45945
This code is forked on iOS, where we have been, as a policy, avoiding Paper-specific changes. This code is shared between renderers on Android, but it is confusing developer experience to have it work on Android Paper, to then fail on iOS unless it is on new arch.
This change disables support on Android Paper for consistency.
Changelog:
[Android][Removed] - Gate off % border radii on Android Paper
Reviewed By: cortinico
Differential Revision: D60967347
fbshipit-source-id: 1d26bc71aee677aa9a0dc9bb38f781a99c7762a8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45783
Improves type strictness in the `react-native` package.
- Break out `URLSearchParams` from `URL.js` into its own module, to isolate a `$FlowFixMe[unsupported-syntax]` suppression within that definition.
- Update `public-api-test` to require an adjacent `<module>.js.flow` type definition file whenever a `$FlowFixMe[unsupported-syntax]`is present.
- Add `URLSearchParams.js.flow` with a Flow parser compatible typedef (`@iterator` instead of `[Symbol.iterator]`).
The result of these changes is to add missing typedef test coverage for `Libraries/Blob/URL.js` (see updated test snapshots).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D60376327
fbshipit-source-id: 93c0949289a4b53f621f563769ffb68d5dc38d91
Summary:
This PR fixes Cache repear
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
[INTERNAL] [FIXED] - Cache repear job
Pull Request resolved: https://github.com/facebook/react-native/pull/45943
Test Plan: CI Green
Reviewed By: blakef
Differential Revision: D60962822
Pulled By: cortinico
fbshipit-source-id: 453153005bbc1b99dbe569eb6be77d17c8a176db
Summary:
Added a check in setRemoteJSDebugEnabled in DevSupportManagerBase.java to check for PREFS_REMOTE_JS_DEBUG_KEY to see if the value has changed.
Fix for https://github.com/facebook/react-native/issues/45399 - App restarting when `NativeDevSettings.setIsDebuggingRemotely` is used in a landing component. If this was invoked from a component load or action that would fire on app start, it was creating an infinite loop where the app would keep on restart before eventually leading to a crash.
## Changelog:
[ANDROID] [FIXED] - Fix issue with `NativeDevSettings.setIsDebuggingRemotely` where the app would keep on restarting if remote debugging was invoked from an action / component that was called on app start.
Pull Request resolved: https://github.com/facebook/react-native/pull/45775
Test Plan:
Create a new project using RN CLI.
Set `newArchEnabled=false`.�
Install modules using `yarn install`.�
Build from source for Android by setting the following in `settings.gradle`-�
```
includeBuild('../node_modules/react-native') {
dependencySubstitution {
substitute(module("com.facebook.react:react-android")).using(project(":packages:react-native:ReactAndroid"))
substitute(module("com.facebook.react:react-native")).using(project(":packages:react-native:ReactAndroid"))
substitute(module("com.facebook.react:hermes-android")).using(project(":packages:react-native:ReactAndroid:hermes-engine"))
substitute(module("com.facebook.react:hermes-engine")).using(project(":packages:react-native:ReactAndroid:hermes-engine"))
}
}
```
Set the ANDROID_HOME and ANDROID_NDK_HOME environment variables required for react native.�Call `NativeDevSettings.setIsDebuggingRemotely` from App.tsx which is the landing component.�
Test with both `hermesEnabled=true` and `hermesEnabled=false` and ensure that app does not keep on restarting after fix.
Reviewed By: cipolleschi
Differential Revision: D60377406
Pulled By: huntie
fbshipit-source-id: c8faf184b50b67f50f8a4b6851df9d0ef3350949
Summary:
This diff sets up an experiment to use `useDebouncedEffect` for managing animated props lifecycle.
Changelog: [Internal]
bypass-github-export-checks
Facebook
This diff also defaults to `useDebouncedEffect` for managing animated props lifecycle in IGVR and FBVR.
Based on local tracing of FBVR, `useDebouncedEffect` results in **~19ms faster visual completion**.
Before we executed **54.2 ms** of passive effects vs **35.6 ms** after.
Reviewed By: josephsavona, rubennorte
Differential Revision: D60834116
fbshipit-source-id: 35d5eb4c4be18e716f96129911e66eaffe54bb17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45941
Quick fix to avoid imports from Swift chaining to Objective-C++ headers. Will follow up with a redesign.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D60960077
fbshipit-source-id: 4ce9507900196d5298c7885a99a5e4d786f76982
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45930
This introduces the `enableEventEmitterRetentionDuringGesturesOnAndroid` that allows us to gate the
fix for bug #45126 and #44610.
Changelog:
[Internal] [Changed] - Introduce the enableEventEmitterRetentionDuringGesturesOnAndroid to gate the Pressable fix
Reviewed By: mdvacca
Differential Revision: D60908117
fbshipit-source-id: 885917832718d9b90d043b2d7e2cdb47e0f01ea7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45865
This diff introduces the logic to defer the destruction of ViewState (and EventEmitter) for views that are currently touched on by the user. The idea is to let the UIManager know which view is currently active from the `JSTouchDispatcher` and eventually defer the view deletion till the view is not interacted anymore.
The JSTouchDispatcher already retains the information on which tag was the touch originally fired.
We'll pass over that information to the UIManager/SurfaceMountingManager so that it can be accounted for when the view has to be deleted.
This is causing a couple of bad bugs on Android:
Fixes https://github.com/facebook/react-native/issues/45126
Fixes https://github.com/facebook/react-native/issues/44610
Closes https://github.com/facebook/react-native/pull/45675
Changelog:
[Android] [Fixed] - Do not destroy views when there is a touch going on for New Architecture
Reviewed By: mdvacca
Differential Revision: D60594878
fbshipit-source-id: c3334d16cf305e0178f50772576050ebfbba85ec
Summary:
This PR enables the `cache-repear.yml` only for the main repository. This is running constantly on forks creating lots of notifications and it's mostly needed only for the main repo.

## Changelog:
[INTERNAL] [CHANGED] - Run `cache-repear.yml` only on main repo
Pull Request resolved: https://github.com/facebook/react-native/pull/45940
Test Plan: CI GREEN
Reviewed By: blakef
Differential Revision: D60957003
Pulled By: cortinico
fbshipit-source-id: 2f250d734688739a278095af8d860a54426604bf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45922
Introduce the ReactNativeNewArchitectureFeatureFlagsDefaults class, which initializes default values for ReactNativeFeatureFlags when the New architecture is enabled.
This class is meant to be overrode by ReactNativeNewArchitectureFeatureFlagsDefaults or others apps migrating to the new architecture.
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D60861873
fbshipit-source-id: b31ba947dae999fea8bb4effd63c56dc142a5c3d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45934
The OSS impl of gradient was wrong, and ends up skipping shadows if it is not defined. Fixed that.
Changelog: [Internal]
Reviewed By: jorge-cab
Differential Revision: D60917620
fbshipit-source-id: 3d4ea3e8084d33fa5d15fb82d45cfd063143087c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45850
Enables the `nativeSourceCodeFetching` capability flag for the modern debugger stack on both Android and iOS. This disables source code fetching hacks within the Inspector Proxy layer and instead enables the debugger server to handle all source code fetching directly on the device.
Changelog: [Internal]
Differential Revision: D60236216
fbshipit-source-id: 1239b4d7d2233852f007114721b202d90459fa06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45849
This fixes a bug where we were calling `delegate.didReceiveMessage` (and other handlers) from multiple threads on Android. In particular, with the addition of `Network.loadNetworkResource` in D54496969, we observed memory access issues in the implementation for `IO.read` in `NetworkIOAgent` after multiple successive requests are received.
This approach updates the Android-specific implementation of `IWebSocketDelegate` to schedule delegate handler and `close` calls on the inspector thread.
Changelog: [Internal]
Differential Revision: D60520747
fbshipit-source-id: 459b44b424157793faaf5967435e1303a0061292
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45664
Implement the `networkRequest` method of `jsinspector_modern::HostTargetDelegate` for Android (Bridge). This diff introduces a common `InspectorNetworkHelper` class that will be shared for the Bridgeless implementation.
This change allows the modern debugger server to handle CDP `Network.loadNetworkResource` (etc) requests. Notably, resources in the Chrome DevTools Sources panel will now be loaded by the backend.
Changelog: [Internal]
Differential Revision: D60036502
fbshipit-source-id: 5fdca7f34634c7541395041025bef62ddfad9eab
Summary:
This diff introduces the `useDebouncedEffect` hook. It should be used for expensive effects that can be scheduled asynchronously, not blocking the rendering.
Changelog: [Internal]
bypass-github-export-checks
Facebook
This a copy of https://www.internalfb.com/code/fbsource/xplat/js/RKJSModules/public/xplat-react/shared/core/react_hooks/DebouncedEffectImplementation.js
I put it here temporarily to be able to run an experiment with `Animated`. We should come up with a better way to introduce this hook to OSS.
I'm bypassing GH export to not to draw extra attention to this.
Reviewed By: rubennorte
Differential Revision: D60762745
fbshipit-source-id: c13b20424360493a7fc94dc27264591a7253f77f
Summary:
Building for the visionOS simulator in the Release scheme requires an x86_64 slice to be included.

## Changelog:
[IOS] [FIXED] - Include x86_64 slice when building for visionOS simulator
Pull Request resolved: https://github.com/facebook/react-native/pull/45911
Test Plan: CI Green
Reviewed By: GijsWeterings
Differential Revision: D60828872
Pulled By: cipolleschi
fbshipit-source-id: 74444ac0b6661baf427837d242ba0ca295da0d16
Summary:
This PR fixes few issues with Hermes scripts:
- Set visionOS vendored frameworks
- Fail if env variables are not set
## Changelog:
[INTERNAL] [FIXED] - Hermes script should fail when no deployment target is set
Pull Request resolved: https://github.com/facebook/react-native/pull/45841
Test Plan: Try to build Hermes
Reviewed By: blakef
Differential Revision: D60901886
Pulled By: cipolleschi
fbshipit-source-id: b9ff470ac6c07e1bd5abc7410ac0c366d66016c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45878
Changelog:
[General][Added] - Add optional `PackagerAsset.resolver` prop so AssetSourceResolver can use it instead of `Platform.OS` to identify where asset is stored on device.
Reviewed By: rshest
Differential Revision: D60447815
fbshipit-source-id: 44fb8510746905ca0cd266144e213c40a3fa86a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45917
Did this the right way for BorderStyle, but not for Overflow.
Changelog:
[Android][Fixed] - Gracefully handle unexpected overlow values
Reviewed By: necolas
Differential Revision: D60853891
fbshipit-source-id: e641e62e9e301681a1be190d8158f793ec17c1f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45860
This has been on by default for a long while.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D60579198
fbshipit-source-id: 4bd8a13dada8edf00489dc64b1ff4ff0364a8843
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45918
In this diff we are deprecating ReactFeatureFlags.enableBridgelessArchitecture, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable TurboModules.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.enableBridgelessArchitecture
Reviewed By: philIip
Differential Revision: D60853317
fbshipit-source-id: 2476bb81887893cedc8d43b117c10cd9d96bdee3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45920
In this diff we are deprecating ReactFeatureFlags.useTurboModules, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable TurboModules.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.useTurboModules
Reviewed By: philIip
Differential Revision: D60853315
fbshipit-source-id: 084ef8073daae16b288d82ececf770fd4b68e80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45921
In this diff we are deprecating ReactFeatureFlags.enableFabricRenderer, this flag will be deleted in the next version of ReactNative (0.77)
Please use DefaultNewArchitectureEntryPoint.load() to enable fabric instead.
changelog: [Android][Deprecated] deprecate ReactFeatureFlags.enableFabricRenderer
Reviewed By: philIip
Differential Revision: D60853316
fbshipit-source-id: f9883a68771c8db8f24269630b0950e96741cf9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45905
- Updating minSdk to 24 before we do the update for the RN
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D60788291
fbshipit-source-id: d21d766159a04d79547e64fca802600279d08255
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45916
When a Filter was removed by state update we missed this check which led to setting the layer type to HARDWARE incorrectly
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60840169
fbshipit-source-id: e375e7d25c85e9d031c1e1a0795c49687e0018e7
Summary:
- Adds `background` prop that supports CSS's linear gradient. Later this can be extended to support various other gradients and possibly CSS's background image (less motivation as better solutions exists for image)
- Uses `CAGradientlayer` to draw Linear Gradient layers. So it is GPU optimised under the hood.
- Style supports JS object to specify `LinearGradient`, so it can support Animated libraries.
## Changelog:
[IOS] [ADDED] - linear gradient
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45434
Test Plan:
- Check out `processBackground-test.js` for supported syntax testcases.
- Checkout example added in ViewExample.js
Although the PR is tested well but open to any changes/feedback on the approach taken.
Android PR - https://github.com/facebook/react-native/pull/45433. Separated the PRs to keep it easier to review. Both PRs can be reviewed individually.
Reviewed By: NickGerleman
Differential Revision: D60791581
Pulled By: joevilches
fbshipit-source-id: 051088fdf68d9fe20c0c306f1f1c591cbd77f3d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45915
We avoid recomputing the RenderNode display list for shadow shape when the inputs have not changed, but Android may clear the display list itself, in which case we need to recreate it.
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D60833553
fbshipit-source-id: fe1ea04b13f85dda6af2761693e7c664794235e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45913
Changelog: [Internal] - Call ViewManagers' onSurfaceStopped() before onDropViewInstance()
This allows `ViewManager` to call `mRecyclableViews.remove(surfaceId)` before it wastes time on `prepareToRecycleView()` for views in a stopped surface.
Reviewed By: sammy-SC
Differential Revision: D60806242
fbshipit-source-id: d5eaaa5443fcb1d9390d8b84e0b5069618bb175e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45885
There are some gaps here right now, but Android API 31+ is looking good.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60731848
fbshipit-source-id: f515270a61a00c362b584f0d1549d14098c2e385
Summary:
In build_npm_package, the publishing of the bumped template is [failing](https://github.com/facebook/react-native/actions/runs/10148492447/job/28063424722)
because it's running in sh instead of bash, but using bash syntax.
## Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45910
Test Plan:
~~I'm unclear on how to test this, and the fix is very much speculative based on other having hit a similar issue.~~
I've had to stub some of the values that the action substitutes.
Reviewed By: cortinico
Differential Revision: D60828697
Pulled By: blakef
fbshipit-source-id: 0a8f909ae5219268f034e5ff0efb8acc94bdb7b1
Summary:
We had CI on main failing consistently the past couple of days.
The problem is that the hermes pipeline is failing to create the iOS XCFramework with the error:
> unable to create a Mach-O from the binary at '/Users/runner/work/react-native/react-native/packages/react-native/sdks/hermes/destroot/Library/Frameworks/catalyst/hermes.framework/hermes'
The main cause is this upgrade of [upload-artifacts](https://github.com/actions/upload-artifact/issues/590) which breaks symlinks.
The solution is to bump the caches and downgrade the `upload-artifact` actions.
## Changelog:
[Internal] - Try to fix CI for Hermes
Pull Request resolved: https://github.com/facebook/react-native/pull/45908
Test Plan: GHA must be green
Reviewed By: cortinico
Differential Revision: D60828616
Pulled By: cipolleschi
fbshipit-source-id: 6976b86dd67e2fd9d806ebaa62f47e39dc44b30d
Summary:
Last month, during the migration to GHA, we decided to reimplement the same behavior we had in CCI: when a new commit comes in, we stop executing tests on the previous one.
This behavior is great to save money, but on main it has the side effect that it makes it hard to detect when the ci was broken.
\With this change, we want to disable this behvior on main while keeping it in PRs.
After this change, when a new commit arrives on main, the previous jobs will not be interrupted
## Changelog
[Internal] - Do not cancel jobs on main when new commits are pushed.
Reviewed By: cortinico, blakef
Differential Revision: D60822657
fbshipit-source-id: 38561438f2e2850a94220d732cd73a09d04e8b81
Summary:
This PR implements the missing `automicallyAdjustsKeyboardInsets` for new architecture.
After fixing this I've noticed there is an open issue (https://github.com/facebook/react-native/issues/45647) with somebody assigned (sorry shubhamguptadream11 for taking your task)
Here is the app running on new arch:
https://github.com/user-attachments/assets/673f0587-6a67-47e3-8050-d6ee33a45724
## Changelog:
[IOS] [FIXED] - implement automicallyAdjustsKeyboardInsets for new arch
Pull Request resolved: https://github.com/facebook/react-native/pull/45819
Test Plan:
1. Test out ScrollViewKeyboardInsets example
2. See if it works the same with old and new arch
Reviewed By: sammy-SC
Differential Revision: D60453404
Pulled By: cipolleschi
fbshipit-source-id: bd7ce5bac8facffc527106b50c54112acf687bc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45846
In general this diff fixes all crashes related to RTCImageUtills happened because of uncovered cases in switch.
In this current bug the problem was in this part of code
RCTTargetSize(imageSize, imageScale, frame.size, RCTScreenScale(), (RCTResizeMode)self.contentMode, YES);
when we cast UIViewContentMode to RCTResizeMode. RCTResizeMode doesnt cover all of UIViewContentMode values.
So just added default cases to swithces in places where it was lost.
Changelog:
[iOS][Fixed] - fixed crash in RCTImageUtils
Reviewed By: philIip
Differential Revision: D60523540
fbshipit-source-id: b8027537c600a7ca226e62238d16a6b05301d4de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45900
Changelog: [internal]
make `normalizeEventType` public, it looks like a nice util when we want to write code to intercept event, e.g. "scroll" event could be named as "onScroll" or "topScroll", this function contains the source of truth of how RN parses it
Reviewed By: christophpurrer
Differential Revision: D60767388
fbshipit-source-id: b3880fda57e2d92d9d199db5f5d39b8a8435820c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45899
Changelog: [internal]
replace ScrollViewEventEmitter::Metrics for ScrollEvent payload type created earlier
make ScrollViewEventEmitter::Metrics an alias of ScrollEvent as well
Reviewed By: christophpurrer
Differential Revision: D60767390
fbshipit-source-id: 8db88c0e1fa837b5dbad92d7bcce825882feaaf6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45851
Create ScrollEvent payload type, so we can unwrap the scroll event metrics if intercept it in C++
Changelog: [internal]
Reviewed By: christophpurrer
Differential Revision: D60526048
fbshipit-source-id: 219a690ccf67d0b1c90e3496b8e5970ab7e2a79b
Summary:
For the ones where `React.MixedElement` would suffice, I change them to `React.MixedElement`. For everything else, I changed it to be `React.Element`
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60798229
fbshipit-source-id: 40176b44769aade2c6b63a680d03c10056b2ddfa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45904
Flow will error on these dollar types soon. For all the ones changed here, they can all be further simplified.
Changelog: [Internal]
Reviewed By: gkz
Differential Revision: D60786768
fbshipit-source-id: e26bf0be1c4a933fc0bd8b59827e10cbd7242a83
Summary:
Adds changelog for the 0.74.5 patch.
## 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] [Changed] - Add 0.74.5 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45898
Reviewed By: christophpurrer
Differential Revision: D60768626
Pulled By: arushikesarwani94
fbshipit-source-id: 62196fc8a4fec1ff992ecc4622116b97dd96b79b
Summary:
I introduced a typo in https://github.com/facebook/react-native/issues/45486 . Thanks migueldaipre
for the catch-up. cc cipolleschi
## Changelog:
[IOS] [FIXED] - Fixes typo of function callFunctionOnBufferedRumtimeExecutor
Pull Request resolved: https://github.com/facebook/react-native/pull/45902
Test Plan: Just a typo.
Reviewed By: cipolleschi
Differential Revision: D60775511
Pulled By: arushikesarwani94
fbshipit-source-id: da781ea5ecf2e0a15e5419430240e10194043b1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45893
changelog: [internal]
This is mainly impact for the Event Loop where setting up of animation graph will no longer block paint.
Reviewed By: rubennorte
Differential Revision: D60648823
fbshipit-source-id: 8efa1dac2a42b14a609adae05e9266f78a181d43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45877
A couple fixes:
- Test was mixing up event names - refactored to make the code [hopefully] clearer
- Code potentially recreates `events` if it's a singleton map, but that was lost due to it not being returned
Changelog: [Internal] Minor fix to UIManagerModuleConstantsHelper
Reviewed By: cortinico
Differential Revision: D60609294
fbshipit-source-id: 3c82ba30b9401674e678585b1612324f885c9ae1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45743
This is a Java-centric class that can be replaced by Kotlin's map extensions.
Changelog:
[Android][Deprecated] Deprecate MapBuilder
Reviewed By: cortinico
Differential Revision: D60309106
fbshipit-source-id: 4a764fa1d59993dc735b2181a2270dc79a0e0396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44569
# Changelog:
[Internal] -
This converts the vertical of NativeArray/ReadableNativeArray/WritableNativeArray classes to Kotlin.
NOTE: the `getArray`, `getMap` and `getString` being annotated as `NonNull` in the Java code is a scam - there is no guarantee that native side will send non-null to the Java side, and in practice, indeed, in certain cases it doesn't. So I opted to make it nullable instead - this way it's at least explicit and is not a ticking bomb hidden to explode behind the false sense of security.
Reviewed By: javache
Differential Revision: D57327835
fbshipit-source-id: 1b546b2ff22af2be903fe6ab91f0148b645595fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45872
build_android is currently broken, this should fix it.
Changelog:
[Internal] [Changed] - Unbreak build_android by not depending on PreferenceManager from androidx
Reviewed By: cipolleschi, hezi
Differential Revision: D60652912
fbshipit-source-id: a089609c6643c40c95919fdc882a89406f6ce871
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44587
# Changelog:
[Internal] -
As in the title, moving towards migrating all the interfaces in react.bridge.
Reviewed By: tdn120
Differential Revision: D57433401
fbshipit-source-id: 35581d27d6d093edb1cc59b245e6468758825f68
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## 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] [CHANGED] - Migrated `packages/gradle-plugin/react-native-gradle-plugin/src/test/kotlin/com/facebook/react/tasks/GenerateCodegenArtifactsTaskTest.kt` to assertj.
Pull Request resolved: https://github.com/facebook/react-native/pull/45845
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: hezi
Differential Revision: D60597025
Pulled By: cortinico
fbshipit-source-id: 4228b958c7b9e1506640b9ff217f098e2626ea81
Summary:
This re-applies D60495100 after I've fixed the history for `ReactImageView`.
bypass-github-export-checks
Changelog:
[Internal] [Changed] - Re-apply Use BackgroundStyleApplicator in View setters on ReactImageView.kt
Reviewed By: NickGerleman
Differential Revision: D60578453
fbshipit-source-id: 995f5e54ea6ca3161935e8b7814df390d827a463
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45866
This turns on enableBackgroundStyleApplicator() by default, which will get us more screenshot tests over existing apps, and let us add new screenshot tests for box-shadow against stock RNTester.
This is a breaking change, for the small number of libraries which use CSSBackgroundDrawable/ReactViewBackgroundDrawable off of a view directly, for setting or accessing styles (this was already unreliably), along with libraries which read `mBorderRadius` from views using reflection. This is more or less confined to Reanimated, react-native-navigation, and one internal library.
Users who want to access or mutate background styles should use the public `BackgroundStyleApplicator` instead.
Changelog:
[Android][Breaking] - Set "enableBackgroundStyleApplicator" by default
Reviewed By: joevilches
Differential Revision: D60365677
fbshipit-source-id: aab8588b27c1125920adb257406c53dadb356767
Summary:
In Android, when constructing a multipart body for a file and that file source is a uri (base64-encoded) we do the following:
1. Decode the base64 string into bytes
2. Create a bitmap object
3. Compress the bitmap object as PNG into new bytes
The process does an unnecessary work (bytes -> bitmap -> bytes) and creates unexpected results e.g. a GIF file will be converted into PNG when uploaded. This PR removes the unnecessary steps (2 and 3).
## Changelog:
[ANDROID] [FIXED] - Fix uploading GIF URI
Pull Request resolved: https://github.com/facebook/react-native/pull/45826
Test Plan:
1. Upload a GIF; use URI (base64-encoded)
2. Verify that the uploaded file is a GIF
```js
const formData = new FormData();
formData.append('photo', {
uri: GIFURI,
type: 'image/gif',
name: 'photo.gif',
});
fetch(UPLOAD_URL,
{
body: formData,
method: "POST",
}):
```
| Before | After |
|:------:|:-----:|
| <video src="https://github.com/user-attachments/assets/6ce4769a-8fa5-4d00-8066-9a1911608632" /> | <video src="https://github.com/user-attachments/assets/76a29d14-ce9d-48cd-94d0-7591064a5b1b" /> |
Reviewed By: cortinico
Differential Revision: D60515478
Pulled By: tdn120
fbshipit-source-id: d6ad1c42631c184c3dcdf3a956641e25d0c1b926
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45799
No idea how I missed this but I don't think `defaultProps` is a thing in React Native? So the images were not showing
Changelog: [internal]
Reviewed By: joevilches
Differential Revision: D60392853
fbshipit-source-id: 27280033fb719340a809053d6ca98ac3f178c8c3
Summary:
- Adds `background` prop that supports CSS's linear gradient. Later this can be extended to support various other gradients and possibly CSS's background image (less motivation as better solutions exists for image)
- Extended `CSSBackgroundDrawable` to draw Linear Gradient shader while preserving the border style support.
- Style supports JS object to specify `LinearGradient`, so it can support Animated libraries.
## Changelog:
[ANDROID] [ADDED] - linear gradient
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45433
Test Plan:
- Check out `processBackground-test.js` for supported syntax testcases.
- Checkout examples added in `LinearGradientExample.js`
Although the PR is tested well but open to any changes/feedback on the approach taken.
iOS PR - https://github.com/facebook/react-native/pull/45433. Separated the PRs to keep it easier to review. Both PRs can be reviewed individually.
Reviewed By: joevilches
Differential Revision: D60493360
Pulled By: NickGerleman
fbshipit-source-id: 762929c4fe16d87cbbd9ebe83ecce96a9e13192c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45832
The main one! This allows box-shadow to be used in View, and uses BackgroundStyleApplicator (if flag is enabled) for background management.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60491176
fbshipit-source-id: c068b1dc971253f1303de5bae62e42a9eceb0de6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45835
`ReactViewBackgroundManager` will do this for us (and otherwise doesn't do anything draw related), but this will be removed when BackgroundStyleApplicator is rolled out, and not all callers use `ReactViewBackgroundManager`.
Changelog:
[Android][Fixed]
Reviewed By: philIip
Differential Revision: D60489756
fbshipit-source-id: 37cfc2b90af057bc142ad95b93e32941edb17ca5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45834
These are very rarely called, outside of directly by the view manager, but they are still public, so we should make these work off the same composite drawable as the view managers (eventually BasrViewManager).
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60495100
fbshipit-source-id: 90f51870dd9929d1f3657d8f5368ef46216c8544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45854
Right now these border widths are incorporated into Yoga layout, but view manager never responds to it.
This adds the props supported by <View> to text, still missing many others. The underlying functions are aware of the spacing type,
I plan to fix this more thoroughly, across the different edges, properties, and different components, after we remove the legacy background stack, and all of these can live in a single place on BaseViewManager.
Changelog:
[Android][Fixed] - Add borderStartWidth and borderEndWidth support
Reviewed By: necolas
Differential Revision: D60560343
fbshipit-source-id: 8e1ebaa087e0728b5758850239c41aeae5d619a9
Summary:
Many `AccessibilityInfo` functions (`isReduceMotionEnabled`, `isBoldTextEnabled`, etc.) return promises, but the mocked versions of them in jest/setup.js aren't returning promises.
All of these functions live in [packages/react-native/Libraries/Components/AccessibilityInfo/AccessibilityInfo.js](https://github.com/facebook/react-native/blob/main/packages/react-native/Libraries/Components/AccessibilityInfo/AccessibilityInfo.js), where you can verify their return types are Promises.
When using `react-native/jest-preset` and running tests that utilize one of these functions, you'll get an error:
```
AccessibilityInfo.isReduceMotionEnabled().then() is not a function
```
https://github.com/facebook/react-native/pull/29381 was opened in 2020 but closed after becoming stale. My PR is nearly identical but covers additional Promise-returning functions that have been added to `AccessibilityInfo` since then.
## Changelog:
[GENERAL] [FIXED] - Update the react-native/jest-preset mock of AccessibilityInfo to better match its API
Pull Request resolved: https://github.com/facebook/react-native/pull/45825
Test Plan:
I've tested by making the change locally in my project's `node_modules/react-native/jest/setup.js` file and confirming that I no longer get an error when running this test:
```
it("should pass", async () => {
await AccessibilityInfo.isReduceMotionEnabled().then(enabled => {
expect(enabled).toBe(false);
});
});
```
Before:
```
TypeError: Cannot read properties of undefined (reading 'then')
16 |
17 | it.only("should pass", async () => {
> 18 | await AccessibilityInfo.isReduceMotionEnabled().then(enabled => {
| ^
19 | expect(enabled).toBe(false);
20 | });
21 | });
```
After: No type error, and test passes.
Reviewed By: robhogan
Differential Revision: D60519836
Pulled By: tdn120
fbshipit-source-id: 24fc77b0f9693e131686a0a45b81fbd33ff65f01
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `BundleHermesCTaskTest.kt` to AssertJ testing library
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45806
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: mdvacca
Differential Revision: D60522760
Pulled By: cortinico
fbshipit-source-id: f7847143d182b29e1bbbba738a0ddae9bf3ee59c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45746
Once the spread was past a certain value, it could break some of this logic by creating a null rect or negative size. This just makes it so that in those cases, inset will be a 0x0 clear region rect and outset will be nothing
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60317780
fbshipit-source-id: 021bf41d71ae69809076b4f5e6413d04cd878372
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45681
This diff fixes 2 related issues that arise when we add a border to the view with box shadow
1) The shadow fills the padding box and not the border box. To fix this we just need to subtract the edge insets (border width) from both the shadow size and the clear region size. We also need to change the clipping area to clip anything outside the padding box
2) The corner radius of the clear region is based on the corner insets, so border radius - border width
The first change required a bit of thinking on my part to remember what bits of the crazy arithmetic here needed to change. So I refactored a bit:
* The general theme now is that all of the rects are derived from one another, and make use of CGRectOffset and CGRectInset to make their necessary adjustments.
* We introduce `shadowFrame` which is just the frame of the shadow area - agnostic of things like blur padding and offscreen shenanigans. So its the size of the layer insetted by the border widths.
* From this we can derive our 2 offscreen rects. The `shadowCastingRect` outsets the shadow frame by the blurRadius, while the `clearRegionRect` insets by spread distance. We then use `CGRectOffset` to push it offscreen. We save this offset so we can use it later to get the CG shadow back in place (since this is all originally derived from `shadowFrame`.
* There is now a single place that dictates the size of the shadow (`shadowFrame`), and a single place that dictates the offset to push our rects offscreen. The necessary change to trace padding box and not content box therefore just needs to change `shadowFrame` as opposed to 4 other spots.
* Additionally, when we offset, we do not need to worry about things like spread and blur, since `CGRectInset` takes care of that along with the size
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60201959
fbshipit-source-id: 4ecf0e0db8ce9d54f08e89adec94d50eb19a26a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45679
`cornerRadiiForBoxShadow(cornerRadii, 0)` no-ops since there is no spread, and it returns the same type as it takes as an input, so there is no point for this complexity
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60203620
fbshipit-source-id: c1f86ce6e8fef07365ab57caa3e906f1601a0c2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45678
This doesn't need to be an explicit path, its just tracing out a rect. CG has a method for that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60202842
fbshipit-source-id: 61faa21e57b1341c3b96961f12503eb4a7f3020b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45824
changelog: [internal]
add a bounds check to prevent crash in TouchTargetHelper.
as it turns out, firstReactAncestor may be bigger than the size of pathAccumulator.
Reviewed By: christophpurrer
Differential Revision: D60449741
fbshipit-source-id: 4e981d06877e26d278c4567beebebd82262f60d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45822
Changelog: [internal]
## Context
`react-native/Libraries/Renderer/shims/ReactFabric` is the default module to load the RN renderer and loading it has side-effects (among other things it sets `global.RN$stopSurface`.
We introduced a proxy module (`RendererProxy`) so we could use dependency injection to overwrite the renderer module with a custom implementation (the original goal was to be able to use a renderer version that didn't pull paper and only used Fabric).
Unfortunately, using both the proxy and the module directly in some places leads to race conditions setting `global.RN$stopSurface`, which causes some screens to be rendered with one renderer and unmounted/disposed with a different one (because we accessed `ReactFabric` later and set `RN$stopSurface` from a different renderer implementation). When this happens, the unmount request in the other renderer is a no-op because no surface was renderer in it. This leads to surfaces not being disposed.
## Changes
This modifies the proxy to add additional functions and modifies all other modules in the package to make sure that all the accesses to the renderer go through the proxy.
Reviewed By: sammy-SC
Differential Revision: D60452544
fbshipit-source-id: 1b17a95ed9b1c529718f22983dde1f00f1b2adae
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `GenerateCodegenSchemaTaskTest.kt` to AssertJ testing library
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45807
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: andrewdacenko
Differential Revision: D60509334
Pulled By: cortinico
fbshipit-source-id: 0702958f0c9d03994b0c9a6a1c743f5db84e5703
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `PreparePrefabHeadersTaskTest.kt` to AssertJ testing library
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45808
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: andrewdacenko
Differential Revision: D60509282
Pulled By: cortinico
fbshipit-source-id: 1b7d9f0c24bb0e8e573f685582c532a38e6b3b13
Summary:
Fixes [44566](https://github.com/facebook/react-native/issues/44566)
Issue was onChangeText was called 5-6 times if maxLength was set in a multiline component and TextInput Value was changed via state update.
`if (_maxLength) {
NSInteger allowedLength = MAX(
_maxLength.integerValue - (NSInteger)backedTextInputView.attributedText.string.length + (NSInteger)range.length,
0);
if (text.length > allowedLength) {
// If we typed/pasted more than one character, limit the text inputted.
if (text.length > 1) {
if (allowedLength > 0) {
// make sure unicode characters that are longer than 16 bits (such as emojis) are not cut off
NSRange cutOffCharacterRange = [text rangeOfComposedCharacterSequenceAtIndex:allowedLength - 1];
if (cutOffCharacterRange.location + cutOffCharacterRange.length > allowedLength) {
// the character at the length limit takes more than 16bits, truncation should end at the character before
allowedLength = cutOffCharacterRange.location;
}
}
// Truncate the input string so the result is exactly maxLength
NSString *limitedString = [text substringToIndex:allowedLength];
NSMutableAttributedString *newAttributedText = [backedTextInputView.attributedText mutableCopy];
// Apply text attributes if original input view doesn't have text.
if (backedTextInputView.attributedText.length == 0) {
newAttributedText = [[NSMutableAttributedString alloc]
initWithString:[self.textAttributes applyTextAttributesToText:limitedString]
attributes:self.textAttributes.effectiveTextAttributes];
} else {
[newAttributedText replaceCharactersInRange:range withString:limitedString];
}
backedTextInputView.attributedText = newAttributedText;
_predictedText = newAttributedText.string;
// Collapse selection at end of insert to match normal paste behavior.
UITextPosition *insertEnd = [backedTextInputView positionFromPosition:backedTextInputView.beginningOfDocument
offset:(range.location + allowedLength)];
[backedTextInputView setSelectedTextRange:[backedTextInputView textRangeFromPosition:insertEnd
toPosition:insertEnd]
notifyDelegate:YES];
[self textInputDidChange];
}
return nil; // Rejecting the change.
}}`
This is the original code snippet.
It was happening because of wrong check of maxLength with text length `if (text.length > allowedLength)` this should be
`(text.length > _maxLength.integerValue)` and `if (allowedLength <= 0)` we should not change the string and fire `textInputDidChange`
## Changelog:
[IOS] [FIXED] : Fixing maxLength check which was firing onChange multiple times
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45401
Test Plan:
Tested in Ios
Ran yarn test
<img width="1661" alt="Screenshot 2024-07-12 at 1 00 28 PM" src="https://github.com/user-attachments/assets/fbad94a8-9989-4252-ad7d-e507d4eafd9e">
Reviewed By: sammy-SC
Differential Revision: D59911745
Pulled By: cipolleschi
fbshipit-source-id: 67410ec50d6a2415e568e1685699bfed02fd0a27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45838
Some Internal tests in the old architecture were failing after landing [#45414](https://github.com/facebook/react-native/pull/45414) because the `RCTNativeAnimatedModule` in the old architecture was not declaring the event.
This change fixes it by declaring the event that is never fired in the Old Architecture as it is not needed.
## Changelog
[iOS][Added] - Declare the `onUserDrivenAnimationEnded` in the old Architecture
Reviewed By: sammy-SC
Differential Revision: D60507812
fbshipit-source-id: eb12563c6551204bcf98f3a2001e1efcf84ef05e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45803
This makes the same rough changes as I made to images, to apply background styles in view manager layer, using BackgroundStyleApplicator, including new boxShadow style property.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D60409795
fbshipit-source-id: 304cb99855de72fe36af33cdda4a150e21b629b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45797
Android borders are drawn using a path generated by `addRoundRect()` inset by half the border width, using the full border width as stoke width. The edges of the ellipsis drawn for rounded borders do not line up with the math used to trace the bounding border-box path.
In a relatively similar hack to elsewhere in border drawing code for gap between content and the border, we inset the clipOut path, as if its bounding rectangle were about half a subpixel smaller, to mininally overlap the border on these edges. We then place the outer box shadows under the border in z-ordering, so that the minimal extra insetting is only visible with transparent backgrounds.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60389685
fbshipit-source-id: 8c449cc3eee1a3e4100f06fd87f27ae341e02eac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45781
This adds some RNTester examples for `boxShadow`, that render correctly when `ReactNativeFeatureFlags.enableBackgroundStyleApplicator()` is set!
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60367850
fbshipit-source-id: 3c9ae2bf906ae923c713b5f36cd2000f612fe3dc
Summary:
Backout of the [commit](https://github.com/facebook/react-native/commit/afa887b6225352d35ed99eb5271bef8a3fe1c7d6) to react to the new event as it is breaking internal tests.
## Changelog:
[General][Changed] - Revert React to onUserDrivenAnimationEnded event in JS
Reviewed By: mdvacca, arushikesarwani94
Differential Revision: D60467143
fbshipit-source-id: c70bb057adf49b5f26df4201f8b987bf6b876f46
Summary:
Backout of this [commit]() as the previous one was making some E2E fail and need to investigate further.
## Changelog:
[Internal] - Add back `_shouldEmitEvent` guardrails
Reviewed By: mdvacca, arushikesarwani94
Differential Revision: D60467145
fbshipit-source-id: a703022aa74ca0ed0fed05b59da68918eb2001e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45795
Changelog: [internal]
Our modules to set up the runtime have side-effects and depend on import order to work correctly. This is error-prone and complicates the migration to ESM in some cases, so this refactors all of them in `src/private/setup` to export a function instead.
Reviewed By: rshest
Differential Revision: D60382506
fbshipit-source-id: 9ac30b29659b74605d59eb97562d6cbf01f48e47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45793
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60381603
fbshipit-source-id: bba62b56c42817b15bb28bce22d6c2cf668dc797
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45791
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60377869
fbshipit-source-id: 02bc0335385859c0589a494de9b59b0c2ebc06f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45792
Changelog: [internal]
These files are safe to move because they haven't been enabled in OSS and people shouldn't be importing them directly.
Reviewed By: rshest
Differential Revision: D60377868
fbshipit-source-id: db0ec2839af91620fe8b6d3927ad0b809d1bdf23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45784
Changelog: [internal]
I originally created `src/private/core` as a directory to contain set up files for RN, but the name wasn't implying that and ended up holding more stuff.
This moves everything out of that directory and renames it as `src/private/setup` so it has a clearer scope.
Reviewed By: NickGerleman
Differential Revision: D60290620
fbshipit-source-id: b5dc27fbaa64df9a8a09a84f02023896f6fd2884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45414
This change completes the fix for broken pressable when animations were applied to components with native driven animations.
When creating the AnimatedProps, if they are natively drive animation, we look for the AnimatedValue involved and we register a listener. This is needed to make sure that the NativeModule will send te updated value upon calling the `update` function.
Then, when observing the props lifecycle, it register a listener to the new `OnUserAnimationEnded` event, fired by the NativeAnimation module.
When the `OnUserAnimationEnded` event is fired, the AnimatedProps will update the props that depends on the user driven animation.
## Changelog
[General][Fixed] - reallign the shadow tree and the native tree when the user finishes interacting with the app.
Reviewed By: sammy-SC
Differential Revision: D59681428
fbshipit-source-id: c6690c41ea6d5517b7f8413e9dba1e12861a2400
Summary:
Adds changelog for the 0.74.4 patch.
bypass-github-export-checks
## 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] [Changed] - Add 0.74.4 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45818
Reviewed By: cortinico
Differential Revision: D60448807
Pulled By: cipolleschi
fbshipit-source-id: 9737523dccf767091a6f1c1e076f8a192d0e5136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45693
This wires box shadow application for `ReactImageViewManager` to `BackgroundStyleApplicator` for setting shadows. This same logic will get copy-pasted to other view managers later up the stack (including Vito images, ScrollViews, etc, then eventually View), until we are able to consolidate to BaseViewManager.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60266016
fbshipit-source-id: eaa842f539ee1654ab719c7d341b4b748db7a15c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45780
D59300215 noticed that the drawable was leaking a clipping rect for the rest of the operations, and added a `save/restore` pair, but the save happens conditionally, so we can restore more often than we save, if we hit a fast path of not needing to invalidate the shadow RenderNode when drawing. This leads to the following unhandled exception:
```
java.lang.IllegalStateException: Underflow in restore - more restores than saves
at android.graphics.Canvas.restore(Canvas.java:647)
at com.facebook.react.uimanager.drawable.OutsetBoxShadowDrawable.draw(OutsetBoxShadowDrawable.kt:110)
at android.graphics.drawable.LayerDrawable.draw(LayerDrawable.java:1019)
```
This change moves saving canvas context to before setting state and drawing onto the canvas, instead of the area manipulating the RenderNode.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60375357
fbshipit-source-id: 773c733fce11ce89ab6741589eea19b6f060f9a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45692
This moves to using `BackgroundStyleApplicator` instead of `ReactViewBackgroundManager`, or Fresco based drawing, for setting background/border style props when the feature gates are right.
This will be ported to Vito (and... all the other built-in views) later up the stack.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60265326
fbshipit-source-id: d9dea8d35eeb09a10d012c3ab93957dbf2ebfdd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45689
Going to use this to gate usage of the applicator, for each of the components, including `<View>`, which
This also conveniently sidesteps some unsavory reflection on View member happening that we can't clean up yet.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60265327
fbshipit-source-id: fabac3ac8479ff359ae6d798407047287dc712f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45688
Box shadows are handled as part of different drawables. We have other cases where we want to show multiple drawables at once, such as for ripple feedback, or more commonly, for app-wide TextInput styles (which adds padding).
With more multi-background scenarios in the future, and CSSBackgroundDrawable already way overloaded, the arch here I want to go towards is less drawables, as hidden implementation details, with single responsibilities, more often switched out. Once path logic is extracted, this would also allow for better fast-paths, like not needing to create a (heavy) CSSBackgroundDrawable, for simple views with a color background.
`CompositeBackgroundDrawable` is then a more structured LayerDrawable, which also lets us mutate or retrieve information from specific layers, and enforces the different types of layers are correctly z-ordered.
`BackgroundStyleApplicator` is the public API for manipulating these styles, inspired by the existing `ReactViewBackgroundManager`. There are some important design differences.
1. The only per-view state is the publicly accessible background drawable. This means the applicator can be used on arbitrary views, and eventually used in BaseViewManager for all views (once all the QEs settle)
2. We have reliable accessors for every setter, which seem to be what folks use externally for animation
3. We work consistently in CSS device independent pixels (for the most part...)
4. More structure/safety in how we refer to edges vs uniform
5. Overflow state is not kept on the applicator, so views can set/keep their own defaults
Overflow clipping must still be implemented per-view, during drawing unfortunately.
Changelog:
[Android][Added] - Add BackgroundStyleApplicator for managing view backgrounds
Reviewed By: joevilches
Differential Revision: D60252279
fbshipit-source-id: 4c6da3e128d4da94f35d50c30c7c412cb513cc12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45734
Rather than enumerating all platforms the iOS podspec should not compile this inverts the source_files field to an allowlist for only files relevant to iOS.
## Changelog
[Internal]
Reviewed By: cipolleschi
Differential Revision: D60291091
fbshipit-source-id: a0f7e3181ec527e39602c4523622f836a04183d9
Summary:
With the React revert from 19 to 18.3.1 of 0.75 the template is not compatible with main anymore.
As a quick solution, we are disabling the e2e tests running on main.
## Changelog
[Internal] - disable E2E template tests
Reviewed By: cortinico
Differential Revision: D60387687
fbshipit-source-id: 74d4133477bcfdc8ba5909b46d9180ac372ec6bb
Summary:
Issue: https://github.com/facebook/react-native/issues/45596
## Changelog:
[INTERNAL] [CHANGED] - Migrate `GeneratePackageListTaskTest.kt` to AssertJ testing library
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45790
Test Plan: Run `./gradlew -p packages/gradle-plugin test`
Reviewed By: sammy-SC
Differential Revision: D60382287
Pulled By: cortinico
fbshipit-source-id: 338c771db9d407f0d83e1c62a8c13ac26d898926
Summary:
The Maestro team just released a new version of maestro which dies in our CI
This change pins the version to something we know it's working, so we can decide when to move to the next version
## Changelog
[Internal] - Pin Maestro version
Reviewed By: cortinico
Differential Revision: D60380466
fbshipit-source-id: af842b7922736cc08300ac3bceef2d6110bcd913
Summary:
`getGradleDependenciesToApply` tries to call `implementation:` in all libraries, including the ones that are not supported on Android.
## Changelog:
[INTERNAL] [FIXED] - Filter out platform-specific libraries from the auto-linking gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/45749
Test Plan: CI should be green
Reviewed By: cipolleschi
Differential Revision: D60374769
Pulled By: cortinico
fbshipit-source-id: 33c83e9cc39d81b0e5c497570a936831ebb345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45708
# Changelog: [Internal]
This was originally highlighted by linter in D59975264, but I forgot to fix it.
Reviewed By: robhogan
Differential Revision: D60282937
fbshipit-source-id: 2869634f2d2111a5e2a81871b38b15a122b3ed8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45528
Right now these exist in static view config (iOS BaseViewConfig), but not native view config, so the props don't work without bridgeless/SVCs, and we would get warnings if doing viewconfig validation.
This change adds the props to native view configs as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59940432
fbshipit-source-id: 89d57d4e58de2a55b749c68274ef0d2271f69100
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45630
removeOutstandingSurfacesOnDestruction is safe to fully release, we are deleting the flag
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D60142272
fbshipit-source-id: 5e7470d52cfc964b72f0cec7224a234ce9e6c2c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45422
When `ReactNativeFeatureFlags.setAndroidLayoutDirection()` is set, we assume in components like ReactHorizontalScrolView that the Yoga contextual layout direction has been set on the underlying component, and skip using I18nManager global direction.
These native views are also used in Paper, so we need to make the change there as well to avoid regressions.
This change mechanically ports the change from Fabric to Paper, at the same layer as used in Fabric (applying ShadowNode layout to the Android view tree).
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D59708408
fbshipit-source-id: 52d6fa80c102250eae7ccccedd7184569f6a727f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45753
Let's turn this off, for clients where the feature flag isn't wired to a config, until the issue with `removeClippedSubviews` is resolved.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60273063
fbshipit-source-id: 6302a7e1f204459ec7f5cbdb26a521e07e023458
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45690
ViewManager layer often uses `YogaConstants.UNDEFINED` (`NaN`) as null-state value. Teaching PixelUtil how to handle `NaN` values makes glue code around easier. I think this technically isn't needed, since the resultant operations would become `NaN`, but it seems like poor form/hard to reason about to propagate NaN into arithmetic or library functions.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60265329
fbshipit-source-id: b2f4abaefb30ebd58c2644d072bb7e5bc4b3ee7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45691
1. Add some accessors, so we can keep accessors and setters symetric
2. Use the shared BorderStyle enum added in last diff
3. Fix some missing invalidation on setting style
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252276
fbshipit-source-id: 3dde6ad5926f109cefc7247da4ba1894694b1867
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45687
This adds some more enums and data classes to encapsulate style values we are working with for border/background rendering. Right now, a lot of these are passed around as strings, or raw ints (of differing ordinals). These will be used as the public API of `BackgroundStyleApplicator` up the stack.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D60252277
fbshipit-source-id: 0f8001869421ffffae9727c7904bf5e395505c08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45685
We built these to be able to parse web style string values, but the types only allow object form, and the TypeScript type is wrong.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D60263730
fbshipit-source-id: 7a6e93924a92e8e62346645cb4f8ab1a37dca34f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45722
Splitting the ReactImageView convertion to another file, to see if this is causing further failures.
Changelog:
[Internal] [Changed] - Convert ReactImageManager to Kotlin
Reviewed By: rshest
Differential Revision: D60285050
fbshipit-source-id: 68415782a40c1eacf4e67fbdd2d70c962c0600c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45711
Migrating this package in one go is proving harder than expected.
Let's split this through in smaller parts: I'm first marking the package as nullsafe.
Changelog:
[Internal] [Changed] - Make `com.facebook.react.views.image` nullsafe
Reviewed By: cipolleschi
Differential Revision: D60282604
fbshipit-source-id: 68879142a88bdc3c837dff91e53c5f5e891773f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45683
Changelog: [Internal]
this did not make any meaningful progress, let's clean it up and revisit it later.
Reviewed By: fkgozali
Differential Revision: D60219828
fbshipit-source-id: 89a283d7c572dfcd6ef16472e81f3dce1c2cd284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45706
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
To avoid flakyness and costs, let's run E2E tests only on main and on stable branches
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60283204
fbshipit-source-id: 806cb8905cb269f18785158dcc5777ef10e0ef44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45710
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new Android app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico
Differential Revision: D60282836
fbshipit-source-id: 0c3b4c1bbacfd6c8695f987c86b7e615a3cef026
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45703
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add job to create a new iOS app from the template and run maestro test on it
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282811
fbshipit-source-id: 2a1dcb1de09795bd0323357455e98a7fa379a2e7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45713
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add Maestro flow for a new app created from the template
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282783
fbshipit-source-id: 0aa7f3fae4f5bf31518e02ddc56ca2d4fac4dfa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45709
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Connect RNTester Android to Maestro action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282769
fbshipit-source-id: 2a20f1cb249fc5c43b0579c3309efd60369a1da6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45707
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a github action to run Maestro on Android
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: cortinico, blakef
Differential Revision: D60282719
fbshipit-source-id: 9544eea192894696361fada1e519caad35f74154
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45705
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Wire RNTester to the Maestro Action
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282689
fbshipit-source-id: 51c624c2acf7a27ed5527e7453d9a04678df6c66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45704
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Create a reusable GHA to run Maestro tests on iOS
Changelog:
[Internal] - Exploration to integrate maestro
Reviewed By: blakef
Differential Revision: D60282657
fbshipit-source-id: 3a2a427f0954b46fc6c3a8bf753e807371eb0239
Summary:
## Context
Running manual tests when preparing a release, it's time consuming.
We have to do the cherry picks, wait for CI to finish, and then manually test 8 configurations.
Maestro is a tool that allow us to run E2E tests automatically, and we can wire it to CI.
## Change
Add a test flow for RNTester
## Changelog:
[Internal] - Exploration to integrate maestro
Pull Request resolved: https://github.com/facebook/react-native/pull/45574
Test Plan: GHA
Reviewed By: blakef
Differential Revision: D60282147
Pulled By: cipolleschi
fbshipit-source-id: 4ecba84f0b2c7186de2bb9938043e73a0bd9a6bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45735
This merges several 2 external libraries from .so to be included inside
libappmodules.so.
Changelog:
[Internal] [Changed] - Move react_codegen_* libraries for RNTester to OBJECT
Reviewed By: rozele, rshest
Differential Revision: D60290806
fbshipit-source-id: 6bfa40995d7538e075819d916e8a204464edb75b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45727
All instances mirror types which are already defined in the platform-independent base module. See snapshot changes.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D60286148
fbshipit-source-id: 30665252ff5e449a2c10ff3a3e76d9337daecb80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45640
Other two libraries that don't need to be dynamic libraries but can just be exposed via libreactnative.so
Changelog:
[Internal] [Changed] - Move react_featureflags and react_render_consistency inside libreactnative.so
Reviewed By: cipolleschi
Differential Revision: D55796945
fbshipit-source-id: be40b1523a560b2783fc7b6312326e20dc8cf595
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43909
As we're moving towards a single `libreactnative.so` file, we need to remove several of our prefab targets. Here I'm cleaning up those that are not having an OnLoad.cpp file which needs to be loaded from SoLoader.
This is breaking for libraries using native dependencies via Prefab (i.e. search for `ReactAndroid::` in CMakeLists.txt files for your project).
If so, the CMakeLists.txt files should be updated as follows:
```diff
- ReactAndroid::react_render_debug
+ ReactAndroid::reactnative
```
This applies to every prefab dependencies (the example is just for `react_render_debug`
Changelog:
[General] [Breaking] - Remove several libs from default App CMake setup
Reviewed By: cipolleschi
Differential Revision: D55751683
fbshipit-source-id: 3aca7897852b5f323d60ede3c5036cae2f81e6c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43908
This creates a new dynamic library that we want to be the only .so that is loaded from apps/libraries.
Changelog:
[Internal] [Changed] - Create the libreactnative.so dependency
Reviewed By: cipolleschi
Differential Revision: D55751682
fbshipit-source-id: 50f4167dc2f9953a8673b28dba3357e19fe88d6b
Summary:
https://github.com/facebook/react-native/issues/45596
Migrated all the assertions to use `assertThat()` function from AssertJ.
Also updated the `prepareBoostTask_withMissingConfiguration_fails` test to use `assertThatThrownBy` to check if the tested task throws a given exception.
## Changelog:
Migrate tests to assertj in these files:
- `packages/gradle-plugin/react-native-gradle-plugin/src/test/kotlin/com/facebook/react/tasks/internal/PrepareBoostTaskTest.kt`
[INTERNAL] [CHANGED] - Migrated PrepareBoostTaskTest from junit.Assert to assertj.core.api.Assertions.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/45718
Test Plan:
All tests pass when `./gradlew -p packages/gradle-plugin test` command is ran.
<img width="454" alt="image" src="https://github.com/user-attachments/assets/9e954f7b-2208-48a9-ae15-ab642252e6da">
Reviewed By: GijsWeterings
Differential Revision: D60284566
Pulled By: cortinico
fbshipit-source-id: 11af0a0ca574f935e6aab3a7855b5daaeab1a718
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45701
# Changelog: [Internal]
One weird thing is that this test actually never runs for Android, so its only compiled. I am not sure why exactly this one produces an error during execution, given that the next test is almost identical.
Nothing valuable from logcat, just a `SIGSEGV`. Since its something with memory, I've tried calling `unsubscribe`, same as in the next test to free memory before the test tear down (which should not run, because this test doesn't run).
Reviewed By: dmytrorykun
Differential Revision: D60282464
fbshipit-source-id: 2c7760f02c1128083f28651fe8ecd0f3cee27715
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45578
# Changelog: [Internal]
Use previously introduced native module for managing the presence of warning notifications in LogBox:
- Don't display warnings and Fusebox migration message if there is an active debugging session
- If the session has just been started, clear warnings to hide Fusebox migration message
- If there is no active debugging session (even if there were some at some point of Host lifetime), display Fusebox migration message
See demo in test plan.
Reviewed By: huntie
Differential Revision: D59975265
fbshipit-source-id: 87d91b4d7f3c825dc795ec1b5b3073f969bc7b60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45577
# Changelog: [Internal]
This diff adds new native module, which can be used from JavaScript.
The API includes:
1. `hasActiveSession`: returns a boolean flag, which can be used for determining if 1 or more debugging sessions are active for current HostTarget.
2. `subscribe`: receives a callback, which will be executed once the debugging state changes. To be more precise, this will only be called when state is changing from no active sessions to 1 session or the other way around. Callback should expect to receive one boolean argument, which can be used for determining if there is an active session.
Reviewed By: huntie
Differential Revision: D59975264
fbshipit-source-id: dd095954529f573f38e9fae1792465a59e639d23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45670
**Motivation**
There is a special [code path](https://github.com/facebook/react-native/blob/bb23026daf1a853f4482be46d6f242712a6b7330/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/animated/FrameBasedAnimationDriver.java#L98) for native driven looping animations that restarts the animation in native, never calling the "animation end" callback. This was designed for and works fine with the `Animated.loop(Animated.timing(...))` animations. Unfortunately, it doesn't work well with more complex animations.
Consider an `Animated.loop(Animated.sequence(Animated.timing(...)))` animation. It doesn't trigger this code path. Instead, its nested `Animated.timing` animations are continuously rescheduled from JS by the looping `Animated.sequence` as singular native driven animations. Each time they end, they fire their "animation end" callback.
This introduces a subtle breakage when those "animation end" callbacks trigger React to update its state. This in turn restarts the rendering. In case with long transitions such looping animations can restart the rendering multiple times. In worst cases it may render the app unresponsive.
**Solution**
We don't need to tell React to update its state when running looping animations. This diff introduces a mechanism, using which `Animated.loop` can tell its nested animations that they are in a loop, and and there's no need to send state updates when they finish. This is consistent with how `Animated.loop(Animated.timing(...))` behaves.
Changelog: [General][Breaking] - Looping animations will not send React state updates.
Facebook
This diff enables this new behaviour for IGVR and FBVR, it also set up the experiment for FBiOS and FB4a.
Reviewed By: javache
Differential Revision: D59970265
fbshipit-source-id: 4832ae05b82f6cc59f92f72305b68610fa422f0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45638
When looping a frame-based animation, we want to make sure to use the latest frame from the easing curve, which may not necessarily match `mToValue`.
Changelog: [Internal]
Differential Revision: D60143746
fbshipit-source-id: 68fa5421a958acc8291f396bc9f263fa110fdc54
Summary:
As explained in https://github.com/facebook/react-native/issues/45280, `TSan` picks up data races related to concurrent read/write to fields in `RCTCxxBridge`. See this report for reference:
```
WARNING: ThreadSanitizer: data race (pid=19983)
Write of size 1 at 0x00010af1dfd8 by thread T13:
#0 -[RCTCxxBridge _flushPendingCalls] <null> (RNTesterUnitTests:arm64+0x42b484)
https://github.com/facebook/react-native/issues/1 __53-[RCTCxxBridge executeSourceCode:withSourceURL:sync:]_block_invoke <null> (RNTesterUnitTests:arm64+0x426050)
https://github.com/facebook/react-native/issues/2 decltype(std::declval<void () block_pointer __strong&>()()) std::__1::__invoke[abi:ue170006]<void () block_pointer __strong&>(&&, decltype(std::declval<void () block_pointer __strong&>()())&&...) <null> (RNTesterUnitTests:arm64+0x456298)
https://github.com/facebook/react-native/issues/3 std::__1::__function::__func<void () block_pointer __strong, std::__1::allocator<std::__1::allocator>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x455c6c)
https://github.com/facebook/react-native/issues/4 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/5 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/6 facebook::react::tryAndReturnError(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x4af18c)
https://github.com/facebook/react-native/issues/7 facebook::react::RCTMessageThread::tryFunc(std::__1::function<void ()> const&) <null> (RNTesterUnitTests:arm64+0x51595c)
https://github.com/facebook/react-native/issues/8 facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1::operator()() const <null> (RNTesterUnitTests:arm64+0x529df0)
https://github.com/facebook/react-native/issues/9 decltype(std::declval<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>()()) std::__1::__invoke[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529b54)
https://github.com/facebook/react-native/issues/10 void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ue170006]<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&>(facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1&) <null> (RNTesterUnitTests:arm64+0x529978)
https://github.com/facebook/react-native/issues/11 std::__1::__function::__alloc_func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()[abi:ue170006]() <null> (RNTesterUnitTests:arm64+0x5298dc)
https://github.com/facebook/react-native/issues/12 std::__1::__function::__func<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1, std::__1::allocator<facebook::react::RCTMessageThread::runOnQueue(std::__1::function<void ()>&&)::$_1>, void ()>::operator()() <null> (RNTesterUnitTests:arm64+0x524518)
https://github.com/facebook/react-native/issues/13 std::__1::__function::__value_func<void ()>::operator()[abi:ue170006]() const <null> (RNTesterUnitTests:arm64+0x3ce2e4)
https://github.com/facebook/react-native/issues/14 std::__1::function<void ()>::operator()() const <null> (RNTesterUnitTests:arm64+0x3cdfd0)
https://github.com/facebook/react-native/issues/15 invocation function for block in facebook::react::RCTMessageThread::runAsync(std::__1::function<void ()>) <null> (RNTesterUnitTests:arm64+0x515384)
https://github.com/facebook/react-native/issues/16 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ <null> (CoreFoundation:arm64+0x8dc0c)
https://github.com/facebook/react-native/issues/17 __NSThread__start__ <null> (Foundation:arm64+0x645c60)
Previous read of size 1 at 0x00010af1dfd8 by main thread:
#0 -[RCTCxxBridge isLoading] <null> (RNTesterUnitTests:arm64+0x43236c)
https://github.com/facebook/react-native/issues/1 -[RCTBridge isLoading] <null> (RNTesterUnitTests:arm64+0x3c0170)
https://github.com/facebook/react-native/issues/2 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6f34)
https://github.com/facebook/react-native/issues/3 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
Location is heap block of size 384 at 0x00010af1de80 allocated by main thread:
#0 calloc <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x4fc30)
https://github.com/facebook/react-native/issues/1 _malloc_type_calloc_outlined <null> (libsystem_malloc.dylib:arm64+0xf488)
https://github.com/facebook/react-native/issues/2 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/4 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6b3c)
https://github.com/facebook/react-native/issues/5 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
Thread T13 (tid=11290378, running) created by main thread at:
#0 pthread_create <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2bee4)
https://github.com/facebook/react-native/issues/1 -[NSThread startAndReturnError:] <null> (Foundation:arm64+0x6458f0)
https://github.com/facebook/react-native/issues/2 -[RCTBridge setUp] <null> (RNTesterUnitTests:arm64+0x3bf748)
https://github.com/facebook/react-native/issues/3 -[RCTBridge initWithDelegate:bundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc540)
https://github.com/facebook/react-native/issues/4 -[RCTBridge initWithBundleURL:moduleProvider:launchOptions:] <null> (RNTesterUnitTests:arm64+0x3bc124)
https://github.com/facebook/react-native/issues/5 -[RCTComponentPropsTests setUp] <null> (RNTesterUnitTests:arm64+0xe6b3c)
https://github.com/facebook/react-native/issues/6 __70-[XCTestCase _shouldContinueAfterPerformingSetUpSequenceWithSelector:]_block_invoke.134 <null> (XCTestCore:arm64+0x540d8)
```
In order to fix the data races, `std::atomic` instead of primitive boolean types.
In order to reproduce my findings and verify fix:
* Clone this branch
* Run setup code as described in README
* Execute `git revert -n 11c09fdc7c442dd694909bebbbc8f21c3e69edf2`.
* Enable TSan for both RNTester and its test scheme.
* Enable Runtime issue breakpoint for TSan
* Run unit tests
* Observe the TSan breakpoint is hit (possibly other places in the codebase as well) when accessing `_loading`, `_moduleRegistryCreated`, and `_valid`.. Continue execution if other breakpoints are hit before this breakpoint.
* Execute git revert --abort
* Run the tests again and observe the TSan breakpoint does not hit said code again.
NB! While this will fix data races, it will not fix potential race conditions. I have not encountered bugs related to race conditions in `RCTCxxBridge`, but given the nature of how it is made use of concurrently, it is, in my opinion, plausible.
## Changelog:
[iOS][Fixed] Use std::atomic for eliminating races in RCTCxxBridge.
Pull Request resolved: https://github.com/facebook/react-native/pull/45558
Test Plan: I believe there are existing Unit tests in place for verifying this fix.
Reviewed By: cipolleschi
Differential Revision: D60233758
Pulled By: dmytrorykun
fbshipit-source-id: 8aa124a0521ad43a5e17b42e0ce6d22ae6b4e667
Summary:
This adds `ccache` on the Android build to speedup the building process.
## Changelog:
[INTERNAL] - Adding ccache for Android builds
Pull Request resolved: https://github.com/facebook/react-native/pull/45662
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D60229625
Pulled By: cortinico
fbshipit-source-id: bc7e416f4ed1b4932159feb672947669bfb498d7
Summary:
A previous commit (https://github.com/facebook/react-native/pull/45616) broke the ci in OSS.
It looks like that JSI is not working well in objective-c++ files when frameworks is enabled.
We need to look into it further but we need to have green CI
## Changelog:
[Internal] - Unblock CI
Reviewed By: blakef
Differential Revision: D60232011
fbshipit-source-id: b02ae163258786ce43cc11bc94420682661a6dd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45634
This allows the Android runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
transform.xyz=somevalue to Metro.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D60155757
fbshipit-source-id: 006d5ff2e3f14634fb39d44b390f30da479b1faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45621
This allows the iOS runtime to pass additional options to Metro. Each app can
decide what to send based on the needs. The use case is to send
`transform.xyz=somevalue` to Metro.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D60143663
fbshipit-source-id: 3e35a01a0ee121096d3a5cf0547e8e0ebf77f8ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45624
Must have forgot to add this functionality in, since it was just using a Rect for the clear region. This uses the proper rounded path.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60147035
fbshipit-source-id: 3eebb2c4a56e4dfc957213e54f3d2de2c966082b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45622
The rest of these props setters opts to use `needsInvalidateLayer`, not `_needsInvalidateLayer` the latter of which is a instance variable. This change no effect since we set `_needsInvalidateLayer` to the or of both below, but we should be consistent with the rest of the logic here.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60144215
fbshipit-source-id: b4b863d964a688c1cb9f6fada626d390681d1542
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45620
This does not really depend on anything in the layer. It is just a prop on the layer itself, so we can just set it in place. This pattern already happens for things like transform: https://fburl.com/code/0bhsdlcy
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60142154
fbshipit-source-id: 52ee0e1e6eacf3bba005a727a5a4325a5cc6d338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45613
We had a bug where box shadows were not getting cleaned up. The fix here is easy - just call `[_boxShadowLayer removeFromSuperView]`. Previously we were just setting this layer to nil, which does not do the job.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D60137528
fbshipit-source-id: 310df944f63ffc73ee5fe938cfb5a48674f997ab
Summary:
## Context
During TW Bloks testing, I frequently encounter the issue of a page not loading. After investigating further, I discovered that for one XOCReactNativeHost, there are multiple instances of ReactInstanceManager created. One of them is properly initialized with XOCLoginActivity, while the other one is not initialized and its activity is null.
When calling ReactContext onHostResume, there is a small chance that the ReactInstanceManager with a null activity will be used, resulting in a "no activity" issue.
After analyzing the construction call stack of ReactInstanceManager, it appears that there is a race condition in the function of ReactNativeHost.getReactInstanceManager https://fburl.com/code/kh6o84m9.
I noticed that two threads are calling this function simultaneously, which can lead to the creation of two instances despite the `mReactInstanceManager == null check`, as it is not within a synchronized statement.
An example of one ReactNativeHost with multiple ReactInstanceManagers can be found at https://fburl.com/code/kh6o84m9.
{F1768111631}
The following are the call stack to create the ReactInstanceManagers, the line number may have slightly shift from the prod code because of debugging info.
P1490866855
P1490869412
## About this diff
Added synchronized lock to the checking of `mReactInstanceManager == null` and make mReactInstanceManager as volatile to avoid creating duplicated instance.
## Changelog:
[Android] [Fixed] - Made several methods in ReactNativeHost.java thread-safe to avoid race conditions
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D60088120
fbshipit-source-id: a4c1970bb54c7395dbfc3282d02bd66d9dc95df9
Summary:
This just fixes a warning in scripts/releases-ci/__tests__/publish-updated-packages-test.js that the CI is firing on every PR
## Changelog:
[INTERNAL] - Fix warning on scripts/releases-ci/__tests__/publish-updated-packages-test.js
Pull Request resolved: https://github.com/facebook/react-native/pull/45643
Test Plan: CI
Reviewed By: blakef
Differential Revision: D60170227
Pulled By: cortinico
fbshipit-source-id: 5889f7dd530cc00651d683001e1f2624bd79c27e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45616
We want to eventually route all js error handling through JsErrorHandler in bridgeless.
This will help with that.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D60138415
fbshipit-source-id: de62edfe75066ba135225e24543628306aa5f4a0
Summary:
When trying to use the legacy view interop with `stripe/stripe-react-native` there is an issue with the `CardField` component because it tries to access module registry inside the `view` method (https://github.com/stripe/stripe-react-native/blob/master/ios/CardFieldManager.swift#L7).
The problem is that we attach the legacy view apis after creating view, so they are not available in that method.
To fix this we can change the order of the methods and attach the apis first. Note that we also need to use the `manager` method instead of `bridgelessViewManager` since `bridgelessViewManager` is not initialized otherwise, it is initialized lazily in the `manager` method.
## Changelog:
[IOS] [FIXED] - Fix legacy view interop apis not available in view method
Pull Request resolved: https://github.com/facebook/react-native/pull/45609
Test Plan: Tested in an app that legacy interop apis (`moduleRegistry`) is available in the `view` method in an app using RN 0.74 with bridgeless mode enabled.
Reviewed By: cipolleschi
Differential Revision: D60165191
Pulled By: dmytrorykun
fbshipit-source-id: 60187556fb36d342bb1ef084a093132bdb0496bd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45593
I'm guessing either there is a race condition between Github removing cache entries when we're over budget OR there is an eventual consistency issue between reported cache entries and their removal. Either way, this job is best efforts. If a entry targetted for removal isn't there, great.
This change prevents the job from stopping if an entry no longer exists.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D60106847
fbshipit-source-id: 252bba7bb0bbb91d279f06a39301491332cd5ace
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45585
Changelog: [internal]
Just migrates the flag to the new system.
Reviewed By: sammy-SC
Differential Revision: D60050005
fbshipit-source-id: 4da39446ecdb6cd86ccf7ee75a0d489764c37be6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45598
I've noticed we attempt to load JSC from the Sonatype Snapshot repository.
That is inefficient as we already know that JSC is available only inside node modules.
This change makes the repository resolution stricter by better specifying which
repo can download which dependency.
Changelog:
[Internal] [Changed] - Do not attempt to load JSC from other repositories
Reviewed By: cipolleschi
Differential Revision: D60116002
fbshipit-source-id: 21a2213708f5b0103860a59f3342f1bc0f59cdb9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45589
I don't know why, but we had some CCI leftovers in the repo.
This cleans them up!
## Changelog:
[Internal] - Remove CCI leftovers
Reviewed By: cortinico
Differential Revision: D60048949
fbshipit-source-id: 08792abd53ba919a7afc0922d6f7c98cc9c4544e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45590
This gives us more wiggle room with the release of 0.76.
Changelog: [General][Changed] Move init deprecation notice 30 Sept → 31 Dec
Reviewed By: cortinico
Differential Revision: D60105868
fbshipit-source-id: d03fcf5d4a97db9b21792eff6f993e2671b276ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45515
After some provisional hacking on macOS support for React Native DevTools last week, this revealed some incompatibilities with traditional OS X APIs, which are minimally addressed here.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59807146
fbshipit-source-id: 39c4eab723046926b0b469232152e2f994af2366
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45575
We should move over to use AssertJ as per our linter.
I'm adding it here to a first test and will use it as a reference for some OSS contributions from outside.
Changelog:
[Internal] [Changed] - Migrate settings-plugin to Assertj
Reviewed By: cipolleschi
Differential Revision: D60037797
fbshipit-source-id: 579ed7bf5fb219e25577af3ab87934503ee7898e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45572
0.75-rc.5 is currently broken on Windows.
This is due to us invoking `npx react-native-community/cli config` without
a `cmd /c` prefix.
This fixes it by using our function `windowsAwareCommandLine`.
The problem is that this required a lot of refactoring since that util was not available for the settings plugin.
Fixes#45403
Changelog:
[Internal] [Changed] - Fix core autolinking not working on Windows
Reviewed By: cipolleschi
Differential Revision: D60037587
fbshipit-source-id: eefeda7aafc43b9ce08f0f9225b0847fad2f46b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45587
changelog: [internal]
There is a way to avoid doing large number of JNI calls from JS thread for view preallocation on Android. We can move the JNI call to the main thread by creating a queue of views to be created on the JS thread and pulling it from the main thread. This way, the expensive part of JNI call (the actual call + creating JNI values) is moved to the main thread and doesn't block the JS thread from executing rendering.
Reviewed By: javache
Differential Revision: D59966062
fbshipit-source-id: af85138cfdb9b2a7a7710d79e09e165b2be55067
Summary:
The CLI of Metro bundler only accepts key presses when the Caps Lock is off. This is somehow inconvenient because the developers might think the Metro bundler doesn't response when the Caps Lock is on.
## 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
-->
[GENERAL] [ADDED] - Add upper case keys to the debug key handler
Pull Request resolved: https://github.com/facebook/react-native/pull/45559
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D60107316
Pulled By: dmytrorykun
fbshipit-source-id: 045dcd382d84c4781dff75a1ff913cd3ccc8d288
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45573
This makes this module now be fully in Kotlin instead of having mixed Java/Kotlin sources.
Changelog:
[Internal] [Changed] - Converted com.facebook.react.modules.dialog to Kotlin
Reviewed By: tdn120
Differential Revision: D60035771
fbshipit-source-id: b45fd099c0b353768ab6580eb6a4a3dccf68f07d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45570
We do have several methods/classes that are `deprecated` in the JavaDoc but not
with an annotation. That's not correct as users will never get those deprecation otherwise
and we'll be forced to keep both implementation around for a longer time.
Changelog:
[Internal] [Changed] - Properly annotate with Deprecated methods that are just deprecated in JavaDoc
Reviewed By: javache
Differential Revision: D60036159
fbshipit-source-id: 466072d6a3fb4f1220e1dc3deaa51a46c714a388
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45567
Changelog: [internal]
(internal because our integration for Perfetto hasn't been released in OSS yet)
In our current React integration for Perfetto we're logging arbitrary time spans via `performance.measure` in specific tracks (that can be custom based on a naming scheme).
For a given track, Perfetto doesn't allow partially overlapping segments (as it's considered to always be a stack of time spans). When logging arbitrary time spans that partially overlap, Perfetto cuts the nested ones to make sure they fit into their suspected parent. This makes the logged data incorrect and makes it hard to understand the performance of an application using this data.
There's a fix for this problem: logging these arbitrary segments/time spans in separate tracks that only share the name. In this case, Perfetto groups the data in the UI but allows overlapping (as they're not really on the same track).
Reviewed By: sammy-SC
Differential Revision: D60010696
fbshipit-source-id: 378ea492c4fafbe55ef97fa91e4fa50bbc1893ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45564
Changelog: [internal]
(this is internal because the integration hasn't been enabled in OSS yet)
In our current React integration for Perfetto we're currently creating multiple custom tracks that are spread throughout the process section and it can be hard to identify the source of the information.
This adds a "Web Performance: " prefix to all custom tracks coming from JS to achieve 2 purposes:
* Group them together (in terms of order in the process)
* Clarify the source of the data
Reviewed By: sammy-SC
Differential Revision: D60010695
fbshipit-source-id: 081f5b6417d676c61005114337530a089142e7c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45539
Changelog: [internal]
This exposes several classes (interfaces in the spec lingo) related to the Performance API to the global scope, so users can access them directly to do things like refinements using `instanceof`. This also prevents the need from importing the modules from `react-native` directly, which would prevent code sharing with Web.
Reviewed By: rshest
Differential Revision: D59859654
fbshipit-source-id: e1f7afb0c98b394b1f97c3790db2e570e6ba0cd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45535
Changelog: [internal]
Small refactor to group things based on the spec where they're defined.
Reviewed By: rshest
Differential Revision: D59911334
fbshipit-source-id: 1c40d6bf82b6cc7be78bd81b652d6855c39a53eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45526
Changelog: [internal]
Just using the right interfaces so we can expose them in the global scope and do refinements as necessary using `instanceof`.
Reviewed By: rshest
Differential Revision: D59911144
fbshipit-source-id: 9779e3220f2c6f81955f54506f97142f0f4ffdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45525
Changelog: [internal]
This makes several changes to the Performance API to align it closer with the spec:
* Makes fields of `PerformanceEntry` and subclasses read-only.
* Returns instances of the correct subclass of `PerformanceEntry` to observers.
* Renames `HighResTimeStamp` as `DOMHighResTimeStamp` for alignment with the spec and native
Additionally, I realized that the way we handle `performance.measure` is a bit problematic at the moment. When we call the function, we create a `PerformanceMeasure` instance with the data we receive, and return that value. In parallel, we notify the entry to native, which will in turn notify the observers. But the observers will not get those instances we just created, but new instances of `PerformanceEntry` (not even `PerformanceMeasure`) with the resolved values. At the same time, the `PerformanceMeasure` instance we return doesn't resolve its `startTime` and `duration` based on the indicated marks (when specified as strings). We need to fix this in the future by resolving the timing data synchronously when calling `performance.measure`.
Reviewed By: rshest
Differential Revision: D59911145
fbshipit-source-id: e0be0441f307cc9bdea8795ae88b6f390780fc7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45524
Changelog: [internal]
The `durationThreshold` option is only meant to be used with `event` entry types. `mark`, `measure`, `longtask`, etc. shouldn't take that option into account, as per the spec.
Reviewed By: mdvacca
Differential Revision: D59918519
fbshipit-source-id: 0553d46944cbe80a32712ff57140763f2514f734
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45545
ReactInstance creation in bridgeless returns a callback that requires dispatching on the UI thread to complete the init. If that thread is busy (eg with other startup tasks), we delay starting the initial surface unnecessarily.
This diff adds an experiment to return early from that startup task to allow follow-up tasks to be scheduled on the JS thread without waiting for lifecycle changes to have been applied.
Changelog: [Internal]
Reviewed By: markv
Differential Revision: D59961779
fbshipit-source-id: dd6a6fe093a32144ef6823bde5ac94a61d268fd2
Summary:
CircleCI was automatically cancelling an old run if a new commit was pushed on the branch.
GitHub does not have the same behavior enabled by default.
Keep running jobs in a pipeline when there is a new commit is usually wasteful of resources and cost money we can save.
## Changelog:
[Internal] - Cancel old jobs if a new commit is pushed
Pull Request resolved: https://github.com/facebook/react-native/pull/45568
Test Plan: Tested on GHA on this PR
Reviewed By: blakef
Differential Revision: D60035940
Pulled By: cipolleschi
fbshipit-source-id: 88b4dfc8bdd3eded6489a87db285e9544d3a1bcf
Summary:
In Node 20, the script to run unit tests in CI (`scripts/run-ci-javascript-tests.js`) will fail, even when all the Jest tests pass. This happens because one of the JS modules being tested is setting `process.exitCode` (see https://github.com/jestjs/jest/issues/9324#issuecomment-1808090455).
Changes:
- Modified the affected module to throw an exception when failing, instead of setting the exit code
- Adjusted the unit test for that module
## Changelog:
[General] [Fixed] - Remove setting of process.exitCode that breaks Jest tests
Pull Request resolved: https://github.com/facebook/react-native/pull/45562
Test Plan:
Before this change, running `node scripts/run-ci-javascript-tests.js` would fail with Node 20.
After this change, it succeeds.
Reviewed By: blakef
Differential Revision: D60033582
Pulled By: cipolleschi
fbshipit-source-id: 71b7f4495d414e719a9bd2d892bd1bc3045ddd5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45554
In this diff I'm extracting the creation of borderWidth into its own method, this is necessary for next diffs of the stack.
Nh behavior change is introduced here
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59942306
fbshipit-source-id: 85d39b64deaa4e8a8632d6f4aab72f626e594b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45553
This diff introduces a "temporary" method called getDiffProps to calculate the difference between 2 props and serialize its result into a folly::dynamic map.
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D59613245
fbshipit-source-id: 3e23cde0113ac2a3904c8daa48a1ca048cd0262d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45556
I missed updating this, and the e2e test we had isn't running, so switching JS objects to camel case broke this.
Changelog: [internal]
Reviewed By: jorge-cab
Differential Revision: D60003747
fbshipit-source-id: 6b7b1138e3ebbfdb982f5a089804351cc4b198ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45550
`ConcurrentModificationException` is happening from `emitScrollEvent()`.
This usually happens if we modify the collection (add/remove) while accessing collection in a foreach loop.
Seems likely add/remove is called from a different thread while in the foreach loop.
Converting to list before we do the foreach as a quick fix.
Changelog: [Internal] - quick fix for exception
Issure reported here: https://fb.workplace.com/groups/rn.support/permalink/26557068097248454/
Reviewed By: mdvacca
Differential Revision: D59991739
fbshipit-source-id: a2fcc798430acaadd07561a5be871967cc8f2c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45549
## Summary
Calling `getCurrentReactContext` on an unmounted `ReactRootView` could lead to a NPE. The method currently returns a nullable value so return type is the exact same. This change checks if the react instance manager is present and returns null early if not.
## Changelog:
[Android] [Fixed] - Adds a null check in react context getter
Reviewed By: zeyap
Differential Revision: D59982179
fbshipit-source-id: bac5c12e7dc4ee3296991063eb3746141b8446bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45544
## This diff now does 5 things:
1. removes the old way we used `actions/setup-node` to manage the cache itself.
2. it creates a new `update-node-modules-cache` workflow, which is the only job that will update the node modules cache
3. it create a `yarn-install-with-cache` action that should be used install of directly calling `yarn install --non-interactive`. This will load a cache against a hash of `package.json`.
4. updated the cache reaper to aggressively remove everything but the latest `npm-{{ hash('package.json') }}`.
5. removed a `cache-setup`, which couldn't be used (we're using artefacts now).
## Why are we doing this:
The various `node-cache-` keys for platforms and on various branches accounts for a very large proportion of the cache (10-20%).
We don't frequently change these dependencies, and even when we do running `yarn install` after loading the cache will resolve any issues.
Limiting the cache to `main` and aggressively pruning older cache entries will clean up a lot of "small win" caching.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59917944
fbshipit-source-id: 4be6f1959e8fde642a4f208f7d19aceba2c3262f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45530
Enable viewconfig validation for RNTester to catch where static and native viewconfigs are mismatched, during development or contribution time. This relies on `useNativeViewConfigsInBridgelessMode()` which is already enabled in `DefaultNewArchitectureEntryPoint` on Android, and seems to be in iOS AppDelegate `RCTRootViewFactory` as well.
We put it in an early place in the bundle before first render, since we don't have RNTester preludes right now, but I think it is still early enough?
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59946366
fbshipit-source-id: ae0c23b13a566489a88a7b4e408f61dce314b003
Summary:
This moves the `helloworld` app to build from the artifacts produced by build_npm_package so that we don't rebuild ReactNative Android from source 8 times.
It reduces build time of such jobs from 14mins to 4mins, resulting in 80mins of build time for every test_all run.
## Changelog:
[INTERNAL] - Move helloworld to build from artifacts on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/45517
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59957613
Pulled By: cortinico
fbshipit-source-id: b6c4adcf804af6c8d2661cf56549d037e09aa2c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45543
# Changelog:
[Internal]-
Introduced recently, this confuses viewconfig validation vs the vanilla Android view managers.
So this change effectively reverts the exposure of `ScrollView.scrollIndicatorInsets` to Android, achieving the goal in a different way (via the SVC injection workaround for the specific Android platform flavour).
Reviewed By: NickGerleman
Differential Revision: D59960782
fbshipit-source-id: 3b9a49f1466426d909e94bf4d33f1d09fbf822c2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45542
As we do have several version numbers for external actions all across the codebase,
here I'm aligning all of them to just use the majors.
I'm doing it only for GitHub first party actions as we trust them,
so minor/patch changes can safely be pulled in without code changes.
Changelog:
[Internal] [Changed] - Align github/* action versions on major
Reviewed By: cipolleschi, blakef
Differential Revision: D59959978
fbshipit-source-id: bb07ce0dfd74d9502a2ac0ea90a2b32f55d6d655
Summary:
With the migration to GHA, we can remove all the duplicated jobs from CircleCI.
These are the only 4 jobs remained to migrate
## Changelog:
[Internal] - Remove all the jobs already migrated to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45219
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D59156888
Pulled By: cipolleschi
fbshipit-source-id: 193f1f8fa7484154d5295ac36a63bb81a159da6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45541
This is another round of letting react-native-bot do the job that the
generic GitHub Action bot was doing.
Changelog:
[Internal] [Changed] - Act On label as react-native-bot
Reviewed By: cipolleschi
Differential Revision: D59959468
fbshipit-source-id: 8e0f7e2e90a40ed2aa265e637c8a809064e22747
Summary:
Nightly/Release workflow are currently broken due to a wrong path reference to a composite action. This fixes it.
## Changelog:
[INTERNAL] - Fix nightly/release workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/45537
Test Plan: CI
Reviewed By: cipolleschi
Differential Revision: D59959185
Pulled By: cortinico
fbshipit-source-id: 02c556d86105eac35e152b4dc09705bc42c8031a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45533
This input is unused and is causing a warning on the build pipeline.
I'm cleaning it up.
Changelog:
[Internal] [Changed] - Remove unused build-from-source input
Reviewed By: blakef
Differential Revision: D59958184
fbshipit-source-id: 23ba010da077342605afaaee122bc7ceabc89915
Summary:
Added space to $(inherited) string to avoid creation of wrong cpp flags in RCTAppDelegate podspec
<img width="1157" alt="Screenshot 2024-07-18 at 8 51 19 PM" src="https://github.com/user-attachments/assets/29d32d08-e81f-4c25-b8ee-5dccc0f620ea">
## Changelog:
[IOS] [FIXED] - Building of iOS project when RCTAppDelegate is used in the project
Pull Request resolved: https://github.com/facebook/react-native/pull/45520
Test Plan: To test this you can simply change in your node modules and run pod install, the build will now work successfully
Reviewed By: cipolleschi
Differential Revision: D59950906
Pulled By: arushikesarwani94
fbshipit-source-id: 0d58620aa0be7ac4fcbcd309f06df0eef7844016
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45529
`experimental_boxShadow` is not yet part of Android view managers, and when we enable it, we are likely to do a view manager at a time before moving to BaseViewManager.
This causes user-visible errors when viewconfig validation is turned on, since we have a static view config, but not yet a native view config.
This removes the static viewconfig for Android until we start adding setters to view manager.
It is kept in `ReactNativeStyleAttributes` (which I think can have members not in the native view-config, since it has component specific props like tintColor), and iOS base viewconfig. On Fabric iOS, this is part of BaseViewProps, and handled by RCTView, but it looks like the prop (and also `experimental_filter`, `experimental_mixBlendMode`) do not have entries in iOS RCTViewManager, which is fixed in next diff in the stack.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59939866
fbshipit-source-id: 2781029a0c29ba111ed04edfe9940c6c72f4e5ac
Summary:
Viewconfig processors may still get called for nullish values I think. Most other processors explicitly handle these (but some don't??).
This returns an empty list, like on parse error, when we have a value, but the value is nullish.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D59933611
fbshipit-source-id: 3f1d89d21977bbe01a05e708aadf1a9451d88083
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45512
isBufferingEnabled_ can be read (by design) from multiple threads, but
it's not atomic. Make it so.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59907026
fbshipit-source-id: ffce54a28404148b3e270fa90dfe850a334ca2f0
Summary:
This PR fixes a case where the user initializes react native in a directory that contains a space.
It was causing pod install to fail because the path to `create-dummy-hermes-xcframework.sh` script wasn't in a string.
## Changelog:
[IOS] [FIXED] - Hermes prepare_command fails with space in path
Pull Request resolved: https://github.com/facebook/react-native/pull/45316
Test Plan:
1. Create a directory with space in path
2. Initialize React Native inside
3. Install pods
4. Check if pod install doesn't fail
Reviewed By: dmytrorykun
Differential Revision: D59912979
Pulled By: cipolleschi
fbshipit-source-id: b2c08d5035a245f8b4d6bfaf562e46d9c5d127b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45501
changelog: [internal]
Implement caching for FabricUIManager::getColor. A call to FabricUIManager::getColor takes on average 0.4ms and there can be many of them. The arguments for the call keep repeating in majority of times. Employing a simple caching mechanism here to avoid unnecessary trips via JNI to reduce overhead.
The dependencies in graphics in BUCK are incorrect. I tried to separate this into multiple files and move implementation to .cpp file but this will require a bit of a more restructuring to make it possible.
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D59859754
fbshipit-source-id: 748efce7f0b8c96001b6ac1a4b457b8c9d63fe9c
Summary:
Factor out the Build NPM package job in a separate action for code reuse
## Changelog:
[Internal] - Factor out the Build NPM package job in a separate action for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45493
Test Plan: GHA are green
Reviewed By: robhogan
Differential Revision: D59858572
Pulled By: cipolleschi
fbshipit-source-id: 561a215ba5812352034157aa254999db56fcd31e
Summary:
With the recent changes to the CI, we need to update the test-e2e-local to work with the new artifacts
## Changelog:
[Internal] - Update local-e2e-test to run with the new Android Artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/45499
Test Plan: Tested locally.
Reviewed By: blakef
Differential Revision: D59902087
Pulled By: cipolleschi
fbshipit-source-id: 84ef78e8dba222bf8a9e3620632fb2a9d286d42b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45471
Changelog: [internal]
This is a React Native specific modification of the Long Tasks API that refines the logic to detect long tasks considering voluntary yielding checks.
In RN, as opposed to Web, we can have a very long task executing in the JS thread without causing any issues to the responsiveness of the app, as long as the task checks whether it should yield in short intervals. In this case, if the app always checks whether it should yield at least once every 50ms, the task will not be considered "long".
Check the new unit tests to see this behavior in practice.
Reviewed By: sammy-SC
Differential Revision: D55647992
fbshipit-source-id: 82ab41173d4d9deee65b8ade2268c40d7f58c6e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45473
This is a basic implementation of the Long Tasks API (https://w3c.github.io/longtasks/).
It detects and reports long tasks when using the Event Loop (in the modern RuntimeScheduler) when a new feature flag for this purpose is enabled.
This doesn't include attribution information at the moment.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D55491870
fbshipit-source-id: e1ccad9cc6a35073b31230a8cf3a4660ab9a043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45492
Changelog: [internal]
When testing the changes in https://github.com/facebook/react-native/pull/45473 / D55491870, I saw that the reported time spans for long tasks didn't perfectly align with the long tasks themselves in traces (Perfetto).
Taking a closer look, I realized that I wasn't doing the conversion between times and durations from `chrono` and `DOMHighResTimeStamp` (a `double`) correctly, and we're doing this conversion very often.
This moves the definition of `DOMHighResTimeStamp` to its own library and adds conversion methods to make sure we don't make this mistake in the future.
Reviewed By: rshest
Differential Revision: D59820241
fbshipit-source-id: c123920de56336da384ddc484f6ac9d287724301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45464
Previous work would cause versions >= react-native 0.76 to exit if called through `npx react-native <cmd>`. This was intended to be full deprecated and removed. The intention was to shift users to calling react-native-community/cli directly.
This change allows commands to be proxied to react-native-community/cli but with no guarantees of success. It's up to each framework / project to explicitly create that dependency.
This also provides warnings, which won't go away, suggesting the supported method of calling the community CLI directly.
The outcome is that we're not going to break existing workflows.
closes: #45461
Changelog: [General][Fixed] allow proxying commands from react-native to react-native-community/cli with explicit warning
Reviewed By: cortinico
Differential Revision: D59805357
fbshipit-source-id: 21e23b082a9c709effa050d8e7dd04a40f5ab0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45483
We don't really use this functionality and is getting harder to migrate to GHA,
hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove report-app-size
Reviewed By: cipolleschi
Differential Revision: D59822862
fbshipit-source-id: 2d082454aea3b3c5863bd34556a23c2fc847f841
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45510
This is just a quality of life improvement, where we test the C++ autolinking
code generation a bit more.
Changelog:
[Internal] [Changed] - Improve tests for GenerateAutolinkingNewArchitecturesFileTask
Reviewed By: blakef
Differential Revision: D59907847
fbshipit-source-id: e6367cc3b1c01700310437b73bc984e3666b3499
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45511
This adds react-native.config.js to autolinking default lockfiles
so autolinking can account for changes in that file.
Changelog:
[Internal] [Changed] - Add react-native.config.js to autolinking lockfiles
Reviewed By: blakef
Differential Revision: D59907268
fbshipit-source-id: d5893a3f7b4d5d9f6c6c13042aa6866ad16b2ea4
Summary:
This change adds a job that runs 2 hours after the nightlies. This jobs returns successfully if the nightly has been published or it report an error in case it has failed.
We will hook this signal to the internal system to be notified about Nightlies failures
## Changelog:
[Internal] - Add jobs to check for nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/45509
Test Plan: Test the Action on GHA
Reviewed By: blakef
Differential Revision: D59907442
Pulled By: cipolleschi
fbshipit-source-id: 3b35aa2ad69b376c65a765f740a1d6e6ed8ad99f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43333
This change fixes https://github.com/facebook/react-native/issues/43285.
Basically, when using a `yarn` alias to install pods, yarn creates a copy of the `node` and `yarn` executables and the `command -v node` command will return the path to that executable.
## Changelog
[iOS][Fixed] - Do not use temporary node when creating the .xcode.env.local
Reviewed By: dmytrorykun
Differential Revision: D54542774
fbshipit-source-id: 3ab0d0bb441988026feff9d5390dcfd10869a1b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45508
The scripts/clean-gha-cache.js uses the `gh` cli too, which expects the GITHUB_TOKEN presented GH_TOKEN. Also allowed us to manually kick off this workflow.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59901639
fbshipit-source-id: f3543cc83cbf67b6969abc3390790e038e06c305
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45503
Kebab case object literals are a pain as an API to give folks. Keep string parsing using the kebab-case web names, like in CSS, but keep object notation camelCase.
This is super super hacked up, and we should burn away all these viewconfig processors as soon as we can.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59793095
fbshipit-source-id: 888cad31142d7aeed42687ab23c2023ac7e4882d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45452
With this we enable <View> to use BoxShadow.
BoxShadow property can be a string as defined on MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow
Or it can also be a list of BoxShadow primitives:
```
[
{
offsetX: 10,
offsetY: 5,
color: 'red',
inset: true,
},
{
...
},
]
```
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn boxShadow format into parsed boxShadow primitive
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57872933
fbshipit-source-id: 2c5732709959bd996cce2f979549fc95cf2410e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45481
We are going with this name as it is more commonly used in the spec and makes more sense since there are no circles involved with spread
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59819180
fbshipit-source-id: cf20c22b11e9ff9935b9f54e28db37d3ea399d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45334
Adds support for the `xml` file extension as a loadable asset, and lets Flow treat the type signature as an image
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58261501
fbshipit-source-id: b29cffee81d0438827529711e86267edd5d2a0f7
Summary:
I'm picking 1630b5c743 in main as it's currently missing (available only on `0.75-stable`).
## Changelog:
[INTERNAL] - Update testing scripts to work with any version of React native
Pull Request resolved: https://github.com/facebook/react-native/pull/45498
Test Plan: Nothing to test as this is a backport
Reviewed By: cipolleschi
Differential Revision: D59861440
Pulled By: cortinico
fbshipit-source-id: 57f642c66c7a6976f5a5cd53debaeb2e461a1f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45457
With this change, we are implementing in Android a similar logic that we implemented in iOS.
1. When the user stops dragging a scroll view, it tells native animated modle that a scroll has finished
2. NativeAnimated module asks to the NativeAnimatedNodesModule if there are native node listening to the scroll
3. In case they are, it emits an event to JS
4. JS listen to the events and resync the Shadow Tree and the Native Tree (this implemented in a previous change)
## Changelog
[Android][Fixed] - Sync the Shadow Tree and the Native Tree with Native animation when scroll is driving the animation
Reviewed By: sammy-SC
Differential Revision: D59756577
fbshipit-source-id: e558557b477f4da9da1f89fb31ba86d0ea1390a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45383
This is the second step required to fix the onTouchMove event in the new architecture.
In this change, we are retrieving the list of nodes that are connected by the animation, and we are sending an event to the nodes so that we can trigger the commit.
## Changelog
[iOS][Added] - retrieve the tags of the nodes connected by the animation and send them to JS
Reviewed By: sammy-SC
Differential Revision: D59524617
fbshipit-source-id: 584317afa8e4cf0ad9f98f38e4e5d436c5fe3ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45382
This change is the first step to tr and solve the pressability's `onTouchMove` issue with animation driven natively in the New Architecture.
The idea is to trigger a special event from native to let JS know that a scroll event has ended (`scrollViewDidEndDragging` or `scrollViewdidEndDecelerating`).
When this happens, we need to send an event to JS to let him know that it has to sync the Native Tree with the Shadow Tree.
Step 2 is to connect Native with JS
## Changelog:
[iOS][Added] - Send onScrollEnded event to NativeTurboAnimatedModule
Reviewed By: sammy-SC
Differential Revision: D59459989
fbshipit-source-id: cb425cddcdaa9d700ec40accaf4ab3ce1f3c5038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45495
Unify type definitions to semver@7, to fix a [type-sync](https://www.internalfb.com/intern/test/281475050813096/) test that was broken by D59378011. The test is very simple and doesn't actually understand the typing.
I don't believe there is a significant difference in the typing, esp. with how we're using it. Flow will tell us if this is the case though (🏖️🏰).
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D59855434
fbshipit-source-id: ae3c6b7aa81b3cde25468d72a7922bcb2b6f652f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45478
Some code is far too recursive. This consumes buffer space and causes problems for the Perfetto frontend. Let's limit it to 50 frames.
Changelog: [Internal]
Reviewed By: rubennorte, sammy-SC
Differential Revision: D59813638
fbshipit-source-id: 69068f9c2193d706ec0cc00ffc0d5950ae094e05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45474
Our actions inputs are now a mixture of different casing.
I'm moving everything to be kebab-case
Changelog:
[Internal] [Changed] - Composite actions inputs should be kebab-case
Reviewed By: cipolleschi
Differential Revision: D59809181
fbshipit-source-id: af6d541c2b4f5fa162dcde412fb8808bae1ef2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45480
We currently use the default GITHUB_ACTION which makes a lot of interaction
appear as user "GitHub Actions". Instead we could use the `REACT_NATIVE_BOT_GITHUB_TOKEN`
which we have as secret so the bot will actually perform the actions.
Changelog:
[Internal] [Changed] - Act as react-native-bot on all the actions
Reviewed By: cipolleschi
Differential Revision: D59815201
fbshipit-source-id: 702b121ec07d0db10abf25e23f7ddf5658dd5d62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45491
The build_android job was missing the sonatype credentials so could not
publish a -SNAPSHOT version. This fixes it.
Changelog:
[Internal] [Changed] - Unbreak nightlies by fixing secrets
Reviewed By: cipolleschi
Differential Revision: D59848810
fbshipit-source-id: 2cc1d03b090d0aeb3886590ec0696f9c3a6556b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45485
## Changelog:
the new functions I introduced in https://github.com/facebook/react-native/pull/45365 to read color channel value, like `alphaFromColor`, will return float between 0~255 on iOS and 8bit unsigned ints on other platforms, because of different platform implementation. However that way we cannot assume consistent return value across platforms, which kind of contradicts with RN's cross platform design.
so here I make `alphaFromColor` in Color.h (the cross platform method) to always return uint8_t, while still allow `alphaFromHostPlatformColor` to return different result
[Internal] [Fixed] -
Reviewed By: christophpurrer
Differential Revision: D59826142
fbshipit-source-id: 4401918be29980474bdc8601443ae33155710f22
Summary:
FIXES [45404](https://github.com/facebook/react-native/issues/45404)
sending headers from Image component not working in new arch , implementation was missing
```
<Image
source={{
uri: "http://localhost:3000/image",
headers: {
"test-header": 'test',
"hello":"tested"
}
}}
style={{
width: 300,
height: 300,
}}
/>
```
## Changelog:
[IOS] [ADDED]- sending missing **headers** field with **Image** component in fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/45415
Test Plan:
# Tested
Attaching the below video to show how headers are getting received on server from Image component running in new arch
https://github.com/user-attachments/assets/c816265d-0bb5-4670-bde0-cfec72d7618f
Reviewed By: javache, cipolleschi
Differential Revision: D59807462
Pulled By: blakef
fbshipit-source-id: dffa4d80db58de6a81947ac876aa76ec7e62dd48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45445
Roll our own base64 encoding and revert D59685218, which fixed the missing Folly dependency implied by D54309633.
I assumed Folly base64 was already elsewhere in RN but given it isn't, and we only need simple, non-perf-sensitive encoding for the debugger (not the SIMD or delegated implementations, or decoding), it might be best to just include our own encoder.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58323859
fbshipit-source-id: 5ce98561e9ced82765e8e7c18e5d2ebfa8148c8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45468
This should greatly reduce the time spent on build_npm_package
because we're moving all the publishing logic to build_android.
I need to do a bit more testing with nightlies to make sure that everything is published correctly.
Changelog:
[Internal] [Changed] - Make build_android publish to the stating repositories
Reviewed By: cipolleschi
Differential Revision: D59804015
fbshipit-source-id: be3f0b6e16f5fdbf760ec7a5e16c8e258e06dd28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45426
The initial implementation of `Network.loadNetworkResource` and the accompanying `IO.read` (D54202854) base64-encodes all data as if it is binary. This is the more general case, and we'll continue to base64-encode non-text resources.
In the common case of text resources (particularly JS and JSON), it'd be preferable to do as Chrome does and send UTF-8 over the wire directly. This has a few performance benefits:
- Less CPU and RAM footprint on device (UTF-8 truncation is constant-time, fast, and in-place), similarly less decoding for the frontend.
- 25% less data per chunk (base64 encodes 3 bytes as 4 characters), implies up to 25% fewer network round trips for large resources.
It also has the benefit of being human-readable in the CDP protocol inspector.
## Determining whether data is text
We use exactly Chromium's heuristic for this (code pointers in comments), which is based only on the `Content-Type` header, and assuming any text mime type is UTF-8.
## UTF-8 truncation
The slight implementation complexity here is that `IO.read` requests may specify a maximum number of bytes, and so we must slice a raw buffer up into valid UTF-8 sequences. This turns out to be fairly simple and cheap:
1. Naively truncate the buffer, inspect the last byte
2. If the last byte has topmost bit =0, it's ASCII (single byte) and we're done.
3. Otherwise, look back at most 3 bytes to find the first byte of the code point (topmost bits 11), counting the number of "continuationBytes" at the end of our buffer. If we don't find one within 3 bytes then the string isn't UTF-8 - throw.
4. Read the code point length, which is encoded into the first byte.
5. Resize to remove the last code point fragment, unless it terminates correctly exactly at the end of our buffer.
## Edge cases + divergence from Chrome
Chrome's behaviour here in at least one case is questionable and we intentionally differ:
- If a response has header "content-type: text/plain" but content eg`0x80` (not valid UTF-8), Chrome will respond to an `IO.read` with `{ "data": "", "base64Encoded": false, "eof": false }`, ie an empty string, but will move its internal pointer such that the next or some subsequent `IO.read` will have `"eof": true`. To the client, this is indistinguishable from a successfully received resource, when in fact it is effectively corrupted.
- Instead, we respond with a CDP error to the `IO.read`. We do not immediately cancel the request or discard data, since not all `IO.read` errors are necessarily fatal. I've verified that CDT sends `IO.close` after an error, so we'll clean up that way (this isn't strictly guaranteed by any spec, but nor is `IO.close` after a resource is successfully consumed).
Changelog:
[General][Added] Debugger: Support text responses to CDP `IO.read` requests
Reviewed By: hoxyq
Differential Revision: D58323790
fbshipit-source-id: def8bf8426266f16bb305d836a6efe8927a9dfc4
Summary:
When running the entire unit test suite of `RNTesterPods` with `TSan`, I saw that occasionally a data race was detected on line 843 of `RCTImageLoader`. It seems the completion handler that does contain the lock around `cancelLoad` is called concurrently with the value being assigned on line 843. Here there is no lock in place.
Here is the output of `TSan` when I comment out my fix:
```
WARNING: ThreadSanitizer: data race (pid=72490)
Write of size 8 at 0x000144151ce8 by main thread:
#0 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16e8030)
https://github.com/facebook/react-native/issues/1 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/4 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Previous write of size 8 at 0x000144151ce8 by thread T4 (mutexes: write M0):
#0 __140-[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x16e8894)
https://github.com/facebook/react-native/issues/1 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke <null> (RNTesterUnitTests:arm64+0x16e3430)
https://github.com/facebook/react-native/issues/2 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_3 <null> (RNTesterUnitTests:arm64+0x16e52a8)
https://github.com/facebook/react-native/issues/3 __75-[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x7f24)
https://github.com/facebook/react-native/issues/4 -[RCTConcreteImageURLLoader loadImageForURL:size:scale:resizeMode:progressHandler:partialLoadHandler:completionHandler:] <null> (RNTesterUnitTests:arm64+0x6c470)
https://github.com/facebook/react-native/issues/5 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke.172 <null> (RNTesterUnitTests:arm64+0x16e4964)
https://github.com/facebook/react-native/issues/6 __tsan::invoke_and_release_block(void*) <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x77ee0)
https://github.com/facebook/react-native/issues/7 _dispatch_client_callout <null> (libdispatch.dylib:arm64+0x3974)
Location is heap block of size 48 at 0x000144151cc0 allocated by main thread:
#0 malloc <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x4fa48)
https://github.com/facebook/react-native/issues/1 _malloc_type_malloc_outlined <null> (libsystem_malloc.dylib:arm64+0xf3ec)
https://github.com/facebook/react-native/issues/2 _call_copy_helpers_excp <null> (libsystem_blocks.dylib:arm64+0x10b4)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/5 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/6 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Mutex M0 (0x000108f316e8) created at:
#0 pthread_mutex_init <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2cc98)
https://github.com/facebook/react-native/issues/1 -[NSLock init] <null> (Foundation:arm64+0x5ca14c)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/5 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Thread T4 (tid=10935088, running) is a GCD worker thread
```
## Changelog:
[iOS][Fixed] Data race in `RCTImageLoader` related to assignment of cancellation block.
Pull Request resolved: https://github.com/facebook/react-native/pull/45454
Test Plan: There are already tests in place for `RCTImageLoader`. I hope these will cover the fix.
Reviewed By: realsoelynn
Differential Revision: D59816000
Pulled By: zeyap
fbshipit-source-id: f959d472eb60f83f39ced6711ee395949ab37e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45479
This just prints a summary on PRs if the Gradle task fails so it's easier to jump directly
to the failure.
Changelog:
[Internal] [Changed] - Enable add-job-summary-as-pr-comment for failed jobs
Reviewed By: cipolleschi
Differential Revision: D59812845
fbshipit-source-id: 2069a1c8db7d264ca1af3c1182fa443cb0a69646
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45469
Enables React Native DevTools by default on `main`, ahead of the 0.76 release. We've observed no new bug reports internally over the last two weeks, and are moving forward with our rollout plan.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D59804882
fbshipit-source-id: 0cb6302f4d940718786db2e5d8fb652fae6a8c54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45475
Instead of zipping all the RNTester's APK together, let's
upload them per buildVariant so it's easier to retrieve them later.
Changelog:
[Internal] [Changed] - Split the rntester APK artifacts in 4
Reviewed By: cipolleschi
Differential Revision: D59809721
fbshipit-source-id: 2d375475d5cee71c212f4d1f3a4a9edf3442358f
Summary:
We don't need to specify a minor/patch for actions/upload-artifact.
We also have all sorts of different versions scattered around the codebase.
This aligns them to the latest sable in the 4.x series.
Changelog:
[Internal] [Changed] - actions/upload-artifact to v4.x
Reviewed By: cipolleschi
Differential Revision: D59811525
fbshipit-source-id: 7264db097bcb2ff34b3ace467996e8308c0f2034
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45463
Changelog: [Internal]
State updates will clone shadow nodes for an shadow tree revision that is outdated.
This can lead to accessing deallocated shadow node references because the JS renderer committed a newer revision and deallocated the one used by the pending state update.
By using a weak pointer to hold a reference to the runtime shadow node reference, we can only update references for wrappers that are still valid.
Reviewed By: javache
Differential Revision: D59804999
fbshipit-source-id: 89c9967d139d3cac7d7252994beae419bc591e79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45413
## Changes
Add an example in RNTester to test that pressability with NativeDrivers works properly.
## Context
The pressability handling is a bit peculiar.
We have to handle 3 main behaviors:
* `PressIn` -> `PressOut` => triggers the `onPress`
* `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress`
* `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`.
For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works.
When a move is involved, we:
1. Detect the initial press in the Native layer
2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer
3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect).
The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is.
This results in issues like the one shown by [#36504](https://github.com/facebook/react-native/issues/36504), where the onMove is not handled correctly.
## Solution
The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision.
We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations.
## Changelog
[General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers
Reviewed By: sammy-SC
Differential Revision: D58182480
fbshipit-source-id: 9ca4fb9a3ca1a8af52ccbe208cbfe8434175f87d
Summary:
CCI on main is broken. We suspect that's due to cache issues which restore a wrong layout for the Folly pod.
This PR is an attempt to fix it
## Changelog:
[Internal] - Fix missing folly base 64
Pull Request resolved: https://github.com/facebook/react-native/pull/45460
Test Plan: CCI and GHA are green
Reviewed By: sammy-SC, huntie
Differential Revision: D59804748
Pulled By: cipolleschi
fbshipit-source-id: 44d6b169cf3319f4d7ee9e0a5833f07bc6ba4bb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45458
Checking for packager is an async operation, which may return when we've already destroyed the ReactInstanceManager. Prevent the CatalystInstance from being created if the ReactInstanceManager has been invalidated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59753247
fbshipit-source-id: e3ac2b6dd142330e2d4051519b9863584b33f8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45459
Seeing failures on main with GHA for gradle builds, in the Post Setup gradle step:
```
Could not get unknown property 'cleanupTime' for object of type org.gradle.api.internal.cache.DefaultCacheConfigurations.
```
This is a speculative change to get CI back to stable.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59802517
fbshipit-source-id: c7b5259397fddef9420570043263e92f21718934
Summary:
This change factors out build-android job so we can reuse it
## Changelog:
[Internal] - Factor out the build-android job for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45455
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59802116
Pulled By: cipolleschi
fbshipit-source-id: 12ece8004da3bfd1f275b4af8e9822d4b0ccc0f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45448
changelog: [internal]
I would like to experiment with executing insert mount instructions after layout and state update. It has shown small improvement in local testing
Reviewed By: mdvacca
Differential Revision: D59582123
fbshipit-source-id: 3ee6ec12a533a287ed32f7373863175f3a107548
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45410
changelog: [internal]
For better performance, let's test setting up the animation graph from passive effects. This will delay the work, not blocking the paint.
Reviewed By: rubennorte
Differential Revision: D59644374
fbshipit-source-id: ff951ee7c1a1d47e13c55fc7c7f6c0690aa465f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45444
## Changelog:
[Internal] -
Even though `ScrollView.scrollIndicatorInsets` isn't supported on the vanilla Android platform, it still may be used on some other variations of it, which means that the changes may not potentially find the way into C++/Fabric, opening a door of all kinds of weird corner case issues.
Reviewed By: christophpurrer
Differential Revision: D59761458
fbshipit-source-id: 4dae5c96791ca924d589a3d803d8fa60fdca1b67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45304
Add support for most keyword values of mix-blend-mode on iOS and added RNTester Example
Missing compositing operators and global values
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59402969
fbshipit-source-id: b7e1aaed01fbf8f80e04ad0fa73d2ef63b5ad933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45306
Adding missing drop-shadow test to rn-tester.
Added with alpha-hotdog image to show we are creating the shadow with the alpha channel of the view.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59410148
fbshipit-source-id: 5a03ee84313979f99585b8ca7e07abf9cdbe2396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45443
We are only building these out for Fabric. This means only one natural iOS impl, but that other Android bits will not work fully correctly on Paper (like setting containing block for filter element). This also means we can remove view configs once we're on Fabric CSS parser. We will do the same for boxShadow once that is ready.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D59762282
fbshipit-source-id: 14ce07f04b822c6aee908894c9081419594fc484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45421
RNTester contains Android resources that are loaded by name and not resolved by Metro. As a result, these assets are not automatically linked when RNTester JS code is embedded in other projects. This is considered "legacy" loading and is generally discouraged, but is still showcased as an alernative way of loading resources.
I also modified the Image test to ensure that flag status is printed so it's obvious why the vector drawable hasn't loaded.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59585555
fbshipit-source-id: d42fb44d8846d8e7c7aa01dca4cec89ae85a9195
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45442
This deprecates also `DeveloperSettings.isStartSamplingProfilerOnInit`
so we can remove it in a future version of React Native.
This field is unused so you should not be using it at all.
Changelog:
[Android] [Changed] - Deprecate DeveloperSettings.isStartSamplingProfilerOnInit
Reviewed By: blakef
Differential Revision: D59757500
fbshipit-source-id: dc879ba46f2f937e5f259a4101646c2f060db548
Summary:
## Summary
Now that HostContext determination for Fabric is a DEV-only behavior, we
can move the HostContext determination to resolve from the ViewConfig
for a given type. Doing this will allow arbitrary types to register
themselves as potential parents of raw text string children. This is the
first of two diffs for react as we'll:
1. Add the new property to the ViewConfig types
2. Update React Native to include the `supportsRawText` property for
`RCTText`, `RCTVirtualText`, `AndroidTextInput`, etc.
3. Switch the behavior of react to read from the ViewConfig rather than
a static list of types.
Changelog: [Internal]
## Test Plan
- yarn test
- yarn test --prod
- Pulled change into react-native, added `supportsRawText` props to
RCTText, RCTVirtualText, etc. ViewConfigs and confirmed everything type
checks.
DiffTrain build for commit https://github.com/facebook/react/commit/a5cc797b8801dfe58c7a34c99a9fa60c6c9c8274.
bypass-github-export-checks
Reviewed By: poteto
Differential Revision: D59641180
Pulled By: rozele
fbshipit-source-id: a3ddb1bc810a70d5f782e708cb845e3eae136d78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45365
## Changelog
As a followup to https://github.com/facebook/react-native/pull/45139
There I only implemented `hostPlatformColorFromRGBA` and `alpha/red/green/blueFromHostPlatformColor` on cxx platform, then used cxx platform specific method at some places. but really I should implement and use methods in `Color.h` that are platform agnostic
* cxx/android: platform color format is int32_t, RGBA are 8bit unsigned int ([0,255])
* windows: platform color format is `winrt::Windows::UI::Color` where RGBA props are 8bit unsigned ints ([0,255])
* apple: platform color format is `UIColor` where RGBA props are floats in [0,1]
[Internal]
previous change D58872165
Reviewed By: christophpurrer
Differential Revision: D59593659
fbshipit-source-id: 5d18419039817510e607d4e3f632c207d25c30a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45436
changelog: [internal]
In D58355433, delete tree experiment was cleaned up. These are the remainings of the experiment that are no longer used. Let's delete them to clean up dead code
Reviewed By: javache
Differential Revision: D59732137
fbshipit-source-id: a22c0b14eda70e62817e80224f367ccb9006acc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45354
Fresco has indicated that they have no plans to support loading vector assets and similar drawable types in Drawee-backed views ([issue](https://github.com/facebook/fresco/issues/329), [issue](https://github.com/facebook/fresco/issues/1463), [issue](https://github.com/facebook/fresco/issues/2463)). Guidance has been to instead load the vector drawable onto the backing image view ourselves. On the React Native side, having the ability to load vector drawables has been requested many times ([issue](https://github.com/facebook/react-native/issues/16651), [issue](https://github.com/facebook/react-native/issues/27502)).
I went this route over using a custom Fresco decoder for XML assets because vector drawables are compiled down into binary XML and I couldn't find a trivial, performant way to parse those files in a context-aware manner. This change only accounts for vector drawables, not any of the other XML-based drawable types (layer lists, level lists, state lists, 9-patch, etc.). Support could be added easily in the future by expanding the `getDrawableIfUnsupported` function.
## Changelog
[Android] [Added] - Added support for rendering XML assets provided to `Image`
Reviewed By: javache
Differential Revision: D59530172
fbshipit-source-id: 3d427c06238287e0a3b7f9570ac20e43d76126c7
Summary:
This is just a minor nit to make it easier to copy-n-paste
## Changelog:
[INTERNAL] - Remove extra dot from close-pr.yml
Pull Request resolved: https://github.com/facebook/react-native/pull/45441
Test Plan: N/A
Reviewed By: cipolleschi
Differential Revision: D59752879
Pulled By: cortinico
fbshipit-source-id: caa398010b64024e2a0259d177762fd76082507f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45440
We only have one type of JavaScriptException anymore, so this can be simplified.
Changelog: [Android][Removed] Removed HasJavascriptExceptionMetadata as a marker interface. Use JavascriptExecption directly
Differential Revision: D57379390
fbshipit-source-id: a088834fddb156ceed5ccc8010d3c4acd365bf29
Summary:
The rn-tester android build assumes the react-native-community/cli is available. This is no longer the case.
Changelog: [Internal]
Differential Revision: D59170923
Pulled By: blakef
fbshipit-source-id: 6f414c2be387ef46dd50ce09a98beb230c8e73b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45420
Devex improvement to skip validation when no native view config exists. Redbox is still hit, showing the true error. See test plan below before/after
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59702501
fbshipit-source-id: 9aada9813c2930ee2b4bb23e5ba8a3e546c4e9af
Summary:
This change factors out the build hermesc windows job into a separate action to reuse the code in different jobs
## Changelog:
[Internal] - Factor out build hermesc windows for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45432
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59748955
Pulled By: cipolleschi
fbshipit-source-id: bb6b96c93ec7ba6af1a210511ec672907f237b45
Summary:
Call the react-native-community/template GHA to trigger a new release when we publish a react-native release. This then waits to confirm that the package is published.
See react-native-community/template#36 for the matching change
Changelog: [General][Added] trigger template publish
Pull Request resolved: https://github.com/facebook/react-native/pull/45327
Test Plan: Not sure on the best way forward here.
Reviewed By: cipolleschi
Differential Revision: D59467829
Pulled By: blakef
fbshipit-source-id: 091269e7ecdae5801ac7c03a1ede54452ae99b24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45423
I noticed while fixing some CI issues that `jsinspector` emits a bunch of warnings, making finding errors (especially in CI logs) awkward.
Also fix up a couple of stale comments from earlier designs of `NetworkIOAgent`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59693730
fbshipit-source-id: d032150787bda320b9c38ccf2e95139411758f47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45380
Removed the use of version checking and error code that is in react-native-community/cli-tools.
Changelog:
[Internal] [Changed] - Removed community-cli-plugin version & error dependencies
Reviewed By: robhogan
Differential Revision: D59378012
fbshipit-source-id: b009edc615b873ff2bff31296ac5d87a4482944f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45381
Removing the remaining dependencies from the react-native-community/*. This
inlines a copy of the logger.
Changelog:
[Internal][Changed] Removed react-native-community/cli-tools logger dependency
Reviewed By: cipolleschi
Differential Revision: D59378011
fbshipit-source-id: ef93d9fff1c623658e33c36b6329f5d548f649e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45409
Changelog: [internal]
This removes `BridgelessJSCallInvoker` in favor of `RuntimeSchedulerCallInvoker`. This change should be transparent when not invoking JS callbacks using priorities, as both of them would just go directly to the scheduler using `scheduleWork`, but when priorities are specified, they'd now be honored in `RuntimeSchedulerCallInvoker`.
I realized this wasn't being used when I saw that `PerformanceObserver` callbacks were always scheduled with the highest priority, instead of with idle priority as specified in code.
Reviewed By: sammy-SC
Differential Revision: D59679512
fbshipit-source-id: 51d36d56ef1ff0b34e5157ed7b5e08de0a3884d2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45387
This diff prepares an experiment to test `setNativeProps` for syncing the final state of native driven animations with Fabric.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59634489
fbshipit-source-id: 453c5a2f0edfea695f7564e0c5ead58db21cf61e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45337
tsia. Some things to consider when reviewing:
* Made a new drawable for inset shadows
* The drawable in this class is the same size as the view with some padding. The padding is needed for 2 reasons
* Blur near edges looks good
* Blur artifacts can appear inside the view if the clear region barely exits the bounds of the view
* We draw the clear shape with another drawable, which solely exists so that we can get the border box path for the adjust border. We just use this path to clip out the shadow
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59300215
fbshipit-source-id: 30acc7aafd82122aa278a42d06418bb1079ca71f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45408
Changelog: [General][Fixed] Fixed prioritization of idle priority tasks
We recently found out that idle priority tasks were never scheduled with the lowest priority possible. We didn't realize before because idle priority tasks weren't used, but now they are via `requestIdleCallback` and other mechanisms.
The problem was that the timeout for idle priority tasks was `std::chrono:milliseconds::max()`, and we compute the expiration time adding that to the current time. Doing that operation is always guaranteed to overflow, and the resulting expiration time was always in the past, resulting in the task having higher priority than any other tasks with any other priorities.
Instead of using `max()` we can just use a sensible value for idle priorities. In this case, 5 minutes should be more than enough.
Reviewed By: sammy-SC
Differential Revision: D59679513
fbshipit-source-id: 6c0f9e275818737ce804f05615c01f7ea6c126ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45396
This diff extends TransformOrigin with a new method to serialize this Struct into a folly::dynamic map (similar to Transform)
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D59613247
fbshipit-source-id: 00e4a08d1a99fe9cabb67206e21712e65b355f7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45417
Add sources for `folly::detail::base64` to our existing `folly` dependency for Android and iOS OSS build toolchains, now a (tiny) dependency of the JS debugger since D54309633, and already part of Folly's Buck sources.
Changelog: [Internal]
Reviewed By: cipolleschi, blakef
Differential Revision: D59685218
fbshipit-source-id: bac33402927f310bf867d2c47b4ebbb9276cf545
Summary:
Fixes: https://github.com/facebook/react-native/issues/43413
This pull request addresses an issue on Android where the text selection was not working when both `selectTextOnFocus` and `autoFocus` were set to true on TextInput.
`ReactTextInputManager` was calling `setSelectAllOnFocus` on `ReactEditText` before its onLayout is called causing text selection to not work on auto focus.
Changes Made
- Added logic to wait for the ReactEditText view's layout to be drawn before attempting to select the text.
On the first layout pass, the code now explicitly calls selectAll() to select the text.
- Implemented a check to ensure selectAll() is only called during the first layout pass, avoiding unnecessary calls on subsequent layout passes.
Impact
This change ensures that text selection is properly triggered when selectTextOnFocus and autoFocus are both enabled, improving the user experience and making text input behavior consistent and reliable.
## Changelog:
[ANDROID] [FIXED]: fixed select text on auto focus for TextInput
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45004
Test Plan:
| Before | After |
|--------|--------|
|  |  |
Reviewed By: javache
Differential Revision: D59448600
Pulled By: cortinico
fbshipit-source-id: 8a594d3193f227ba2d64b808d905bab8b3d24e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45407
This bumps to the latest minor of Gradle
Changelog:
[Android] [Changed] - Gradle to 8.9
Reviewed By: NickGerleman
Differential Revision: D59677575
fbshipit-source-id: 05b9afc6f32a9cd11461bc04522d1e522644867e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44845
## Design
- `NetworkIOAgent` is owned by the `HostAgent`.
- `NetworkIOAgent` is passed any CDP requests not handled by the `HostAgent` itself, and before delegating to `InstanceAgent`.
- It handles:
- [`Network.loadNetworkResource`](https://chromedevtools.github.io/devtools-protocol/tot/Network/#method-loadNetworkResource)
- [`IO.read`](https://chromedevtools.github.io/devtools-protocol/tot/IO/#method-read)
- [`IO.close`](https://chromedevtools.github.io/devtools-protocol/tot/IO/#method-close)
- `NetworkIOAgent.loadNetworkResource` creates a `Stream` corresponding to a single resource download/upload. A reference is held in a map `streams_` until an error, the agent is disconnected (destroyed) or it is discarded by the frontend with `IO.close`.
- `delegate.loadNetworkResource` is called with a `stream`-scoped executor, which it uses to call back with headers, data and errors.
- Callbacks for `IO.read` requests are held by the `Stream` until the incoming data is complete or enough data is available to fill the request (an implementation choice to optimise for fewest round trips). Any incoming data or error causes any pending requests to be rechecked.
{F1719616688}
## Unimplemented platforms
- Platforms may optionally implement `HostTargetDelegate.networkRequest` (as of this diff, none do). If they don't we report a CDP "not implemented" error, similar to the status quo where it was unimplemented by the C++ agent.
Changelog:
[General][Added] Debugging: implement common C++ layer of CDP `Network.loadNetworkResource`
Reviewed By: motiz88
Differential Revision: D54309633
fbshipit-source-id: 51e416e9d537b253f72693952d5fd520b6ae11b6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45384
changelog: [internal]
add a little more information to the mounting instructions block
Reviewed By: javache, rubennorte, mdvacca
Differential Revision: D59631537
fbshipit-source-id: 140ba1834172686998c51a9645ea1e66fff1879d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45398
Accidentally left in a value (that Phabricator then hid) which I was using to test fixed prerelease constants in D59141948... On real releases, this is overwritten by the version stamping process.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59668218
fbshipit-source-id: 3d04e52db75a5d8a53cf47d3a2f88b643030d94e
Summary:
This change factors out the Build HermesC for Linux job so that we can reuse the code in various workflows
## Changelog:
[Internal] - Factor out build-hermesc-linux for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45402
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59673895
Pulled By: cipolleschi
fbshipit-source-id: f5c680d523866442d25317e880b4803ac89c3741
Summary:
After `pod install`, it would set some empty flags, which seems useless. cc cipolleschi .

## Changelog:
[IOS] [FIXED] - Don't set empty string when remove ccache
Pull Request resolved: https://github.com/facebook/react-native/pull/45400
Test Plan: No empty flags should be set after we exec `pod install`.
Reviewed By: cortinico
Differential Revision: D59671357
Pulled By: cipolleschi
fbshipit-source-id: 26b55da9efaeed36876649cc27f09ecafaba412a
Summary:
In recent commits, some new targets have been added, and they are not exposed as prefabs, yet are used in e.g. `TextLayoutManager`. They are needed then for `react-native-live-markdown`: https://github.com/Expensify/react-native-live-markdown/pull/428/commits/c1611cd98ed5009fd66c871b9999b55941086af0
## 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
-->
[ANDROID] [ADDED] - expose prefabs for newly added targets
Pull Request resolved: https://github.com/facebook/react-native/pull/45386
Test Plan: It cannot be tested inside the repo, but try to build the `example` app with new arch enabled on `Android` in the `react-native-live-markdown` repo to see that those are needed.
Reviewed By: NickGerleman
Differential Revision: D59638801
Pulled By: cortinico
fbshipit-source-id: 3d09507d72a0c4d3dbb3a2a81b753625230a04a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45389
This undos a breaking change with ResourceDrawableIdHelper for Kotlin consumer.
I've re-added a `getInstance` method so that Kotlin libraries won't break.
The method is added as Deprecated as those libraries need to migrate to `.instance`
accessors as more idiomatic.
Changelog:
[Android] [Fixed] - Undo a breaking change with ResourceDrawableIdHelper.instance
Reviewed By: robhogan
Differential Revision: D59638043
fbshipit-source-id: ae2aab962e9a7676f0bfbae21f699e274502dc6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45390
This undos a breaking change with I18nUtil for Kotlin consumer.
I've re-added a `getInstance` method so that Kotlin libraries won't break.
The method is added as Deprecated as those libraries need to migrate to `.instance`
accessors as more idiomatic.
Changelog:
[Android] [Fixed] - Undo a breaking change with I18nUtil.instance
Reviewed By: alanleedev
Differential Revision: D59638044
fbshipit-source-id: 1c93a98676b5b01e89be3b974961c5f3ae919511
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45388
This undos a breaking change we're about to ship in 0.75, where Kotlin users
where forced to update this callsite to be `.getEntryIterator`.
This re-introduces a `entryIterator` val so both Kotlin and Java compatibility are retained.
Changelog:
[Android] [Fixed] - Undo breaking change for ReadableMap.entryIterator for Kotlin consumers
Reviewed By: alanleedev
Differential Revision: D59637925
fbshipit-source-id: b674df86e056f17791d9cabe28557529886f1c93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45378
Kotlin consumers of those APIs are forced with this breaking change:
```
# Before thanks to Java property conversion
Dynamic.type
# After
Dynamic.getType()
```
This restores the old more idiomatic API by moving those 2 funcitons to be vals.
Changelog:
[Android] [Fixed] - Undo breaking change on Dynamic.type and Dynamic.isNull
Reviewed By: javache
Differential Revision: D59631783
fbshipit-source-id: 8d720af34e104ee0e4f3120302a4a84fc17a7b1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45392
In this diff I'm introducing a new overload of Systrace.beginSection to receive arguments by parameter
changelog: [Android][Added] Introduce Systrace.beginSection with arguments
Reviewed By: sammy-SC
Differential Revision: D59639329
fbshipit-source-id: 23d43e5dd48fdde9c7d49a1c10fa9ecc4c3b7196
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45385
We ran various experiments with this flag, and this does not turn out to provide any significant benefits at this point to make it worth the complexity and platform divergence it introduced.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58355433
fbshipit-source-id: 4b857a5d0b8aa5915b4a880cbcae2526a16a08a9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45324
Improve concurrency during startup of bridgeless by concurrently initializing eager native modules and triggering bundle load.
Changelog: [Android][Changed] Modules marked with needsEagerInit = true will now be created on the mqt_native thread.
Reviewed By: mdvacca
Differential Revision: D59465977
fbshipit-source-id: 55cc0f0359bafcf32dc538f4346c6a5d5546f658
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45376
This reduces one breaking change users are seeing on `CatalystInstance.getJsCallInvokerHolder`.
I had to specify:
```
Suppress("INAPPLICABLE_JVM_NAME")
get:JvmName("getJSCallInvokerHolder")
```
as the Kotlin compiler is unhappy with me setting a JvmName on a interface property.
More on this here: https://youtrack.jetbrains.com/issue/KT-31420
Changelog:
[Android] [Fixed] - Undo breaking change on `CatalystInstance.getJsCallInvokerHolder`
Reviewed By: javache
Differential Revision: D59631640
fbshipit-source-id: 4d5b3499e4e0e0bec1d380c4b7942ea28ae35465
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45374
This change factors out the language standard in a separate constant so we can easily control it from a single place.
There are only 2 exception to this:
1. hermes-engine: the podspec is used in CI and it has no access to the rct_cxx_language_standard variable
2. Yoga: it can be used as a separate pod, outside of React Native, so it makes sense to leave it alone.
This change also fixes a problem where, in some setup, the language was set to C++14
## Changelog
[Internal] - Refactor Cxx language standard in a single constant
Reviewed By: dmytrorykun, blakef
Differential Revision: D59629061
fbshipit-source-id: 41eac64e47c14e239d8ee78bd88ea30af244d695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45322
Instead of using multiple weak_ptr and weak_ref, use a single weak_ref to the Java object and use that to get back to the original C++ instance, without the need for additional shared_ptr.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59465976
fbshipit-source-id: d410bdacf21a1886c6ed95d2c57ac8c6e17428e3
Summary:
Factor out the build-hermes-macos job to reuse the code
## Changelog:
[Internal] - Factor out build hermes macos action
Pull Request resolved: https://github.com/facebook/react-native/pull/45371
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D59627977
Pulled By: cipolleschi
fbshipit-source-id: 84226d8a2c036f816fa8ea949b467873a7eef37c
Summary:
Fixes: https://github.com/facebook/react-native/issues/45307
## Changelog:
[Android] [Fixed] - if `npx react-native-community/cli config` fails or timeouts proper error is shown and built is aborted, instead of leaving and empty autolinking.json
During build `npx react-native-community/cli config` is generated into autolinking.json. When command fails, we should error and should not leave and empty `autolinking.json`
Pull Request resolved: https://github.com/facebook/react-native/pull/45333
Test Plan:
Output of the reproducer in https://github.com/facebook/react-native/issues/45307 looks like this:
```log
android % ./gradlew assembleDebug
Starting a Gradle Daemon (subsequent builds will be faster)
ERROR: autolinkLibrariesFromCommand: Failed to create /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/build/generated/autolinking/autolinking.json - process npx react-native-community/cli config exited with error code: 126
FAILURE: Build failed with an exception.
* Where:
Settings file '/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/settings.gradle' line: 3
* What went wrong:
A problem occurred evaluating settings 'android'.
> ERROR: autolinkLibrariesFromCommand: Failed to create /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/build/generated/autolinking/autolinking.json - process npx react-native-community/cli config exited with error code: 126
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 10s
8 actionable tasks: 4 executed, 4 up-to-date
```
Output if you modify the package.json to be invalid looks like this:
```log
android % ./gradlew assembleDebug
ERROR: autolinkLibrariesFromCommand: process npx react-native-community/cli config exited with error code: 1
JSONError: JSON Error in /Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/package.json:
35 | "node": ">=18"
36 | },
> 37 | SOMETHING_NON_JSON
| ^
38 | "packageManager": "yarn@3.6.4",
39 | "resolutions": {
40 | "rtn-centered-text": "portal:../RTNCenteredText"
Unexpected token "S" (0x53) in JSON at position 1019 while parsing near "...ode\": \">=18\"\n },\n SOMETHING_NON_JSON\n ..."
35 | "node": ">=18"
36 | },
> 37 | SOMETHING_NON_JSON
| ^
38 | "packageManager": "yarn@3.6.4",
39 | "resolutions": {
40 | "rtn-centered-text": "portal:../RTNCenteredText"
at parseJson (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/parse-json/index.js:29:21)
at loadJson (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/loaders.js:48:16)
at #loadConfiguration (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:116:36)
at #loadConfigFileWithImports (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:87:54)
at #readConfiguration (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:84:82)
at search (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:50:63)
at emplace (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/util.js:36:20)
at ExplorerSync.search (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/ExplorerSync.js:78:42)
at getUserDefinedOptionsFromMetaConfig (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/index.js:32:37)
at mergeOptionsBase (/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/node_modules/react-native-community/cli-config/node_modules/cosmiconfig/dist/index.js:60:31)
FAILURE: Build failed with an exception.
* Where:
Settings file '/Users/boga/Work/OSS/RNMBGL/rn-fabric-boolattribute/ReproducerApp/android/settings.gradle' line: 3
* What went wrong:
A problem occurred evaluating settings 'android'.
> ERROR: autolinkLibrariesFromCommand: process npx react-native-community/cli config exited with error code: 1
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 2s
8 actionable tasks: 4 executed, 4 up-to-date
```
Reviewed By: cipolleschi
Differential Revision: D59582430
Pulled By: cortinico
fbshipit-source-id: bedb9563175cc5c46f5af80cf309769e56b803cc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45366
This updates ReactImageView to share the background drawing and clipping code used by other built-in components. This means manipulating a background drawable, and clippping at draw time, instead of using Fresco hierarchy background (in view foreground), and radii which manipulate the underlying bitmap.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D59495407
fbshipit-source-id: ce3c975e5ed323fa3d4610ec1515ef3c8dd8b2d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45356
Subview clipping was disabled for RTL on Android due to a bug where TextInputs automatically blur when selected. This bug is reintroduced when `set_android_layout_direction` is set.
When `set_android_layout_direction` is enabled, and we use View `getLayoutDirection()` instead of `I18nManager.isRTL()`, the layout direction is not known until layer in the mounting process. This defeats the check a `setRemoveClippedSubviews()` prop setter to ignore the prop if the view is RTL (since it doesn't invalidate when a new layout direction is set).
The root cause of the underlying RTL bug is due to updating clipping status triggered by `onSizeChanged()`, which is called before `onLayout()`, where `ReactHorizontalScrollContainerView` offsets content in RTL. This also seems potentially erroneous, as we do not update the clipping rect on position change (unless that is handled elsewhere).
I moved the check to `onLayout()`, called after ReactHorizontalScrollView will change metrics, which seems to fix the issue. I then removed the exclusion in `removeClippedSubviews` prop setter.
Changelog:
[Android][Fixed] - Fix Android removeClippedSubviews in RTL
Reviewed By: mdvacca
Differential Revision: D59566611
fbshipit-source-id: a2eb12b984dc78940756804b6b7a3950377af9de
Summary:
When setting a shadow on a `Text` inside a `TextInput`, the shadow was rendered with artifacts when `backgroundColor` was set on the `TextInput`.
This is caused by how attributed strings are constructed on the new architecture - all text attributes from the text input (including background color) are propagated onto the string. Then, it's converted to a `Spannable` on Android side, which includes `ReactBackgroundColorSpan` being set on the entire text when it doesn't have a background color set explicitly. Then Android tries to render the shadow not only for the text but also for the background rect which results in the artifacts.
This PR prevents background color from the `TextInput` from being propagated onto the attributed string, so the `ReactBackgroundColorSpan` is only applied when a text fragment has its background set explicitly.
## Changelog:
[ANDROID] [FIXED] - Fixed text shadow rendering with artifacts when `backgroundColor` was set on the `TextInput`
Pull Request resolved: https://github.com/facebook/react-native/pull/45343
Test Plan:
Checked relevant examples on RNTester
|Old arch|New arch (before)|New arch (after)|
|-|-|-|
|<img width="436" alt="Screenshot 2024-07-09 at 14 44 52" src="https://github.com/facebook/react-native/assets/21055725/64005ec4-3e42-4327-9b09-f57d3c477fb6">|<img width="436" alt="Screenshot 2024-07-09 at 14 43 03" src="https://github.com/facebook/react-native/assets/21055725/f558ad26-08de-4231-acdf-92f596ec186c">|<img width="436" alt="Screenshot 2024-07-09 at 14 41 46" src="https://github.com/facebook/react-native/assets/21055725/6b4ff6ed-5267-4f1a-a895-1bbd760f73e5">|
Reviewed By: NickGerleman
Differential Revision: D59527817
Pulled By: cortinico
fbshipit-source-id: d03d4749e4435ef04e51b1018f046be0e5e0bca4
Summary:
Factor out build-apple-slices-hermes to a seprate action to reuse code
## Changelog:
[Internal] - Refactor the CI to reuse code
Pull Request resolved: https://github.com/facebook/react-native/pull/45359
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59575467
Pulled By: cipolleschi
fbshipit-source-id: 5d253f3dd523cb70b768c62db10fb7ff39fbd49f
Summary:
This PR updates the comments for `~ShadowNodeWrapper()` and `~ShadowNodeListWrapper()` to align them with the actual implementation that now uses `jsi::NativeState` instead of `jsi::HostObject`.
## Changelog:
[GENERAL] [FIXED] - Updated comments for `~ShadowNodeWrapper()` and `~ShadowNodeListWrapper()`
Pull Request resolved: https://github.com/facebook/react-native/pull/45357
Reviewed By: sammy-SC
Differential Revision: D59578988
Pulled By: javache
fbshipit-source-id: 1c46ce8407fc8b337f3a6762caee3b2e0e1edfc6
Summary:
Factor out the action to build hermesc for apple platform so we can reuse it across jobs
## Changelog:
[Internal] - Factor out hermesC apple to reuse code
Pull Request resolved: https://github.com/facebook/react-native/pull/45346
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D59521564
Pulled By: cipolleschi
fbshipit-source-id: c99966e314b3d418d1d83d653c0be68b2931b03b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45348
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59525418
fbshipit-source-id: 094b7c9c952d8684e24203cc07d6bda51bdf12b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45352
We claim that we will never draw multiple elements on top of each other, which isn't correct when we have a background.
We should claim that we can draw overlapping elements if we have a background drawable which we place in the Drawee hierarchy (part of the ImageView foreground drawable), or if the underlying view has a background drawable (which is handled by `ImageView` superclass `hasOverlappingRendering()`).
The effect of this is subtle, and just means that we get correct compositing when an opacity is set on image with background.
Changelog:
[Android][Fixed] - Fix ReactImageView.hasOverlappingRendering()
Reviewed By: mdvacca
Differential Revision: D59489788
fbshipit-source-id: fe2922f064b91f1709ed546dd647d4d4112d04c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45338
`CSSBackgroundDrawable` is a silly goose and reuses layout types to store color. This has extended into a really strange public API, where we use floating point colors, where the color is itself in int with packed integer color components.
This hides that away, and marks some classes with `UnstableReactNativeAPI` that I plan to hide shortly.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59488811
fbshipit-source-id: 7dc57edc9888f8a92088d2410ee71c2768ae8ec1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45169
This is a follow-up to D56280451 where I made all SystraceSection calls feed into the Instruments signposts API. This will additionally do the same for all calls to nativeTraceBeginSection/nativeTraceEndSection from JSITracing.cpp.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D58895740
fbshipit-source-id: ee1cdff883ac1172f9bafe11ab950738d7ae7f82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45336
The spec says we need to adjust the border radius of the shadow if spread is present. It gets bigger for outset shadows and smaller for inset shadows.
Source https://drafts.csswg.org/css-backgrounds/#shadow-shape
> To preserve the box’s shape when spread is applied, the corner radii of the shadow are also increased (decreased, for inner shadows) from the border-box (padding-box) radii by adding (subtracting) the spread distance (and flooring at zero). However, in order to create a sharper corner when the border radius is small (and thus ensure continuity between round and sharp corners), when the border radius is less than the spread distance (or in the case of an inner shadow, less than the absolute value of a negative spread distance), the spread distance is first multiplied by the proportion 1 + (r-1)3, where r is the ratio of the border radius to the spread distance, in calculating the corner radii of the spread shadow shape.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59296120
fbshipit-source-id: e55327701547f27961a0d612ed595b4383e1d763
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45340
flattenStyle may return an object which is already frozen (in development), so it is incorrect to further mutate this.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59515063
fbshipit-source-id: 92df158d5841988d40bcd76b861963b06dad1573
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45323
We're no longer running experiments with TurboModule and legacy module rollout, so this debug info is no longer required, and adds unnecessary verbosity to TurboModule lookup errors.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59465974
fbshipit-source-id: 87a2ebd9c05ad312889bcbd819ccbe885b429064
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45320
TurboModule should be the default path, and we should only fallback to the legacy native modules if we can't find a module through the TurboModule mechanism.
Changelog: [General][Changed] - TurboModules will be looked up as TurboModules first, and fallback to legacy modules after.
Reviewed By: christophpurrer
Differential Revision: D59465978
fbshipit-source-id: c5672d34e90dcee321de0a5acd3a50b6bb1092b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45330
changelog: [internal]
With view preallocation, we want to trigger image download in case there is only a single image source even if layout hasn't been determined.
This can lead to images appearing 100s of milliseconds earlier.
This optimisation is already used by plain ImageView: https://fburl.com/code/cp87xmw7
Reviewed By: rubennorte
Differential Revision: D59465972
fbshipit-source-id: e045d6bd9d595d366541ffa32364488be4766ef8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45319
This test has been cleaned up, we can remove the callers.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D59465975
fbshipit-source-id: 01f4b24f221aa017fbfd2238f81454d38d05920a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45325
We don't want to lose this context when we cleanup the old architecture.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D59466876
fbshipit-source-id: 3cf3c63d619d9e8535e369ec1ef7c5706431b85d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45317
changelog: [internal]
ship optimized version of Text componant. In local benchmarking this version shows 35% improvement over old Text component.
Reviewed By: NickGerleman
Differential Revision: D59460871
fbshipit-source-id: c3a41d3aac4cd40e054b669d56295bcb631d8310
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45331
Let's add the a new JSRuntime API to register the thread. This allows Hermes sampling to correctly work in Bridgeless/Activity.
## Changelog:
[General][Added] - Add experimental api to JSRuntimeFactory to initialize runtime on js thread
Reviewed By: RSNara
Differential Revision: D58787655
fbshipit-source-id: 2202271b9ad88cf8ba2145fb4e9e7bfd6e0c09fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45329
Thanks to [#45232](https://github.com/facebook/react-native/issues/45232) we found a bug in the interop layer, where we were not passing the BridgeProxy in bridgeless mode to the view managers.
This Change should fix that issue.
## Changelog:
[iOS][Fixed] - Make sure to pass the RCTBridgeProxy to ViewManagers
Reviewed By: dmytrorykun
Differential Revision: D59468292
fbshipit-source-id: 00666be21385a735878eb567c4b8a0986c609c5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45328
This assertion is currently not actionable since the stack trace will always be just `mCreateReactContextThread`. Moving this assert is safe, as the only other place we write it is also the UI thread.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59467576
fbshipit-source-id: c4606672255149a202f99a8f787230e2a23a868a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45321
Changelog: [internal]
This creates a variant of the internal hook in `TextInput` that handles the synchronization of the state between native and JS. The new variant moves everything that's not needed for rendering to refs instead of state.
One of the reasons for this change is that by not setting state in layout effects, we're not forcing passive effects to be flushed synchronously, which can improve perceived performance (as we can start painting before passive effects are executed).
Reviewed By: sammy-SC
Differential Revision: D59400624
fbshipit-source-id: 540c20daf49919fbfabd357a1a057ca126ec6b03
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45315
Changelog: [internal]
This moves some logic from the `TextInput` component to its own hook. It's just a refactor in preparation for a following change were we're going to test replacing this hook with an alternative version that relies less on state (using refs for some things instead).
Reviewed By: sammy-SC
Differential Revision: D59400614
fbshipit-source-id: ea37b8514f89e94be1386774ad70d56389878886
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45318
I'm setting the Gradle cache to write-only for build_android on main/stable branches.
This is so we start from a fresh cache on those jobs (as they're not on the critical path for developers).
Changelog:
[Internal] [Changed] - Attempt to limit the Gradle cache size
Reviewed By: cipolleschi
Differential Revision: D59466459
fbshipit-source-id: 8b7936ebe053ae06256f8506093eb17c07219de9
Summary:
This PR removes usage of deprecated `statusBarFrame` method in `RCTPerfMonitor` . Instead `RCTPerfMonitor` now uses `safeAreaInsets` which also fixes issue causing Perf Monitor to appear under corner in landscape mode on e.g. `iPhone 15 Pro`. It also fixes initial position of expanded state which was causing it to render under notch.
Also removed duplicate background color setting
## Changelog:
[IOS] [REMOVED] - Remove usage of deprecated statusBarFrame method
[IOS] [FIXED] - Fix position of RCTPerfMonitor in landscape mode & expanded mode
Pull Request resolved: https://github.com/facebook/react-native/pull/43058
Test Plan: `RNTester` builds and runs successfully, `RCTPerfMonitor` works and displays correctly
Reviewed By: dmytrorykun
Differential Revision: D59116913
Pulled By: cipolleschi
fbshipit-source-id: 0ff61f61b206c530cfb9e471bc2dc33a0a43c833
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45303
`ViewManagersPropertyCache` uses reflection to find all ReactProp but fails when any symbols in the method refer to classes not available in the current build.
Work around this by extracting this helper to a separate private inner class.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59397865
fbshipit-source-id: e77d3167698e4311e8778ebab28a0c8a0d2666c2
Summary:
To fix [The Memory Leak Issue](https://github.com/facebook/react-native/issues/45080) This change modifies the timing of view creation in the LogModule. The motivation behind this update is to address a potential memory leak issue. Previously, views were being created and held onto, which could lead to references to the Activity being retained even when they were no longer needed. By creating the view only when the show method is called and ensuring it is removed in the hide method, we can prevent these memory leaks and improve the overall memory management and stability of the LogModule.
Fixes https://github.com/facebook/react-native/issues/45080
- Adjusted the timing of view creation to occur when the `show` method is called.
- Ensured that the created view can be removed in the `hide` method.
- This update addresses potential memory leaks by preventing the view from holding a reference to the Activity.
These changes improve memory management and stability within the LogModule.
Modify the timing of view creation in LogModule. The view is now created when the show method is called, and it can be removed in the hide method. This change resolves potential memory leaks caused by the view holding a reference to the Activity.
## Changelog:
[ANDROID] [FIXED] - Fix LogModule to create view when show is called
Pull Request resolved: https://github.com/facebook/react-native/pull/45261
Reviewed By: dmytrorykun
Differential Revision: D59372962
Pulled By: cortinico
fbshipit-source-id: 6693afdb279c7164ff0f68c93f8ca8a54b1c2077
Summary:
In https://github.com/facebook/react-native/issues/44483 `If-None-Match` request failed to get a 304 after a 200 response. This is caused by NSRequest's
cachePolicy which prevents sending a request to server to check 304 state and return directly a 200 response.
## Changelog:
[IOS] [FIXED] - fix: on iOS not getting 304 from `If-None-Match` request
Pull Request resolved: https://github.com/facebook/react-native/pull/45263
Test Plan: repeat request given in https://github.com/facebook/react-native/issues/44483
Reviewed By: cortinico
Differential Revision: D59364609
Pulled By: dmytrorykun
fbshipit-source-id: 2a8b86c526320a1e9c1c58e41aa9c74beeeac2ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45287
Fixes https://github.com/facebook/react-native/issues/45277
This fixes an NPE reported in OSS if you do this call in JavaScript:
```
const fr = new FileReader();
fr.readAsText({});
```
Changelog:
[Android] [Fixed] - Fix NPE in FileReaderModule
Reviewed By: dmytrorykun
Differential Revision: D59372620
fbshipit-source-id: ad5073376eaa26852c8277bdbb7d76b1aa480b3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45295
When registering Babel to run RN from source, we currently call `babel/register` directly from `scripts/babel-register.js`.
This has the effect of overwriting any previous registration, which causes problems in the FB monorepo because RN also loads other projects that lie outside this registration (like Metro) from source - possibly requiring different configurations.
Moreover, if Metro is subsequently loaded from source, its own registration clobbers RN's.
Instead, this diff runs the registration through `metro-babel-register`, which maintains a cumulative list of registration directories and applies a uniform transform.
Note that this means we're not using exactly the same transform at build/publish time as for running from source - to fix that, we ought to move everything to a central `babel.config.js`, but that's a much bigger change, and this gets us close enough to unblock.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59376984
fbshipit-source-id: 0dbb00970ac87dbe40ec8904bf51ef4b1fee5e0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45294
Just doing some cleanup here as those exports are scattered around this file.
Changelog:
[Internal] [Changed] - Cleanup exports for PressableExample in RN-Tester
Reviewed By: yungsters
Differential Revision: D59376617
fbshipit-source-id: 0f6f81fca7b5cbcdc05bbb6a1f87d3ad74c20b50
Summary:
This PR restores the virtual destructor for `ShadowNodeWrapper` which was added in https://github.com/facebook/react-native/pull/33500 and unfortunately removed in https://github.com/facebook/react-native/pull/40864.
The virtual destructor here serves as a key function. Without a key function, `obj.hasNativeState<ShadowNodeWrapper>(rt)` **does not** work correctly between shared library boundaries on Android and always returns false.
We need this pretty badly in third-party libraries like react-native-reanimated or react-native-gesture-handler.
## 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
-->
[ANDROID] [FIXED] - Fix dynamic_cast (RTTI) for ShadowNodeWrapper when accessed by third-party libraries again
Pull Request resolved: https://github.com/facebook/react-native/pull/45290
Test Plan: This patch fixes an issue in Reanimated's fabric-example app.
Reviewed By: fabriziocucci
Differential Revision: D59375554
Pulled By: javache
fbshipit-source-id: 09f3eda89a67c26d6dacca3428e08d1b7138d350
Summary:
[`querystring`](https://www.npmjs.com/package/querystring) package is deprecated. In this Pull Request I've replaced usage of `querystring` with `URLSearchParam` what is recommended by Node.js.
It's also causing a warning when installing dependencies inside a React Native app:
```
warning react-native > react-native/community-cli-plugin > querystring@0.2.1: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
```
## Changelog:
[INTERNAL] [FIXED] - Replace `querystring` package with `URLSearchParam`
Pull Request resolved: https://github.com/facebook/react-native/pull/45125
Test Plan:
Params should be parsed in the same way and warning shouldn't be presented.
js1 jest xplat/js/tools/metro/packages/metro/src/cli/__tests__/parseKeyValueParamArray-test.js
Reviewed By: cipolleschi
Differential Revision: D58948498
Pulled By: GijsWeterings
fbshipit-source-id: 79b1f7b3feae230d2d3641205c513b98b3fda511
Summary:
We do have a mixture of casing in the custom GH actions in our repo.
This aligns them all to be `kebab-case`
## Changelog:
[INTERNAL] - Aling all custom actions to kebab-case
Pull Request resolved: https://github.com/facebook/react-native/pull/45286
Test Plan: CI
Reviewed By: blakef
Differential Revision: D59374046
Pulled By: cortinico
fbshipit-source-id: 030a9323e501e375585e90f10a3b29c3bb671b28
Summary:
Changes `.npmignore` file to only exclude the `ReactAndroid/build` directory instead of all `build` directories under `ReactAndroid` (which included the `ReactAndroid/src/main/java/com/facebook/react/common/build` package). This problem was caused by the newer version of NPM being used.
Closes https://github.com/facebook/react-native/issues/45204
## Changelog:
[ANDROID] [FIXED] - Fixed build from source failing due to a missing file
Pull Request resolved: https://github.com/facebook/react-native/pull/45279
Test Plan:
Run `npm pack` or `npm publish -dry-run`.
Before this change it includes 3774 files in the package and `ReactBuildConfig` isn't included. After this change it includes 3775 files in the package and `ReactBuildConfig` is included.
Reviewed By: javache
Differential Revision: D59371555
Pulled By: cortinico
fbshipit-source-id: f54f1e88e30429d538b9e160e6ce20d994c5d1b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45269
There's no callers to this property, and we already create a `jsRuntimeFactory` above in DefaultReactHost, which will actually decide which VM to use.
Changelog: [Android][Removed] Unused jsEngineResolutionAlgorithm from ReactHost
Reviewed By: cortinico
Differential Revision: D59333435
fbshipit-source-id: 21be4d138bca64c0cb78de366bf2e247b4f37650
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45053
Add support for most keyword values of mix-blend-mode on Android
Missing compositing operators and global values
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58752052
fbshipit-source-id: e63e01d45a7e0924f3853f08dff5cec7e2f1ceaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45256
The actual stamped versions here are all strings.
Android interface for constants is untyped, and we always return a string here. iOS, we will try to parse the string into a double, which will fail for every prerelease version RN has ever published.
Platform on Windows seems to uniquely be doing the right thing.
Changelog:
[General][Fixed] - Fix Platform.constants.reactNativeVersion type
Reviewed By: robhogan, necolas
Differential Revision: D59141948
fbshipit-source-id: 9c758e5eb8796b03197258d87ec06b31018e211c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45250
Adds and implements a new `appDisplayName` field as part of `HostTargetMetadata` and the `ReactNativeApplication.metadataUpdated` CDP event.
This will be used to display the app display name in the debugger frontend.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D59273360
fbshipit-source-id: d770cccadb520b9c13c7288cd690df21683d2cc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45249
Follows D58288489, D58415181.
Implements the remaining `HostTargetMetadata` fields, sent by the debugger on `ReactNativeApplication.metadataUpdated`, on **Android Bridgeless**.
This will be used to display details such as the app name and React Native version in the debugger frontend.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59271755
fbshipit-source-id: a2488fed98df0800ec0a611d2317cd40cd809aac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45234
Follows D58288489.
Implements the remaining `HostTargetMetadata` fields, sent by the debugger on `ReactNativeApplication.metadataUpdated`, on **Android Bridge** (Bridgeless to follow).
This will be used to display details such as the app name and React Native version in the debugger frontend.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58415181
fbshipit-source-id: 8aca707c0b9f6e933ac5e5b4ac47ba8d48e99241
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45258
Setting this to false, then removing, will not reset back to default state of `true`. Add explicit defaults so that the absence of the prop will lead to scroll indicators always being shown.
Changelog:
[Android][Fixed] - Fix default for `showsHorizontalScrollIndicator` and `showsVerticalScrollIndicator`
Reviewed By: javache
Differential Revision: D59285745
fbshipit-source-id: 6a7c204cfe9c4ab9e4efbbda300cdfdaf57e8f37
Summary:
Fix entails using non-synthesized getter, such that underlying backing is an std::atomic<RCTNetworkTaskStatus>.
In the greater scheme of things, I believe `RCTNetworkTask` should be improved as it has several `nonatomic` properties that are read and written to on different threads. Thread safety of this class seems to have been addressed on a per property basis, judging from the employment of `std::mutex` elsewhere in the implementation.
This is an attempt at fixing https://github.com/facebook/react-native/issues/44687.
## Changelog:
[iOS][FIXED] - Fix data race related to access on `RCTNetworkTask.status`.
Pull Request resolved: https://github.com/facebook/react-native/pull/44694
Test Plan: Added unit test in class `RCTNetworkTaskTests`.
Reviewed By: cortinico
Differential Revision: D59217353
Pulled By: javache
fbshipit-source-id: 1af77238ddd99db21e2e53f174a81e207d5832b2
Summary:
This migrates `analyse_code` to GHA into a single job called `lint`.
## Changelog:
[INTERNAL] - Migrate analyse_code to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45247
Test Plan: CI
Reviewed By: NickGerleman
Differential Revision: D59283393
Pulled By: cortinico
fbshipit-source-id: dcdc4828a551062b3706e6450614b8c94e1a7e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45264
Changelog: [internal]
We added a flag to fix some issues when committing state updates synchronously from the main thread in https://github.com/facebook/react-native/pull/44015 but that implementation was incorrectly not invoking item dispatch listeners after mount.
This adds the missing logic so we can unblock shipping sync state updates.
Reviewed By: javache
Differential Revision: D59319230
fbshipit-source-id: b0ab7e7c79a3315ef29dbb024e62c10444192509
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45240
X-link: https://github.com/facebook/yoga/pull/1675
There was a bug where some crash would happen if a tree was cloned that had static/absolute parent/child pair inside it. This was because we were no longer calling `cloneChildrenIfNeeded` on the static parent, but would still layout the absolute child. So that child's owner would be stale and have new layout. In React Native this would lead to a failed assert which causes the crash.
The fix here is to clone the children of static nodes during `layoutAbsoluteDescendants` so that we guarantee the node is either cloned if it is going to have new layout.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59175629
fbshipit-source-id: 4d110a08ba5368704327d5ab69a8695b28e746f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45242
tsia, comments should explain how this works but tldr is
* Set up cropping region to only draw within the view's bounds
* Draw 2 offscreen rects to cast the shadow. One represents the bounds of the original view, the other represents the clear region. Fill these rects with EO fill algo so the intersection is clear. The disjoint will be colored and cast a shadow.
* Do that for each shadow in reverse order
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: lenaic
Differential Revision: D58885576
fbshipit-source-id: 2f3a5de75e93c7d34676128bbddbe38d64f1fb59
Summary:
tisa. Algo is
* Draw offscreen rect the size of the outset shadow (so accounting for spread)
* Set g state to cast shadow in proper place ON screen
* Clear out region in view
The rects need to be offscreen for the following reasons
* We need to account for spread radius, and CGContext shadows do not have support for this. So the only way to create a bigger shadow is the create a path that is the same size as the shadow we want
* We cannot just position this rect onscreen with no offset (so the shadow is casting directly under it) since the blur will look unnatural
* Offscreen means we do not see filled shadow rect but we do see the shadow it casts by offsetting it in the proper location
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D58881588
fbshipit-source-id: 2ea1b8945a3b9f182c4fb11668ac91a0ae7846ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44882
tsia, nothing too fancy here. Just taking the box shadows from raw props and throwing them into a struct so we can read it.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: NickGerleman
Differential Revision: D57617028
fbshipit-source-id: 29cf683b663b4903721d674efbf61a200eaf3a64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45237
Changelog: [internal]
This creates a feature flag to test a fix for an incorrect state update dispatched to Fabric when using smooth scroll animations.
Specifically, when starting a smooth scroll animation from X to Y, the scroll view would set the state to Y, and then all the range from X to Y again. For example, the sequence of state updates when smooth scrolling from 0 to 5 would be `0 -> 5 -> 1 -> 2 -> 3 -> 4 -> 5`, which is obviously incorrect.
This flag prevents setting the final value before it's actually reached.
Reviewed By: javache
Differential Revision: D59233069
fbshipit-source-id: 221602d7d30635070e7776ce756e2ef438edf638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45236
Changelog: [internal]
## Context
We're currently observing inconsistencies between the state of the UI on Android and the propagated state in Fabric.
When investigating the issue, we saw that there are some state updates that were going to be dispatched from scroll views to Fabric were skipped because the state object in native was deallocated.
The reason for that is a race condition between:
1. Dispatching new state updates from the UI thread
2. Updating the state previously dispatched from the UI thread on the JS thread.
{F1735383134}
## Changes
This creates a new feature flag to replace the weak reference with a strong one, so when the previous state is deallocated we can still access it to set new state.
The use of weak references was introduced in D44472121 to avoid holding onto JSI references (which could be contained in the state) when the runtime was deallocated, but we later introduced an explicit clean up mechanism in D45905628 that would make that unnecessary.
Reviewed By: javache
Differential Revision: D59233070
fbshipit-source-id: 018d8935f506430ecab96df0f7a998a37ee0f556
Summary:
This migrates the `test_js` workflow to GHA
## Changelog:
[INTERNAL] - Migrate test_js to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/45246
Test Plan: Will wait for CI
Reviewed By: javache
Differential Revision: D59270333
Pulled By: cortinico
fbshipit-source-id: e77eb9819e0819638c51e61b1e477ac04680a2f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45233
We want the Gradle cache to be written only on main/-stable branches run, and only for jobs with `cache-read-only` == false (i.e. `build_android`).
This changes implements it.
Changelog:
[Internal] [Changed] - Further refine the Gradle caching logic.
Reviewed By: blakef
Differential Revision: D59225944
fbshipit-source-id: b6c3a5d4d0d399d6fe42287976925c43f3f12eb7
Summary:
Adds changelog for the 0.74.3 patch.
## 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] [Changed] - Add 0.74.3 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/45238
Reviewed By: cortinico
Differential Revision: D59263876
Pulled By: dmytrorykun
fbshipit-source-id: 0f16d51a01790b4ddcaca092dec7527aab386dcd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44914
Shows a proof of concept how '*strongly typed Turbo Module scoped*' `EventEmitters` can be used in a ObjC Turbo Module.
## Changelog:
[iOS] [Added] - Add ObjC Turbo Module Event Emitter example
Reviewed By: rshest
Differential Revision: D57650830
fbshipit-source-id: c5c2dee4766484e9e58415e33c084999a9ae3bc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45218
Noticed that when an exception occurred we would not cleanup global_refs, leaking them in the global table.
Restructure this to use RAII and rely on JNIArgs to do the cleanup as necessary.
Changelog: [Android][Internal]
Reviewed By: RSNara
Differential Revision: D59156494
fbshipit-source-id: c89552d72387bad2a120373e78a2c545415a7c82
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45207
These are their own shared library, and their own soloader-call, but they can easily be pulled into existing targets without causing excessive bloat.
Changelog: [Android][Removed] react_newarchdefaults is no longer a prefab, instead use fabricjni
Reviewed By: christophpurrer
Differential Revision: D59107105
fbshipit-source-id: fb3b25f3ce4511aa18126477f2beefe1292c6d09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45231
Following up to cipolleschi's work, it turns out that me setting this command inside
the docker file for React Android is unneffective:
https://github.com/react-native-community/docker-android/pull/228
The reason is that the user executing is different (1001 for the Dockerfile, while GHA executes as root 1000).
So we need to set this, otherwise the nightlies will be invoked with the `-TEMP` prefix:
Changelog:
[Internal] [Changed] - Setup `git config --global --add safe.directory '*'` when running jobs inside Docker
Reviewed By: blakef
Differential Revision: D59223862
fbshipit-source-id: 26674fc8cdaebf6687407072cc4e4f5c38246845
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45205
We only need a static register method, which includes the core components and the provider function. CoreComponentsRegistry isn't referenced at all in Kotlin/Java, and can be replaced with DefaultComponentsRegistry with no change in behaviour in all scenarios.
Changelog: [Android][Removed] CoreComponentsRegistry is now fully replaced by DefaultComponentRegistry.
Reviewed By: cortinico
Differential Revision: D59107106
fbshipit-source-id: e679be490f43dab52eb5e11a08aa9d0ae2a89a92
Summary:
Fixes https://github.com/facebook/react-native/issues/45222
## Changelog:
[ANDROID] [FIXED] - Fix autolink plugin for libraries that are platform-specific
Pull Request resolved: https://github.com/facebook/react-native/pull/45223
Test Plan: And a library that does not have Android native code such as react-native-segmented-control/segmented-control and sync gradle
Reviewed By: rshest
Differential Revision: D59221562
Pulled By: cortinico
fbshipit-source-id: 55739d63ded63e46897d0d770281f937668c1f50
Summary:
Users are reporting that RN 0.75 is crashing due to us attempting to accessing a static method
on `AndroidUnicodeUtils.convertToCase` which is not static anymore due to Kotlin conversion.
Static access is inside Hermes codebase here:
https://github.com/facebook/hermes/blob/f5c867514c71b25212eb3039230e0c095518b532/lib/Platform/Unicode/PlatformUnicodeJava.cpp#L107-L109
Changelog:
[Android] [Fixed] - Fix crash due to missing JvmStatic to `convertToCase`
Reviewed By: javache
Differential Revision: D59218291
fbshipit-source-id: ac121a8bcd5fd917ee134d257f967c8e3e338ca5
Summary:
Use the hard-coded config for Helloworld instead of assuming the community cli is there to generate a config, which we can no longer assume.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45221
Test Plan:
This works in my local environment:
```
bundle exec pod install
```
and
```
./gradlew generateAutolinkingPackageList
```
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59162715
Pulled By: blakef
fbshipit-source-id: 95ff2c3929f12ee0ecf468cb80d2df1281eb746e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44906
Shows a proof of concept how '*strongly typed Turbo Module scoped*' `EventEmitters` can be used in a Java Turbo Module.
## Changelog:
[Android] [Added] - Add Java Turbo Module Event Emitter example
Reviewed By: javache
Differential Revision: D57530807
fbshipit-source-id: 04261d8885760f0e3b3c8c1931e0d56a5d33a0df
Summary:
The fix entails making `AllocationTestModule.valid` an Objective-C atomic property and funneling access to the ivar via the synthesized property getter and setter.
While the data race was present in test code, it would make it more difficult to spot more severe data races with the TSan. Also, getting rid of a data race is always good.
## Changelog:
[iOS][Fixed] - Data race related to access of `AllocationTestModule.valid`
Pull Request resolved: https://github.com/facebook/react-native/pull/45191
Test Plan: `RCTAllocationTests` will test the implementation of `AllocationTestModule`.
Reviewed By: christophpurrer
Differential Revision: D59155083
Pulled By: javache
fbshipit-source-id: e3217cffd0801377a25f04bf8ed0b4e2d1d88498
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44928
The react-native-community/ dependencies aren't being explicitly included as part of the Framworks (RFC-0759) work.
Changelog: [General][Breaking] react-native isn't dependend on react-native-community/*
WARNING: Do not commit until we've cut 0.75, this goes in the 0.76 release only otherwise it'll break `npx react-native@latest init`.
Reviewed By: cortinico
Differential Revision: D58528447
fbshipit-source-id: f238e621c47df9e28b2e18f4137eb08e525052f6
Summary:
In order to fix the data races described in https://github.com/facebook/react-native/issues/44715, I propose a simple solution by leveraging shared counter functions wherein `std::atomic` is the backing for the integer values.
## Changelog:
[iOS] [Fixed] - Implement shared atomic counters and replace static integers in `RCTImageLoader` and `RCTNetworkTask` that were accessed concurrently, which in some cases lead to data races.
Pull Request resolved: https://github.com/facebook/react-native/pull/45114
Test Plan: Added unit tests for the counters in `RCTSharedCounterTests`.
Reviewed By: cipolleschi
Differential Revision: D59155076
Pulled By: javache
fbshipit-source-id: f73afce6a816ad3226ed8c123cb2ccf4183549a0
Summary:
Having React Native support every Apple platform is tough to achieve as it introduces many platform-specific ifdefs.
On the other side, maintaining an OOT platform fork is already a demanding job, so to make it easier I propose adding ifdefs for iOS-specific code. Thanks to this change, OOT platforms can focus on their OS-specific features while the core is also adding iOS-specific features behind ifdefs. Fortunately, **most of the code on Apple platforms can be shared** and this PR aims to introduce better support for this and to minimize OOT fork's surface.
In this example `RCTDeviceInfo.mm` has support for handling orientation changes and the availability of this feature across Apple OS looks as follows:
| Platform | Support |
| ------------- | ------------- |
| macOS | ❌ |
| tvOS | ❌ |
| visionOS | ❌ |
| iOS/iPadOS | ✅ |
Here is a table from `TargetConditionals.h` header file which shows the coverage of `TARGET_OS_IOS` macro. (It supports both iOS and iPadOS)

## 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] [ADDED] - Conditionals for iOS only code in RCTDeviceInfo.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/45176
Test Plan: CI Green
Reviewed By: christophpurrer
Differential Revision: D59106103
Pulled By: cipolleschi
fbshipit-source-id: 594a9d2451024baddfbc9cd3bc1ccfb8829fc31c
Summary:
This PR fixes rendering of `RCTRedBoxExtraData`
I noticed that it wasn't displaying the `reload` and `dismiss` buttons, which made it impossible to close modal and to reload JS on e.g. `visionOS` (on `iOS` it could only be closed by swiping).
PR adds these buttons back and also introduces some refactoring
Before & After:
<img width="1118" alt="pr-img" src="https://github.com/facebook/react-native/assets/56474758/50e22499-9df0-45f0-84ac-2118ab7a8e6c">
## Changelog:
[IOS] [FIXED] - Fix rendering `RCTRedBoxExtraData`
Pull Request resolved: https://github.com/facebook/react-native/pull/43102
Test Plan: Make sure that `RCTRedBoxExtraData` displays and works as expected
Reviewed By: dmytrorykun
Differential Revision: D59108365
Pulled By: cipolleschi
fbshipit-source-id: b88c5665962d0280d68377863aa3346edfdf86b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45197
With React 19, `forwardRef` is no longer necessary because `ref` is available on props. However, this only holds true for functional components — not class components.
This eliminates the `forwardRef` invocation in `ScrollView`, while retaining the wrapper component to map `ref` to `scrollViewRef` for the class component. For now...
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59091873
fbshipit-source-id: 60afcd441aec82fa050738b5c09083f3a26378d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45203
Configures a `REACT_NATIVE_ENABLE_FUSEBOX_DEBUG` flag, and exposes this flag in the Buck target via a [constraint setting](https://www.internalfb.com/intern/wiki/Buck-users/select-and-friends/#constraint-setting-and-c). This is an additional hook to enable the new debugger stack (codename Fusebox) as part of our internal rollout.
NOTE: This approach replaces D59014161 (reverted).
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59109110
fbshipit-source-id: 7d23d9d402569b00d8dd17b9c8f3bcc108f0365f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45151
This change was missed when fixing hue-rotate and adding drop-shadow. I believe the only issue with this was stacking context was not being created for these two filters.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58965245
fbshipit-source-id: e6bfdb738a8bc8caa878f60420cfe8b421f64aa4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45161
This is part of a bigger refactoring of the Android pipelines.
As `build_android` is already building everything, let's save the maven-local
so it can be reused by other jobs (test_android_helloworld and build_npm_package).
Changelog:
[Internal] [Changed] - Let build_android produce a signed maven-local.zip archive
Reviewed By: cipolleschi, blakef
Differential Revision: D59002893
fbshipit-source-id: db03946c975b2ce91dae0c4011981b2fe9dd6113
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45133
Recently, CircleCI has failed pretty often due to these tests.
The reason is that we migrated these jobs to M1 machines, as circleCI is deprecating intel ones, and on these machines the simulators tend to freeze. Hence, every often we get stuck when running the tests. :(
We are going to move to GHA, so that should not be a big issue.
## Changelog:
[Internal] - Disable unit tests in CircleCI to improve CI robustness
Reviewed By: cortinico
Differential Revision: D58948614
fbshipit-source-id: 5420bdf0fda325779a4e287e7b00c623de822ccb
Summary:
This PR refactors `supportedInterfaceOrientations` to use RCTKeyWindow instead of `[RCTSharedApplication() keyWindow]`.
## Changelog:
[IOS] [CHANGED] - Refactor supportedInterfaceOrientations method to use RCTKeyWindow()
Pull Request resolved: https://github.com/facebook/react-native/pull/43026
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D59109614
Pulled By: cipolleschi
fbshipit-source-id: 025534c419078dce29e1e5caacf8a1b15de1abcc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45196
Currently, `mockComponent` makes a false assumption that if a component is a function, it extends `React.Component`.
There's a bunch of problems with this mocking setup with requiring mock components that extend `React.Component`, but this change does not attemp to solve that.
This change unblocks future refactors to make native components export functional components (that are neither class component nor `forwardRef` results).
Changelog:
[General][Changed] - Fixed native component mocking in Jest unit tests to support functional components
Reviewed By: javache
Differential Revision: D59097730
fbshipit-source-id: ca2784ac3baa9ab4ab6a503c5fd6437c60179352
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45195
Configure `Modal-test.js` to reset modules between test cases so that there is better isolation, making the tests easier to reason about and to debug.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59097729
fbshipit-source-id: 3b9260283e171ff7fa6b7ffc56685f703875291e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45174
As per title, this port bck to main the changes we made in the release testing script.
## Changelog:
[Internal] - Update release testing script to work with the new template
Reviewed By: blakef
Differential Revision: D59054045
fbshipit-source-id: 0e93c2db94499407845b4fb2c98c8b44310e770f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45175
This change ports the CI improvements we made on stable branch to main.
## Changelog:
[Internal] - Port back to main improvements we made in GHA
Reviewed By: cortinico
Differential Revision: D59053873
fbshipit-source-id: 73eb7e33b9bbdc5d8c3a9294f487ad969b144bf3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45190
Just a small follow up from the previous change to `IntersectionObserverManager`.
Changelog: [internal]
Reviewed By: javache
Differential Revision: D59065041
fbshipit-source-id: 2944299143e6a0fe53fe64083db85635e72d71af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45162
Previously we would crash in ReactInstance#callFunctionOnModule (P1443291303) when reloading (due to the onHostPause call) because we removed a source of synchronization by using the immediate executor.
Workaround it by making sure we always null out references to `mReactInstance` before we actually start destroying it.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59002404
fbshipit-source-id: 3ee14cd1fe7d423bb6158356bb99b3d2d6af8d6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45170
Reimplements `unstable_subscribeToOnScroll` so it does not invalidate all descendant children upon first invocation per `ScrollView` instance.
Previously, the state update would cause the entire `ScrollView` component to re-render. This refactors the `enableSyncOnScroll` boolean state so that it resides in a lower level component that implicitly memoizes all of its `props` (including the `ScrollView` children).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D59033393
fbshipit-source-id: 5a4b75aebdcbd0dd1dfa28511862bee495816250
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45194
Makes a couple improvmeents to `LogBoxInspectorHeader`:
- Avoid eagerly initializing the `StatusBar` TurboModule until it is actually needed (which is only when the inspector is rendered on Android).
- Switch to `SafeAreaView` on iOS, for more accurate spacing (instead of the hardcoded iPhone X notch size).
Changelog:
[General][Changed] - Improve LogBox initialization performance
[iOS][Changed] - Improve LogBox safe area insets styling
Reviewed By: lyahdav
Differential Revision: D59081529
fbshipit-source-id: 01cc351fa9267f96b7a3c13cf1db80de3e597f93
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45186
Changelog: [internal]
(this is an internal change because `IntersectionObserver` hasn't been released yet).
When testing IntersectionObserver, I realized that it wasn't triggering notifications for elements not intersecting when the surface that contained them was completely deallocated.
This is unexpected because IntersectionObserver notifications are delivered when the element is removed from the root, but not when the root itself is removed.
This fixes that behavior by:
1. Adding a method in `UIManagerMountHooks` to get a notification about the surface being unmounted. This is necessary to keep the API backwards compatible.
2. Using that method in `IntersectionObserverManager` to notify all observers (and report a change if necessary).
Reviewed By: javache
Differential Revision: D59061136
fbshipit-source-id: ef5669f9d6b08d98652489e6731902d192ec28f8
Summary:
Tests were failing on windows due to parsing CRLF line endings. This change enables the API tests for windows by normalizing line endings before parsing the file.
## Changelog:
[INTERNAL] [ADDED] - `public-api-test` now runs on Windows.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45145
Test Plan: Build-time-only change; relying on CircleCI
Reviewed By: cipolleschi
Differential Revision: D59001867
Pulled By: huntie
fbshipit-source-id: a7a41945e8c93288be1d5b7b59df7f621e467657
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45185
Follow-up to D59058085.
Since the release branch for 0.75 has been cut, we are able to simplify this step.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59058084
fbshipit-source-id: 21b77a74e13bb196336a63b984f921f0c9fde587
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45184
This is a follow-up to D59055522.
> NOTE:This diff will be followed up by a merge of the set-rn-version script into set-version. (I had considered a rename to version-rn-artifacts, intentionally keeping this script separate and distinct from a future [lerna version + this script] setup — however the current UX and confusion with this naming would be too confusing. It can move into a util 👍🏻.)
- Rename `set-rn-version` to `set-rn-artifacts-version` (more accurate).
- Mark this script as deprecated.
- For now, there are too many references to this script in CI test jobs to refactor away this entry point, so I am avoiding this — these should later be standardised to `set-version`.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D59058085
fbshipit-source-id: 4123ac73b5c7a2e07a1d1b6da61e0ad94fc31f84
Summary:
While developing React Server Component support for React Native, I've been adding this patch to the `react-native` package. It opts the entire `react-native` package out of being server rendered.
In the future, we'll want to circle back and refactor the `react-native` package to be more isomorphic so we can allow for utilities like `processColor` to be used in server bundles that target native platforms.
## Changelog:
[GENERAL] [ADDED] - Added support for importing `react-native` in a `react-server` environment for React Server Components support.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/43986
Test Plan:
Using react-native with this patch in a framework that supports React Server Components for native platforms, such as my unreleased branch of Expo Router, will allow for server rendering views from `react-native` to RSC Flight code with client references to the `react-native` package, e.g.
```js
import { View } from 'react-native';
export default function App() {
return <View testID="basic-view" style={{ "backgroundColor":"#191A20" }}/>
}
```
Can be server rendered to ↓
```
2:I["/node_modules/react-native/index.bundle?platform=ios&dev=true#798513620",["..."],"View"]
1:["$","$L2",null,{"testID":"basic-view","style":{"backgroundColor":"#191A20"}}]
```
> The client boundaries (URL paths) are specific to the current Expo CLI implementation (based on Metro) and may look different in other implementations.
Reviewed By: rickhanlonii
Differential Revision: D55891243
Pulled By: TheSavior
fbshipit-source-id: d8dc9590039181ebf2c013dacca5f255d7a8f625
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45180
- Simplifies the responsibilities of `scripts/releases/set-rn-version.js`.
- This no longer modifies `packages/react-native/package.json`, delegating this to `set-version`.
- Simplifies logic in `set-version`, **fixing behaviour** against deps in `packages/react-native/package.json`.
- This also acts as cleanup since D58469912 (template removal) — removing the unreferenced `update-template-package.js` util.
NOTE: This diff will be followed up by a merge of the `set-rn-version` script into `set-version`. (I had considered a rename to `version-rn-artifacts`, intentionally keeping this script separate and distinct from a future [`lerna version` + this script] setup — however the current UX and confusion with this naming would be too confusing. It can move into a util 👍🏻.)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59055522
fbshipit-source-id: 79b937f9e0ac790512b180ab4147aefef7f5202c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45028
Since the addition of new workspaces to the repo which introduce interdependencies on `react-native` (`helloworld`, `react-native-test-library`), this fix is needed to preserve our current versioning strategy and bump the repo after yesterday's `0.75-stable` branch cut.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58725561
fbshipit-source-id: ab282806560f47dc5acf7e694302ca6b85649b14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44814
We needed this workaround to import the paper renderer in the New Architecture to make sure that the event emitter is properly registered before we use it.
With the previous change, we don't need this lines of code anymore as we are using a different mechanism for the events.
## Changelog:
[Internal] - Avoid to import the old Renderer in the New Architecture
## Facebook:
This diff was initially part of D57097880, but I split them for the OTA
Reviewed By: cortinico
Differential Revision: D58234325
fbshipit-source-id: 1335992460635e9e97ee83615f9fd2651936b32c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45167
Configures a `REACT_NATIVE_ENABLE_FUSEBOX_DEBUG` flag, and exposes this flag in the Buck target. This is an additional hook to enable the new debugger stack (codename Fusebox) as part of our internal rollout.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D59014161
fbshipit-source-id: f05e8b01ed07da90ef6d7a66ade05f462dd82023
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45156
We don't want to bubble up exceptions from props parsing, so match the behaviour from convertRawProp and fall back to the default value when an exception is encountered.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59000397
fbshipit-source-id: f6f64a80fed98525cdd2a5b5d360c2d6ede76a12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45160
This should optimize the Gradle cache, so that only `build_android` which
effectively builds everything Android related, should be allowed to write there.
More info on this strategy here:
https://github.com/gradle/actions/blob/main/docs/setup-gradle.md
Changelog:
[Internal] [Changed] - Only build_android should write to the Gradle Cache
Reviewed By: cipolleschi
Differential Revision: D59002323
fbshipit-source-id: 31b815747efdf93bfc7baf97799e287c8dcd7f02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45165
This is a fix for https://github.com/facebook/react-native/issues/45112
This diff changes the codegen so that the output path is computed relative to project root (or `path` if provided) instead of current working directory.
Changelog: [General][Fixed] - Codegen computes output path relative to project root instead of current working directory.
Reviewed By: fkgozali
Differential Revision: D59009821
fbshipit-source-id: 3a138a3508fc239c8600b8c9f242f1c665f8e3c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45049
WithRuntimeDecorator is missing many methods that were added after it.
Add implementations for them.
The underlying issue here is that because this inherits from
RuntimeDecorator, which implements all methods, there is no compilation
error for this runtime when we add new methods.
Changelog:
[GENERAL] [FIXED] - Add missing methods to the WithRuntimeDecorator class.
Reviewed By: avp
Differential Revision: D58752127
fbshipit-source-id: d80b4ed1c38698ed3850d0cd961bf7ddde2449a0
Summary:
This PR adds missing `WithRuntimeDecorator` methods related to `NativeState`. This pattern is used by reanimated to ensure no concurrent access to the runtime. Without this `override` the `RuntimeDecorator` implementation was used, bypassing our mutex.
Changelog:
[GENERAL] [FIXED] - Add missing `NativeState` methods to the `WithRuntimeDecorator` class.
Pull Request resolved: https://github.com/facebook/react-native/pull/45042
Reviewed By: fbmal7
Differential Revision: D58744051
Pulled By: neildhar
fbshipit-source-id: 3f5c85d0bf7cd6445d0c434ac4ae7ed54df203ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45168
Refactors the native component imports in `ScrollView` so that 1) they create less clutter in the `ScrollView` implementation file, and 2) they offer more efficient import inlining.
Currently, `ScrollView` has to evaluate both horizontal and vertical components even though only one may be used. Now this optimization is possible.
Changelog: [Internal]
Reviewed By: lyahdav
Differential Revision: D59015990
fbshipit-source-id: 963009821a7d3019d36a43269e9792ac1f2f38ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45164
Some changes have been made to the codegen since `react-native-test-library` was published. This diff updates the generated artifacts in that library.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D59010093
fbshipit-source-id: f11ccd3645da72d45c70581e485f8546166ca182
Summary:
## Summary
Right now, the only way to load the javascript bundle is through the assets:// directory.
But, legacy react native also supports loading bundles via regular file urls.
If present, those file urls override the assets:// bundle urls.
This diff implements that support in bridgeless.
Changelog: [Android][Added] Allow js bundle file urls
Reviewed By: christophpurrer
Differential Revision: D58977143
fbshipit-source-id: 6f1a170546c8bbeac3a1b9d2dd5633177e33a688
Summary:
The ReactInstanceManager allows applications to register a ReactInstanceEventListener with itself.
Exposing a similar functionality to ReactHost. So, applications can do the same in bridgeless.
Changelog: [Android][Added] - Make ReactInstanceEventListener available on ReactHost
Reviewed By: christophpurrer
Differential Revision: D58890092
fbshipit-source-id: c18ee8a45d274c5cba859c6a5b4049904f1d308a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45138
Add a new `/open-debugger` endpoint format that allows specifying `target` - the proxy-unique target `id`. This is logically equivalent to specifying both device and page.
Changelog:
[General][Added]: Inspector: Support `/open-debugger` specifying `target` param
Reviewed By: hoxyq
Differential Revision: D58950622
fbshipit-source-id: 9665f8a24ba2bb0561cc3c693dfb84bfffdeb4a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45140
Previously, if the `/open-debugger` endpoint was provided with both `device` and `appId` query params, we would:
- Try to find a target with a matching `device` (note that these logical "devices" are unique per-app) - if found, use it. Otherwise,
- Try to find a target with a matching `appId` - if found, use that.
This could go "wrong" in two ways:
- If a `device` is given with a spurious `appId`, we'd open to a target with an `appId` differing from the one specified.
- If the `device` has gone away but there is a different target with the same app, we'd use that as a fallback (right app, wrong device).
This applies the filters more strictly so that if both are given, both must match.
Changelog:
[General][Changed]: Inspector: Enforce device and appId filters if both are given to /open-debugger
Reviewed By: hoxyq
Differential Revision: D58951952
fbshipit-source-id: a95f1160e5c88f957445058f3273e922a5d28c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45088
This diff should make iterator-style prop setting more performant.
- It removes some layers of indirection. Now `ConcreteComponentDescriptor` calls into `setProp` directly.
- On both platforms, we will use `folly::dynamic` parser, it seems it is slightly faster.
- On Android, we will reuse `props->rawProps` parsed as a `folly::dynamic` representation, instead of parsing stuff twice.
Changelog: [Internal] - This hasn't been rolled out to OSS yet.
Reviewed By: javache
Differential Revision: D58593492
fbshipit-source-id: aa2dcb4e7ba2248f6ba7aa82a60355efdf769b2c
Summary:
This PR replaces the depreacted `statusBarOrientation` method to `interfaceOrientation`, as in the apple developer docs it clearly says the method has been deprecated
https://developer.apple.com/documentation/uikit/uiapplication/1623026-statusbarorientation
## Changelog:
[iOS] feat:- added UIInterfaceOrientation in place of statusBarOrietation.
[IOS] [ADDED] - Added RCTUIInterfaceOrientation helper method
Pull Request resolved: https://github.com/facebook/react-native/pull/44825
Test Plan: Tried `RNTester` build after the changes and it ran successfully!
Reviewed By: cortinico
Differential Revision: D58947500
Pulled By: cipolleschi
fbshipit-source-id: 401abf1d46b415093f441d1dbee139e7aaf8712c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45146
Changelog: [Internal]
Currently, on Android, we destroy the Fusebox `HostTarget` when we receive the `onHostDestroy` event, which (counterintuitively) does not mean the ReactHost/InstanceManager ("Java Host") is being destroyed. This can lead to situations where the `HostTarget` is destroyed too soon (e.g. when a single Java Host is reused across multiple Activities).
Now that we have the `invalidate()` method on the Java Host classes, we can tie `HostTarget`'s destruction to that instead.
Since calling `invalidate()` is explicitly optional, we also need to account for the case where the caller just lets go of the Java Host reference and expects GC to handle cleanup. This includes:
* Breaking the retain cycle between the Java Host and its C++ part. We achieve this using `WeakReference` to reference the Java Host.
* Making the C++ part of the Host safe to destroy from any thread (and in particular the finalizer thread). We achieve this by scheduling `HostTarget`'s unregistration (in C++) on the executor supplied by the Java Host.
Reviewed By: hoxyq
Differential Revision: D58284590
fbshipit-source-id: 4ee4780354fb81137b891d5891d6138ac215cbff
Summary:
Improve compatibility with web implementations of JS timers.
Fixes https://github.com/facebook/react-native/issues/45085
## Changelog:
[GENERAL] [CHANGED] - Timer functions are now throwing exceptions in less cases and are instead quiet quitting (similar to browsers)
[GENERAL] [CHANGED] - Timer functions `timeout` argument is now coerced to a number
Pull Request resolved: https://github.com/facebook/react-native/pull/45105
Test Plan: Updated RN tester
Reviewed By: christophpurrer
Differential Revision: D58952146
Pulled By: javache
fbshipit-source-id: 5b6de524f6a03f5221f0d11e0ae2a9313951c767
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45143
Changelog: [internal]
Just a small refactor of some private methods in `RuntimeScheduler_Modern` to refer to some concepts in terms of the event loop.
Reviewed By: christophpurrer
Differential Revision: D58948811
fbshipit-source-id: 979c78ccd4cf5d96f00061049366171934b43ee2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45082
Changelog: [Android][Breaking] `ReactNativeHost` invalidates the instance manager on `clear()`
Changes `ReactNativeHost.clear()` to invalidate the underlying `ReactInstanceManager`, rather than merely destroying the instance.
This is technically a **breaking change** because the underlying `ReactInstanceManager` may have escaped (via `ReactNativeHost.getReactInstanceManager()`) before the `clear()` call. In my reading of the API and of usages like [this one in Expo](https://github.com/expo/expo/blob/23a905b17065703882ebeda1fc9f65a05cc69fa7/packages/expo-dev-menu-interface/android/src/main/java/expo/interfaces/devmenu/ReactHostWrapper.kt#L117), this should rarely occur in practice.
The plan:
1. D58811090: Add the basic `invalidate()` functionality.
2. **[This diff]**: Add `invalidate()` call sites where it makes sense in core.
3. [Upcoming diff]: Keep the Fusebox debugging target registered until the Host is explicitly invalidated.
Reviewed By: javache
Differential Revision: D58811091
fbshipit-source-id: 5dfebad46a2bdf3601642b3c3fe3e79e8695e193
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45081
Changelog: [Android][Added] Add `invalidate()` method to ReactHost and ReactInstanceManager
Adds an `invalidate()` method to both `ReactHost` (Bridgeless) and `ReactInstanceManager` (Bridge). This method is an *optional* signal that the application is about to permanently stop using the Host, and that the Host can therefore fully clean up any resources it's holding.
Reusing a Host after it's invalidated is illegal and will trigger a Java assertion.
The plan:
1. **[This diff]**: Add the basic `invalidate()` functionality.
2. [Upcoming diff]: Add `invalidate()` call sites where it makes sense in core
3. [Upcoming diff]: Keep the Fusebox debugging target registered until the Host is explicitly invalidated.
Reviewed By: tdn120
Differential Revision: D58811090
fbshipit-source-id: 79b607dcc74de38b85fc0ebb4c640b9654595c9a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44939
DropShadow is a filter so we need to add the logic for sending it to native through the same process function for the other filters.
Drop shadow can have more arguments than the other filters. I'm following a similar pattern to boxShadow D57872933.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D58370127
fbshipit-source-id: dba06bb2e0ea2799d20e8b0b9065a5729df22bb6
Summary:
Accidentally shipped, removing.
## Changelog: [Internal]
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/45135
Reviewed By: christophpurrer
Differential Revision: D58950410
Pulled By: blakef
fbshipit-source-id: 7bda7278f918a1e50c25f86e461e19fe7e176c5c
Summary:
The cache checks in GHA were performed against bool values, while the actual values are strings.
So the checks were always failing and all the steps were executed, even when not necessary.
The reason why it was failing is because, with this setup, when a cache is hit, some steps were skipped in previous jobs, making following jobs trying to execute code on not-existing files.
## Changelog:
[Internal] - Fix cache for build_hermes_macos
Pull Request resolved: https://github.com/facebook/react-native/pull/45127
Test Plan: GHA are green again
Reviewed By: blakef
Differential Revision: D58947838
Pulled By: cipolleschi
fbshipit-source-id: 8dba216e72a3034fd4c1484418d37bfb78cf314d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45116
Changelog: [Internal]
The UIManagerBinding `findShadowNodeByTag_DEPRECATED` method returns a shadow node and was updating the runtime reference on the shadow node with the created wrapper for the return value.
The JSObject holding the wrapper would get deallocated, which would deallocate the wrapper stored on the shadow node.
This would cause crashes on the next reference update for the shadow node, due to the shared_ptr being reassigned with the new value while it was already deallocated.
The `sendAccessibilityEvent` function calls `findShadowNodeByTag_DEPRECATED` to get the shadow node referenced by the provided react tag, which could lead to runtime shadow node reference corruption.
Reviewed By: sammy-SC
Differential Revision: D58920296
fbshipit-source-id: ddb9ed0ee64bc01934aabde7070731dc53a2db70
Summary:
Platforms like visionOS require explicit framework dependencies to be set in pods to build properly. For some reason linking on visionOS is more strict than on iOS but this might change in some future OS versions so it's good to have pods having exact dependencies.
I've discussed that earlier with Saadnajmi and cipolleschi. Let me know if you are okay with this change.
## Changelog:
[IOS] [FIXED] - set proper framework dependencies for built-in pods
Pull Request resolved: https://github.com/facebook/react-native/pull/45104
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D58943593
Pulled By: cipolleschi
fbshipit-source-id: 3d2df4f3bbdf36704e09f5e39bfb838b2e0f3c99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45111
Spent time debugging this issue today:
https://fb.workplace.com/groups/1700234700326965/posts/2197109080639522
The problem is described here:
https://perfetto.dev/docs/concepts/buffers
But basically we're writing too much data, too fast and the traced process can't read it fast enough. Perfetto is doing data drop.
This diff tries to use the `kStall` mode. It doesn't seem to do much but I'll leave it in for now because it shouldn't hurt too much. It's designed for our use case.
The main fix comes from increasing the buffer size to 20MB. Since it's not on by default I think it's fine to have a really large buffer for now to unblock tracing.
Reviewed By: javache
Differential Revision: D58832598
fbshipit-source-id: 101b364e2e9e28aa6a041ded1df82d5fec1f42e1
Summary:
This PR changes the call from `RCTSharedApplication()` to retrieve the status bar size using the `RCTUIStatusBarManager()` method, a way which supports multi-window apps.
## Changelog:
[IOS] [FIXED] - Retrieve status bar size using RCTUIStatusBarManager
Pull Request resolved: https://github.com/facebook/react-native/pull/45103
Test Plan: Check if the perf menu pops up in the correct spot.
Reviewed By: javache
Differential Revision: D58868503
Pulled By: cipolleschi
fbshipit-source-id: db5fc80a712a8a18a2863cdfbbe44f48bafe9fc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45091
Changelog: [internal]
We're currently logging when we execute timers in Systrace/Perfetto, but we have no information about them whatsoever.
This adds some additional information:
* What kind of timer it is
* It's ID
* And most importantly, when it was created (including the ID as well).
This allows us to know where was a specific timer scheduled and with what API.
Reviewed By: bgirard
Differential Revision: D58832112
fbshipit-source-id: 1bc11759b6c8296acf63ff3533ca1dc3428360a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45090
Changelog: [internal]
The definition of these methods is redundant when using microtasks, so it's better to avoid defining them in the first place (to also detect issues if the setup is not what we expect).
Reviewed By: sammy-SC
Differential Revision: D58816582
fbshipit-source-id: dd1b07f8b11069605e3184b1272a9bbc3b44ca75
Summary:
After upgrading my project to the latest version of react native i.e, 0.74.2, i was getting an error when running `pod install` an the error was coming from the post install hook. Going deeper into the file tree, i found that some of the things are Nil and react native is trying to use some methods on them, so fixed those issues by using chaining operators to conditionally apply the path method on them.
## Changelog:
[Internal] - fixes the post install issue when running pod install with react native version, 0.74.2
Pull Request resolved: https://github.com/facebook/react-native/pull/45095
Test Plan: Manually tested the fix. Works perfectly fine in both debug and production mode.
Reviewed By: cortinico
Differential Revision: D58863666
Pulled By: cipolleschi
fbshipit-source-id: 64459711dcf926b7544b99b542e9861c1c0f05ca
Summary:
This PR uses a suggested solution from here: https://github.com/facebook/react-native/issues/42698 to allow users to use Cocoapods 1.15.2 which fixed issues regarding RN builds.
## Changelog:
[IOS] [FIXED] - Bump cocoapods version to 1.15.2 excluding 1.15.0, 1.15.1
Pull Request resolved: https://github.com/facebook/react-native/pull/45099
Test Plan: CI Green
Reviewed By: blakef
Differential Revision: D58863685
Pulled By: cipolleschi
fbshipit-source-id: 0128eb0cbf83e4a3d35addbae4c31e349775688c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45101
This test broke after I merged
https://github.com/facebook/react-native/pull/34785
yesterday.
Just fixing it in a similar way as the test above.
Changelog:
[Internal] [Changed] - Fix broken unableToAddHandledRootView
Reviewed By: rubennorte, blakef
Differential Revision: D58864166
fbshipit-source-id: 4f48dbfd5238a2811564ce02199af7fc284d39b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44832
I'm renaming this folder as now we have 2 gradle plugins + we currently have
`package/react-native-gradle-plugin/react-native-gradle-plugin/` which is confusing so we can just call this folder `packages/gradle-plugin/`
to be consistent with the NPM package name
Changelog:
[Internal] [Changed] - packages/react-native-gradle-plugin/ -> packages/gradle-plugin/
Reviewed By: blakef
Differential Revision: D58284883
fbshipit-source-id: 5a7bb40a5d80f6fbab4ffb29e44107453f1013ec
Summary:
Follow the same solution (do not throw a crash when view ID is set already) used in `ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java` for `ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.java`
## Changelog
[Android] [Changed] - Log a SoftException on SurfaceMountingManager.addRootView
Pull Request resolved: https://github.com/facebook/react-native/pull/34785
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D40022263
Pulled By: cortinico
fbshipit-source-id: d565d2831e2833ccea55f28ea16083b7bae0ed32
Summary:
Adds an overload for `createLayout` method that also handles extracting paragraph attributes and scaling font size if necessary.
## Changelog:
[ANDROID] [CHANGED] - Extracted common parts related to calculating text layout to a helper
Pull Request resolved: https://github.com/facebook/react-native/pull/45083
Test Plan: Tried out on RNTester
Reviewed By: robhogan
Differential Revision: D58818560
Pulled By: cortinico
fbshipit-source-id: a42b5de04c4a70edb88cdd734387d7e4cee94032
Summary:
While landing a change on GH, I forget to remove one line that does not belong to an action
## Changelog:
[Internal] - CI fix
Pull Request resolved: https://github.com/facebook/react-native/pull/45084
Test Plan: GHA are green
Reviewed By: blakef
Differential Revision: D58817768
Pulled By: cipolleschi
fbshipit-source-id: 5fc02d2d2a19dd3fe2202c93d0d1873e5dda4b82
Summary:
This change is the first step in refactoring GHA so that they can be reused more easily across jobs.
Its goal is also to be more reliable w.r.t. caches.
That this change do:
* moves `prepare_hermes_workspace` to a composite action
* saves the `prepare_hermes_workspace` caches only on main
* uploads the destination folder as an artifact so that we can use it later in the run
* makes the `test-all`, `nightly` and `publish-release` workflow use the new composite action
* updates the `setup-hermes-workspace` to download and use the artifact uploaded by `prepare_hermes_workspace`
## Changelog:
[Internal] - Factor out the prepare_hermes_workspace action
Pull Request resolved: https://github.com/facebook/react-native/pull/45071
Test Plan: GHA in CI
Reviewed By: cortinico
Differential Revision: D58808087
Pulled By: cipolleschi
fbshipit-source-id: 42c46bcf75fc73b2edfda9be62b5d0fe8a919a5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45076
> **start**: The same as left if direction is left-to-right and right if direction is right-to-left.
This is equivalent to `auto`, which is not actually a valid CSS value.
Changelog: [General][Added] Add support for `texAlignment: 'start'`
Reviewed By: sammy-SC
Differential Revision: D58791937
fbshipit-source-id: 09622d814212a7055f94b1f091c71edae5db117c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45073
We can also remove the workaround needed for git `safe.directory`
as this is now configured inside the container as `*`
Changelog:
[Internal] [Changed] - Bump reactnativecommunity/react-native-android to 13.1
Reviewed By: blakef
Differential Revision: D58789791
fbshipit-source-id: f44163a0aa822b19e0dd1106d3f039fd0dc83186
Summary:
This change splits the build step and the test step for running the test on iOS, so we can introduce a retry for the test only.
We are doing that because we have seen some flakyness in CI jobs as sometimes the simulator fails to install the app.
## Changelog:
[Internal] - Add retry to iOS tests
Pull Request resolved: https://github.com/facebook/react-native/pull/45070
Test Plan: Testing in CircleCI
Reviewed By: cortinico
Differential Revision: D58786706
Pulled By: cipolleschi
fbshipit-source-id: 61363cb86dd1a496d3595b43b6331cbee7f032ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45060
Currently, `j`, (i.e., `/open-debugger` with no parameters), connects the "first available" target, which in practice is the first page of the first connected device still connected.
In the absence of a target selection UI, a better guess at user intent is to use the *latest* target (most recently added page of most recently connected device).
Also slightly reduces CLI noise by not claiming that we're launching a debugger when there's no target, and not qualifying which target when there's only one.
Changelog:
[General][Changed] Debugger: `j` opens most recent (not first) target.
Reviewed By: huntie
Differential Revision: D58736151
fbshipit-source-id: 3d106a1fa958f9e5c91b16e04075609e1abf6e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45069
Currently, `/json/list` returns pages within each device in the iteration order of a C++ `unordered_map`, which doesn't tell us anything useful. Page IDs happen to be sequential, but only as an implementation detail.
Change this contract so that we guarantee ordering reflects addition order, allowing clients to consistently select e.g. most recently added page for a given device.
The implementation of this is as simple as switching from an `unordered_map` to a key-ordered`map`, because we already assign keys (page IDs) with an incrementing integer. Within the inspector proxy, devices already use an insertion (connection)-ordered JS `Map`, so we just document this guarantee.
Changelog:
[General][Changed] Debugger: Make `/json/list` return connection-addition-ordered targets.
Reviewed By: huntie
Differential Revision: D58735947
fbshipit-source-id: 7a132cc5e750475792a2b845afc9a42424690bf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44840
Changelog: [Internal]
Introduce a simplified and minimal tracing backend for Fusebox. This backend is sufficient to implement a pretty usable performance panel.
Although the more I see how easy this is and how annoying working with Perfetto is, the more I think we should just maintain this going forward. Anyways we can figure that out incrementally. For now the plan is still for this to be temporary.
Reviewed By: motiz88
Differential Revision: D57981944
fbshipit-source-id: b3d8c6e8c5a18311bbe98254f8ddf3810fa1334b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45068
changelog: [internal]
In D58672844 I added gating to module.exports.
This gating is sensitive to when feature flags are initialised and causes test failures and regressions for developers. Let's move the feature flag check to component's render function. It introduces extra spread operator but it is good enough to compare new and old <Text /> component.
Reviewed By: GijsWeterings
Differential Revision: D58783941
fbshipit-source-id: f89f4f48e6aeb774ed4a84483a9f4ad59d5bc045
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45026
All callsites for these containers already explicitly synchronize using these objects, so there's no need to use a synchronized collection wrapper here.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D58724044
fbshipit-source-id: 5151ebb0ceda8656b6039d9984cc32a843051abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45025
This API just passed through the `enableArchitectureIndicator` prop to a custom WrapperComponent, as there is no default consumer of it. Instead, each provider of a custom WrapperComponent can capture the required value of itself.
Changelog: [General][Removed] Removed enableArchitectureIndicator API which is only used internally.
Reviewed By: cortinico
Differential Revision: D58723922
fbshipit-source-id: 0c52a904424382f33caab92ac50b316ae161f877
Summary:
This incorrectly used the SHA from facebook/react-native instead of
facebook/hermes to label the hermes cache key. This would bloat our
cache by ~ 1.2GB for each PR.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45061
Test Plan: We should remove the existing entries for v4-hermes and track the growth over time.
Reviewed By: cipolleschi
Differential Revision: D58780475
Pulled By: blakef
fbshipit-source-id: 0f192faa287f53154f1c8319be6783820d614018
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45059
Changelog: [internal]
By moving the command to a code block it's going to be easier to see it when quickly reading the README.
Reviewed By: cortinico
Differential Revision: D58779883
fbshipit-source-id: e912a58641245c6d7dc158f7af0a722e438a0cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D58705515
fbshipit-source-id: 74e9a68fc0e3d1e88b8eebbb34a1ca8c29052c21
Summary:
The existing regex is not workign. I've split it in two and tested it against a private repo.
## Changelog:
[INTERNAL] - Fix release regex for publish-release workflow
Pull Request resolved: https://github.com/facebook/react-native/pull/45043
Test Plan: Tested on privare repo with GHA
Reviewed By: cipolleschi
Differential Revision: D58736292
Pulled By: cortinico
fbshipit-source-id: f07ef32dcb0059922100c555f7894bbf0c7dd8f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45035
Changelog: [General][Fixed] Avoid a zombie state when opening a second debugger frontend concurrently.
The problem here was that we were sending proxy-protocol messages to the device in the wrong order (`disconnect` *after* `connect`):
{F1701266597}
The root cause was that we were depending on the outgoing debugger socket's async `close` event to trigger sending the `disconnect` message to the device. This would happen after we'd already (synchronously) sent the `connect` message.
With this diff, we send the `disconnect` message synchronously with calling `close()` on the debugger socket, which fixes the ordering problem at the source. To avoid sending duplicate `disconnect` messages (e.g. one before calling `close()` and one from the `close` event handler), we store some extra state on `Device` (`#connectedPageIds`).
Reviewed By: robhogan, huntie
Differential Revision: D58730634
fbshipit-source-id: 0f54af2e4f8071a8f6d97cc9e3d8a4ea89a46f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45027
Changelog: [Internal]
Changes the device ID collision handling logic to reuse `Device` instances instead of creating new ones. This enables further refactoring of `Device` to improve session state isolation.
Reviewed By: hoxyq
Differential Revision: D58724884
fbshipit-source-id: bc11ce45ce8c80c58c32dcd1b07b28f1d1753a62
Summary:
We are moving to publish from gha so we need to remove these jobs
## Changelog:
[Internal] - Remove old publishing jobs from CI
Pull Request resolved: https://github.com/facebook/react-native/pull/45040
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D58734881
Pulled By: cipolleschi
fbshipit-source-id: 5981bfcf2aa51d55d54d08556631b30b6102a7cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45032
Those tests haven't been running since ~1 year now.
I know it's not ideal but I'd rather remove them instead of keeping them around not executing.
We can still revert them back from the history once we decide to revive the E2E testing effort.
Changelog:
[Internal] [Changed] - Remove unused rn-tester e2e tests
Reviewed By: cipolleschi
Differential Revision: D58729123
fbshipit-source-id: f0f47e3c2e087141fdff506b7c5c9b460263721b
Summary:
Fixes https://github.com/facebook/react-native/issues/41988
Hopefully even if this isn't the right way to go about solving this, it at least points in the right direction for a different fix!
Currently - both on Paper and Fabric - the `selectTextOnFocus` prop does not work as expected on a single line text input. It seems that if the `UITextField` has not yet become the first responder, the text will be briefly selected but then deselected immediately afterward.
This can be seen in the tester when running for either Fabric or Paper (video using Fabric)
https://github.com/facebook/react-native/assets/153161762/aa9c609e-6eb8-4177-a41f-32aae53c06ac
Instead, we can move the `selectAll` call to `reactFocus` in `RCTBaseTextInputView` or `focus` `RCTTextInputComponentView` - both of which first call `becomeFirstResponder` - to get the expected result.
## Changelog:
[IOS] [FIXED] - fix selectTextOnFocus in Fabric and non-Fabric by calling selectAll after becomeFirstResponder
Pull Request resolved: https://github.com/facebook/react-native/pull/44307
Test Plan:
* Test changes on RN Tester (iOS)
https://pxl.cl/55kDc
Reviewed By: cipolleschi
Differential Revision: D56699773
Pulled By: fabriziocucci
fbshipit-source-id: ed092835f3c602e2c50a4198357653a9cef942d9
Summary:
Use GHA on PRs:
1. run test_android_helloworld when users create a PR, to provide coverage while we figure out what's going on with our CircleCI tests / deprecate them.
2. fixes uploading the `.apks` that are generated.
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/45019
Test Plan: Does GHA run for this PR?
Reviewed By: cipolleschi
Differential Revision: D58728019
Pulled By: blakef
fbshipit-source-id: c6db41d60225702d50343384f103585d83e3528c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45023
This mirrors the same setup we have on the 0.75 release branch
Changelog:
[Internal] [Changed] - Move test_android_helloworld to 4-core-ubuntu
Reviewed By: cipolleschi, blakef
Differential Revision: D58724157
fbshipit-source-id: 754d4f777d4239eeaa6a5232508f54cfe62d4c88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45013
Changelog: [internal]
## Context
We recently realized that in the majority of events dispatched to React from Fabric, passive effects were being mounted synchronously, blocking paint instead of in a separate task after paint.
The reason for that is that in React, passive effects for discrete events are mounted synchronously by design (see https://github.com/reactwg/react-18/discussions/128), and Fabric is currently assigning the discrete event priority to most current events (including things like layout events).
## Changes
This creates a feature flag to opt into a more granular control over event priorities in React Native. Instead of assigning the discrete event priority to events by default, this would assign the "default" event priority by default, except for events dispatched during continuous events that would also be considered continuous.
This would also fix the priority for continuous events, that it was currently being assigned as "default" incorrectly.
Reviewed By: christophpurrer, javache, sammy-SC
Differential Revision: D58677191
fbshipit-source-id: c65a8dc2118ed028e1e895adec54f9072b7e55a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45011
Changelog: [Internal]
Fixes an inspector-proxy test case that was (silently) incorrect. This is in preparation for an upcoming rewrite of the core of inspector-proxy to more strictly isolate session state, which causes the incorrect test to fail.
Reviewed By: hoxyq
Differential Revision: D58193527
fbshipit-source-id: bdc27179210117ca9249b272f2e4aff19ba8a06c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44908
Changelog: [General] [Changed] - CircleCI test to Helloworld, but disabled for now until we remove the template
Reviewed By: cipolleschi
Differential Revision: D58469912
fbshipit-source-id: 718a774946bd70347697f18bbfc470b2897d2f87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44962
Add a short term fork of `Text` for the purpose of performance testing.
Specific differences from `Text`:
- Lazy init Pressability via a nested component.
- Skip children context wrapper when safe.
- Move props destructuring to function param.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D58601810
fbshipit-source-id: 988bac6100287705fb1bf8dc48cb2cfae56343df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58602799
fbshipit-source-id: 605bc384267d9f4ae5a051e76c1a4d862fe54039
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44884
Removing JavaScript error handler supplied to ReactHostImpl.java which is just a stub and creating a default handler in ReactInstance.java which uses NativeExceptionHandler TurboModule to handle error.
Changelog: [Android][BREAKING] Removing `ReactJsExceptionHandler` param from ReactHostImpl() constructor and providing a default private implementation
Reviewed By: javache, cortinico
Differential Revision: D58385767
fbshipit-source-id: 46548677df936b7c2f584084a2c9769c27e6a963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45010
D46482492 added logic for handing off state across "device" connections that have the same ID. This logic currently has no test coverage. It also contains a bug whereby the new device's pages are removed from the target listing endpoint (`/json`) when the *old* device's socket is closed.
This diff adds tests and fixes the bug.
Changelog: [General][Fixed] inspector-proxy no longer accidentally detaches connected devices.
## Next steps
It seems that the device ID handoff logic exists to paper over a deeper problem with the inspector proxy protocol (or its implementation in React Native): The React Native runtime should not routinely be creating new "device" connections without tearing down previous ones.
In followup diffs, I'll explore changing this behaviour for Fusebox, based on the new test coverage.
Reviewed By: robhogan
Differential Revision: D51013056
fbshipit-source-id: e0c17678cc747366a3b75cef18ca2a722fc93acd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45009
This script dependes on the template existing in react-native/template. We're removing this, but can't land that until we disable this test.
Future work could move this test into the react-native-community/template project to validate against RN release candidates to support releases.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D58672744
fbshipit-source-id: c1500aebb0b21afd1ba37785e73dd6a0e1d6020e
Summary:
Qhile landing the changes for React19 in 0.75, we missed one test that needs to be updated
## Changelog:
[Internal] - Fix Jest tests in React 19
Pull Request resolved: https://github.com/facebook/react-native/pull/45007
Test Plan: CircleCI is green
Reviewed By: robhogan
Differential Revision: D58671824
Pulled By: cipolleschi
fbshipit-source-id: 48a72f5cdc4d03201cb1778915ed3519759cf017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45006
The steps were pointing to an incorrect folder. Updated to points to react-native/packages
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58669426
fbshipit-source-id: b58b9bc7d8c7860f2f46c8bdf4bf0636e82ee357
Summary:
After updating my project to 0.73.2 I noticed that even though I had a specific port set in my `metro.config.js`, every time I'd start my project, it was running on port 8081. Passing the `--port` argument would allow me to change the port, but the config from metro did not. I checked if the metro config was being properly applied, using `--verbose` and it was.
So I dug a bit, trying to figure out what had changed and noticed the coalescing of the value, whenever the argument `--port` is not present. That seemed odd since it meant that there's always a port defined for the `options` of `loadMetroConfig`, which would always be used in the `loadConfig` step.
To confirm I was on the right track I went to the [cli-plugin-metro](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro) repo, to the last release before the move here, and noticed that there was [no coalescing in the same method](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro/src/commands/start/runServer.ts#L60).
In this PR, I remove the coalescing of the port from `runServer.js` from the `community-cli-plugin`, to allow the port configuration through `metro.config.js`.
## Changelog:
[INTERNAL] [FIXED] - Fix server port configuration via `metro.config.js`
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/44957
Test Plan:
Running `yarn start` and verifying that:
- it would listen to port `8081` if no argument nor a custom port was set in `metro.config.js`
- it would listen to port `8082` if that one was defined in `metro.config.js`
- it would listend to port `8083` if that port was passed as an argument to the command (i.e. `yarn start --port 8083` even though port 8082 was defined in `metro.config.js`
Reviewed By: cortinico
Differential Revision: D58605152
Pulled By: robhogan
fbshipit-source-id: 9cf7a8b6a0d9de3af1ca4092906b4c648acee373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45005
We've had failures owing to running out of disk space, however this isn't a stable failure. Adding more data about disk availability and utilisation to help debug these issues.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58667190
fbshipit-source-id: 3d5f7cc985ac71044818f7b5663ef7400ad691b5
Summary:
Implements `requestIdleCallback` and `cancelIdleCallback`
### Notes
Proposed implementation does yet cover all WHATWG eventloop requirements.
- Deadline computation is not implemented and is polyfilled by giving each callback `50ms`, rather than it being shared between other idle callbacks.
- The requested callbacks are called with lowest priority by the scheduler as of now, but the execution is not as described in the standard.
## Changelog:
- [GENERAL] [ADDED] - Implemented `requestIdleCallback` and `cancelIdleCallback`
Pull Request resolved: https://github.com/facebook/react-native/pull/44759
Reviewed By: javache, sammy-SC
Differential Revision: D58415077
Pulled By: rubennorte
fbshipit-source-id: 46189d4e3ca1d353fa6059a904d677c28c61b604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44991
Updates the open source renderers for React 19. This is in preparation for React Native 0.75.
Notable, this incorporates the feature flag changes from [facebook/react#29903](https://github.com/facebook/react/pull/29903).
Changelog:
[General][Changed] - Upgrade Renderers for React 19
Reviewed By: robhogan
Differential Revision: D58632199
fbshipit-source-id: 674bb47554e4b0c6ab5127fb9683ed8284b7a4ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44990
Upgrades React Native and Relay to depend on React 19, which is currently published as release candidates. This is in preparation for React Native 0.75.
This will depend on updating open source renderers after [facebook/react#29903](https://github.com/facebook/react/pull/29903) is merged.
Changelog:
[General][Changed] - Upgrade to React 19
Reviewed By: robhogan
Differential Revision: D58625271
fbshipit-source-id: f9ad95b18716a9ce02f7cfbcc7248bdfb244c010
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44989
Enables these 2 global feature flags for React Native Jest testing:
- `IS_REACT_ACT_ENVIRONMENT`
- `IS_REACT_NATIVE_TEST_ENVIRONMENT`
Changelog:
[General][Changed] - Enables React global flag that causes Jest testing environment to require `act()`
Reviewed By: robhogan
Differential Revision: D58644562
fbshipit-source-id: 4de5ea3a89e8ca99ac4c1c21721872db4f5552b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45002
There are a couple Jest unit test cases for `VirtualizedList-test.js` that require further investigation.
We believe that these are problems with Jest fake timers in the test and not with the component itself, so for now let's skip them so as to unblock the upgrade to React 19.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58656948
fbshipit-source-id: d52f3ad8277def6eae20cbbc11751d73b769d929
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44997
Wrap `VirtualizedList-test` uses of `react-test-renderer` in `act` as appropriate, so as to pass under current React and mostly pass under React 19, with further fixes to come.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58649295
fbshipit-source-id: 5e0fa791d581fbf004a2ca7eaa5c4b4d9a15ddfe
Summary:
Migrate `VirtualizedSectionList-test` to use `act`-wrapping in prepation for React 19.
Avoid the `react-native/jest/renderer` abstractions as this is a separate package.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653558
fbshipit-source-id: 0e19fff5c3998fb00b71c3d07100a2064682cb4c
Summary:
Use `act`-wrapping abstractions for `create`/`update`/`unmount` in `Animated-test` so that it's React 19-ready.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653231
fbshipit-source-id: 44075dfde9740070279c0d1004674349d63de9cd
Summary:
Wrap `ReactTestRenderer.create` in `act` within `ReactNativeTestTools.expectRendersMatchingSnapshot`, as required for concurrent rendering and `IS_REACT_ACT_ENVIRONMENT` in React 19.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58653136
fbshipit-source-id: 9ca0d053bda3e87dd92b762061b839d7bdd571b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44961
Switch the "number of lines" warning, which ensures this value is not negative, to only fire in DEV.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58472148
fbshipit-source-id: e52849effe9a6dc3f25288a64deebd4fd7624e4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44999
Use `act`-wrapped abstraction for test rendering in preparation for this becoming mandatory.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58651098
fbshipit-source-id: d797c792b1f6ac155f02951a8264cf0631961d83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44998
Add async helpers to the existing `jest/renderer` module to wrap `react-test-renderer`'s `update` and `unmount` in `act`.
Migrate one test `ScrollView-test` as a usage example and to make it compatible with incoming React 19 concurrency requirements.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650989
fbshipit-source-id: 5eb48722ee7a5487355969e553ba79c3ce361067
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44994
For RN monorepo tests, wrap `create` calls through our `jest/renderer` abstraction in `await act`.
This is a no-op under current React but will be required under `react-test-renderer@19` with `IS_REACT_ACT_ENVIRONMENT`.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650940
fbshipit-source-id: 4013af89dd7c9f447b2dd493989f3a4fdf2b6508
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44996
Mock out some LogBoxData symbolication in LogBoxInspector-test that would otherwise make it sensitive to an async `useEffect` when wrapping in `act`.
This is immaterial to the snapshot under test (changing a state from `PENDING` to `NONE`).
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58651811
fbshipit-source-id: d47100a87d83102bbe183cb7266d66344e75b0b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44993
Use our existing thin abstraction around `react-test-renderer` `create` within `react-native/jest/renderer`, in order to benefit from the introduction of async `act` wrapping in that abstraction.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58650874
fbshipit-source-id: d3d1967fa68568e3ae2d8069478cb79aa7049ed0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44992
To allow for async `act` in a subsequent diff, make this utility method async and awaited at all call sites.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58647828
fbshipit-source-id: 3a47c57569814638c216309eed1885dd37521dde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44995
Use our existing abstraction around `react-test-renderer`'s `create` and make it asynchronous, to allow for wrapping `create` in `act` in a subsequent diff, and using the async API per guidance in https://react.dev/reference/react/act?#await-act-async-actfn .
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58647827
fbshipit-source-id: f81cf382892ef5ba14b452bd32980c98bd7ef03b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44982
Removes `react-shallow-renderer` dependency from the `react-native` package because it is no longer used.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643454
fbshipit-source-id: f9aa62af2ff0282d6b54b97da6f2870a38881947
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44973
Changes `expectRendersMatchingSnapshot` to no longer make assertions about shallow rendering, because shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643365
fbshipit-source-id: 03653045a44a176095c53fc0ff27743cc8ea1820
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44980
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643065
fbshipit-source-id: 34a31989f298535546a64c3ccd2888d648c1cdf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44977
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643060
fbshipit-source-id: a61dfcf6cd778a8556aec874fd5e42f8e11f2be2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44970
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643058
fbshipit-source-id: 75c95b3ef8f9c481b50d90bf195ba3bd90196f0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44975
These Jest unit test cases were making assertions about shallow rendering, but that shallow rendering is now deprecated.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643064
fbshipit-source-id: 19cb05df25b4b92ee584ea126d238276f5b214f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44981
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643062
fbshipit-source-id: 6d7bba78945509bbb6bdab1e6347ba0d90343ec3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44971
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643068
fbshipit-source-id: f3a0331140fbaa9ee19b76da8700e60b3efc525a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44976
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643067
fbshipit-source-id: 2e298e2736227afb9322463daa3db0578638559a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44969
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643057
fbshipit-source-id: 0d2943a714ca718841ab4bec5a33f6c9e48fea92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44986
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643069
fbshipit-source-id: a2dbba104a7f6af57b6990da3cb0055a5390bc00
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44983
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643056
fbshipit-source-id: 61494765f68f1810b19a33f5e2a6c5d4087ce11c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44972
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643055
fbshipit-source-id: 419fe07643f623e75050487beb9ca306417e43d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44978
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643059
fbshipit-source-id: 0eb36537fd3a8c69f4861fac14b99755eff97f04
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44968
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643066
fbshipit-source-id: 216a036ef8e5cfe9b362c2f367da052ee6c9808b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44979
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58643061
fbshipit-source-id: 0c68324d4d92fc8818ac469737eda3679aa773b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44974
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641098
fbshipit-source-id: be7592b3fb5c4a66879ad734439faceb4ad5cdde
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44987
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641097
fbshipit-source-id: a9d3abee19d58262d36ac250a55780df803c464b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44967
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641096
fbshipit-source-id: e9752f21763156ee409ae81a304cada84a346bdb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44985
Migrates this Jest unit test away from using `react-shallow-renderer` because it is no longer recommended.
Changelog:
[Internal]
Reviewed By: robhogan
Differential Revision: D58641095
fbshipit-source-id: 90563955876a148a2b867e0ec5128bdd8786f274
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44888
In https://github.com/facebook/react/pull/29839 we removed the `Warning: ` prefix. This PR replaces the special cases in LogBox for `Warning: ` to use the presence of a component stack instead. This is what LogBox really cares about anyway, since the reason to let errors pass through to the exception manager is to let DevTools add the component stacks.
Changelog: [General] [Fixed] - Fix logbox reporting for React errors
Reviewed By: rickhanlonii
Differential Revision: D58441017
fbshipit-source-id: 5355cd04ddcd5238dadbfcbd64fe1f43c8cd04dc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44958
Now, all soft exception methods will have raiseSoftException(...)
## Before
```
BridgelessReact: ReactHost{0}.getOrCreateDestroyTask(): handleHostException(message = "Unable to load script. Make sure you're either running Metro (run 'npx react-native start') or that your bundle 'RNTesterBundle.js' is packaged correctly for release.")
```
## After
```
BridgelessReact: ReactHost{0}.raiseSoftException(getOrCreateDestroyTask()): handleHostException(message = "Unable to load script. Make sure you're either running Metro (run 'npx react-native start') or that your bundle 'RNTesterBundle.js' is packaged correctly for release.")
```
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D58593609
fbshipit-source-id: 171a872cd41e4ffe9c2e9654c563a6f3af342ad9
Summary:
When an XMLHttpRequest is performed, the `onprogress` event it is not invoked when the `Content-Length` header is missing in the response. This is the case when we are calling an endpoint that responds with `transfer-encoding: chunked` (https://tools.ietf.org/html/rfc9112#section-7.1), preventing the user to keep track of the progress while the server is sending chunks. Despite we will never know the total length of the content (because it will not be known due to the RFC specification, so it will be always `-1`), we will now be able to keep track of the loaded data.
Note that in Android, this is the current default behaviour.
To address this issue:
- I removed the condition where the `downloadProgressBlock` was dispatched only when `response.expectedContentLength` was greater than 0
- I created a new test case for `XMLHttpRequest` in the tester app to download a chunked file
## Changelog:
[IOS] [CHANGED] - fire `onprogress` event for `XMLHttpRequest` even when the `Content-Length` header is missing in the response headers
Pull Request resolved: https://github.com/facebook/react-native/pull/44899
Test Plan:
|before|after|
|----------|:-------------:|
|https://github.com/facebook/react-native/assets/37150312/6da3518f-eed3-4808-a2f8-abe26e5c7487|https://github.com/facebook/react-native/assets/37150312/ed1da300-dcf7-4874-a941-a2289f1cb777
Reviewed By: cortinico
Differential Revision: D58562088
Pulled By: NickGerleman
fbshipit-source-id: 23a1cafa49ddcd25fa0db7d04fae845126771425
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44952
The test_helloworld_android Release variant are broken on GHA.
This fixes it as it forces hermesc to be built *before* the app attempts to create a bundle.
Changelog:
[Internal] [Changed] - Fix for broken test_helloworld_android on Release
Reviewed By: cipolleschi, blakef
Differential Revision: D58591480
fbshipit-source-id: 2afc1cfe8c416da6f5919d20098639653798dd1a
Summary:
With the migration to GHA, we are updating the testing scripts to work with the new CI.
There are a bit of shenanigans due to:
* How GHA archives artifacts => they are all `.zip` files, so I had to play around with unzipping them
* GHA seems to create a different commit, like if it is forking the repo instead of using it. I think that it is how the checkout action works. *Note:* this might be a problem for the `Create React Native Release` workflow because it has to commit on the stable branch!
* Android is building only the simulator architecture when running from regular CI. The app is not configured to run only on that, so the RNTestProject was a failing because it was trying to build all the available architectures. It is an easy fix in the user project space when release testing.
## Changelog:
[Internal] - Update the testing script to work with the new CI
Pull Request resolved: https://github.com/facebook/react-native/pull/44923
Test Plan:
Tested locally.
* [iOS] RNTester - Hermes ✅
* [iOS] RNTester - JSC ✅
* [Android] RNTester - Hermes ✅
* [Android] RNTester - JSC ✅
* [iOS] RNTestProject - Hermes ✅ (The project is created correctly and it builds, crash at runtime for https://github.com/facebook/react-native/issues/44926)
* [iOS] RNTestProject - JSC ✅ (The project is created correctly and it builds, crash at runtime for https://github.com/facebook/react-native/issues/44926)
* [Android] RNTester - Hermes ✅ (Needed to build only the simulator architecture)
* [Android] RNTester - JSC ✅ (Needed to build only the simulator architecture)
Reviewed By: andrewdacenko
Differential Revision: D58528432
Pulled By: cipolleschi
fbshipit-source-id: 733065de4c532b13d8e95e2217f9aafd5a2ef8a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44924
# Changelog: [Internal]
For Strict Mode, RDT backend will apply ANSI escape codes to style the message, basically to dim it for 2-nd invocations of logs / warnings / errors in Strict Mode.
With these changes, LogBox will filter out these stylings, so that the message is displayed correctly in the LogBox bubble and in LogBox panel (full screen mode).
Reviewed By: rickhanlonii, yungsters
Differential Revision: D58477316
fbshipit-source-id: 17773f658d2a3bfa7f6a3ccec9fc88a97dd2c0af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44919
## Changelog:
[Internal] [Fixed] - Call Turbo Module methods 'methods' in the Turbo Module JSON schema
We don't support `properties` on Turbo Modules. We only support methods (even eventEmitters are just methods)
Reviewed By: javache
Differential Revision: D58510557
fbshipit-source-id: 02b1dc93a37b58b47bb9fd94a9658b5a7301bf55
Summary:
PR changing the single mountingOverrideDelegate to a vector of those, so other listeners can operate on the transaction. Used by `react-native-screens` in https://github.com/software-mansion/react-native-screens/pull/2134 and `react-native-reanimated` in https://github.com/software-mansion/react-native-reanimated/pull/6055.
Till now, only one listener could be added there, meaning that e.g. `Layout Animations` from `react-native`, `Layout Animations` from `react-native-reanimated` and listening for `Screen` removal in `react-native-screens` could not operate at the same time.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Add option for multiple `mountingOverrideDelegates`
Pull Request resolved: https://github.com/facebook/react-native/pull/44927
Test Plan: The code of `LayoutAnimations` inside `react-native` should work the same since it will add just one listener then. For other cases, different libraries can read/mutate transactions.
Reviewed By: javache
Differential Revision: D58530278
Pulled By: sammy-SC
fbshipit-source-id: d6305963621000be11d51a50cffff64526cca934
Summary:
CircleCI is removing support for intel machines at the end of June, hence we have to migrate to M1.
## Changelog:
[Internal] - Migrate to M1
Pull Request resolved: https://github.com/facebook/react-native/pull/44944
Test Plan: CircleCI is green
Reviewed By: robhogan
Differential Revision: D58589100
Pulled By: cipolleschi
fbshipit-source-id: da7359d8c13093ef1595adc5fabb4f3628006c7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44951
As the latest minor of AGP just released, let's bump it so that 0.75 users can use it.
Changelog:
[Android] [Changed] - AGP to 8.5.0
Reviewed By: cipolleschi
Differential Revision: D58587826
fbshipit-source-id: c14091faba1cb270ea2386f22fdbf079bce61421
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44948
This is a small improvement suggested by tido64 to also account for package.json when computing caching
for autolinking of libraries.
Changelog:
[Internal] [Changed] - Add package.json to default `lockFiles` for ReactSettingsExtension
Reviewed By: cipolleschi
Differential Revision: D58587739
fbshipit-source-id: 6e0acf7d4badd8d8cc25dd90bb55fd6c0fa3779b
Summary:
## Context
Right now, the ReactInstance construtor eagerly initializes native modules.
## Problem
When these modules initialize, they may load other modules. But, all those loads will fail, because the react instance is in the process of being constructed.
## Changes
Eagerly initialize modules after the react instance is created. That way, these native module requires work.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58537536
fbshipit-source-id: d0e424df708ec35b014f5cecda11e8756e8f4346
Summary:
## Changes
1. Store the react instance inside a private property (vs in the mReactInstanceTaskRef)
2. Attach the react instance to that property immediatley, after create
## Problems resolved
1. React host apis that use the instance (like ReactContext.getNativeModule()) will now also work **during** react native init. (see T191972567).
2. If exceptions get thrown during react instance init, the react instance will now get cleaned up (see test plan).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58537535
fbshipit-source-id: fddf44d45b214b52a950e33d67ac6612a50ddcba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44905
Replaces the last template CI job.
Changelog: [Internal] [Changed] Use Helloworld in GHA CI workflow.
Reviewed By: cortinico
Differential Revision: D58466813
fbshipit-source-id: 333b9a4c71eec6901c78f144db48f365539c6a5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44936
# Changelog: [Internal]
Added a small test that uses `folly:ManualExecutor`, which reproduces the memory leak issue in Hermes' RemoteObjectsTable:
1. Send `Runtime.enable`
2. Evaluate `console.log(<object>);` to populate `RemoteObjectsTable`
3. Send `Page.reload` to reload VM
This test is expected to fail, because by the time it is published, the D58398254 hasn't landed.
Reviewed By: motiz88
Differential Revision: D58531763
fbshipit-source-id: 99af3bfce0a31fe905d5bf2bf433f62cfbc34897
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44887
The previous inexact object types and documentation for Share.share()'s arguments have led to confusion in how this library should be used. This diff updates the argument types to be more explicit, and rewrites some of the documentation for clarity.
Changelog:
[General][Breaking] Update `Share.share()`'s argument types to be more explicit.
Reviewed By: NickGerleman
Differential Revision: D58224906
fbshipit-source-id: 5ac8efe7caa0ecdd430fa7a1951c73c4acd8c6a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44938
Yoga is transitively included in Swift targets and needs to be modular.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58469454
fbshipit-source-id: 72bc6b5d3e5ee0710d9334a626e4e7297ce26b09
Summary:
Changelog: [ANDROID] [ADDED] - Add the ReactMarkerConstants.CONTENT_APPEARED support on Android in bridgeless mode.
This re-applies https://github.com/facebook/react-native/pull/43620 which was reverted because a CI job started failing because we forgot to update `packages/react-native/ReactAndroid/api/ReactAndroid.api`.
Reviewed By: cortinico
Differential Revision: D58535868
fbshipit-source-id: 9eec33c5e798850a7434a6c391abf2fc3fc9d0a6
Summary:
Changelog: [Internal]
Showing warnings in LogBox is noisy, confusing for web developers, and not the best use of screen real estate on mobile platforms. Since the Fusebox console offers a superior experience, as of this diff we'll suppress warnings in LogBox if we detect that Fusebox is available.
*The first time* a warning is suppressed, globally (i.e. at most once per app launch), we'll show a notification pointing the user towards Fusebox. When the notification is clicked, we call the `DevSettings.openDebugger` method and dismiss it.
The wording of the notification ("Open debugger to view warnings") is intentional:
1. It's short enough to fit on small screens in its entirety.
2. It doesn't actually say "*click here* to open the debugger". This is for the best because `DevSettings.openDebugger` is a best-effort method that might fail, and in the current implementation there's no reliable feedback to the user about the success/failure of the launch.
Reviewed By: huntie
Differential Revision: D57681446
fbshipit-source-id: fe6101785780de3bc586ade11f471f7c74707be1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44934
Resubmission of D57681447 with an updated `ReactAndroid.api`.
---
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: huntie
Differential Revision: D58529832
fbshipit-source-id: e5510f529a19e0149d8dce04fa610e6c2371cc79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44910
Props within the `Text` component are accessed both via destructuring the props object but also in some cases by using a "dot" access on the destructured `restProps`. However in all of the "dot" access cases the property is being overrided. Which means in the final JSX these properties get set twice, e.g. via the `restProps` spread then overrrided by static properties. This change just destructures all values to avoid this inefficiency.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58446569
fbshipit-source-id: 12a800f5e2218a1d95d57cc689a4c79caab480b4
Summary:
This change removes the need for the trigger-react-native-release.js script.
Thanks to the migration to Github Actions, we can now leverage the GHA workflow UI to trigger a Prepare Release job that creates a github tag that will spin a new release.
The pro of this approach are:
- less code to maintain: instead of a complex trigger release scripts, we only have to maintain two very straightforward scripts for the CI
- easier to trigger a release: instead of running a script, we can now just use the GH UI
The `trigger-react-native-release` script was doing the following steps:
- check that we are in the release branch ==> Already implemented in the GHA workflow
- Gets the branch name (not needed) ==> the job will automatically run on the stable branch
- Check for unsent changes (not needed) ==> we are not in a local environment
- get the gh token (not needed) ==> You need to be logged in GH and have write access to the repo
- get the version ==> provided as a parameter
- fails if the tag is already there ==> Functionality added in the workflow
- Parse and validate the version ==> Functionality added to the action prepare-release action + the JS Script
- Compute the npmTag ==> Functionality added to the action prepare-release action + the JS Script
- trigger the release workflow ==> The GH UI does that for us
## Changelog:
[Internal] - Remove the trigger-react-native-release.js
Pull Request resolved: https://github.com/facebook/react-native/pull/44898
Test Plan: Testing in Production!
Reviewed By: cortinico, huntie
Differential Revision: D58461470
Pulled By: cipolleschi
fbshipit-source-id: 32bb0ee91370c9483a29e2ca2e18e24557d5fd53
Summary:
Add 0.72.15 to Changelog
## Changelog:
[Internal] [Changed] - Generated 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44904
Reviewed By: cipolleschi
Differential Revision: D58470819
Pulled By: cortinico
fbshipit-source-id: 20a1816811213ed9a69f1ede3579aa8fc661faf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44901
Point Gradle to the monorepo instead of a node_modules, as well as remove some commented out entries we're not interested in.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58287786
fbshipit-source-id: 92b3d15d05c55a2589bb8a6b75dc3d5d0f9756ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44647
Changelog: [Internal]
Adds a private API that gives JS the ability to trigger the same "open debugger" action as in the Dev Menu. This is in preparation for changes to LogBox.
For simplicity, this method operates on a best-effort basis - i.e. it doesn't report the success or failure (or failure reason) of the launch.
Reviewed By: hoxyq
Differential Revision: D57681447
fbshipit-source-id: ddb1fbd0f1c8d07bfa57d65c54e3a34bb7a470a8
Summary:
Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode. This is an important marker for TTI measurement.
## Changelog:
[ANDROID] [ADDED] - Add the `ReactMarkerConstants.CONTENT_APPEARED` support on Android in bridgeless mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/43620
Test Plan:
adding this on RNTesterActivity to see if the log is executed
```kotlin
ReactMarker.addListener { name, tag, instanceKey ->
if (name == ReactMarkerConstants.CONTENT_APPEARED) {
Log.i("XXX", "XXX")
}
}
```
Reviewed By: cortinico
Differential Revision: D58459930
Pulled By: rubennorte
fbshipit-source-id: 4498a3623c506d228aea995c8aeafdb51fcc5b96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44925
I have the suspect this is causing our builds to be slower and especially causing the template tests to take 6 hours.
Let's try to disable it.
Changelog:
[Internal] [Changed] - Do not publish Gradle Scans
Reviewed By: cipolleschi
Differential Revision: D58520463
fbshipit-source-id: 028e16a725ea87e178ed4e0bf134737f32780544
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44909
Today we wrap all `onPressIn` and `onPressOut` callbacks we pass to pressability so we can set the `highlighted` state. However highlighted state is only ever set to anything other that false on iOS. This change not only skips calling `setHighlighted(false)` on every press event but also skips wrapping the callback.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D58391419
fbshipit-source-id: e79f51469609a59063098501f015f8078e3db79f
Summary:
This PR solves [this issue](https://github.com/facebook/react-native/issues/44151).
Inverted FlatList doesn't work (elements cannot be clicked) when the list is scrolled.
## 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
-->
[GENERAL] [FIXED] - Fix clicking items on the inverted FlatList on the new architecture
Pull Request resolved: https://github.com/facebook/react-native/pull/44168
Test Plan:
# Steps
1. `buck2 install catalyst-ios` or `buck2 install catalyst-android`
2. Go to `RNTester Browser - Fabric` -> `FlatList` -> `Inverted`
3. Toggle inverted to `true`
4. Scroll to the top
5. Tap down and drag to either left or right
6. Expected is to have Red highlighted (which indicate Press Down) when dragged.
## iOS
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vCW | https://pxl.cl/53vDq |
## Android
| Before | After |
|-----------------------|----------------------|
| https://pxl.cl/53vFp | https://pxl.cl/53vFG |
## Reproducing steps from OSS
1. Use this reproducer: https://github.com/WoLewicki/reproducer-react-native/tree/%40wolewicki/flatlist-inverted
2. Apply changes from this PR & build the app.
3. Scroll a bit the list, so it changes the position.
4. The `onPress` should be fired when the button is clicked.
5. Do the following tests:
1. Add a `horizontal` prop to the FlatList - verify everything works.
2. Remove a `inverted` prop - verify everything works.
3. Remove a `inverted` prop and add a `horizontal` prop - verify everything works.
6. Test different combinations of transforms of the FlatList, example:
```javascript
<FlatList
inverted
horizontal
style={{
transform: [
{scaleY: -1},
{scaleY: -2},
{scaleY: -0.5},
{translateY: 20},
{translateY: -10},
{skewX: '10deg'},
{rotateX: '10deg'},
],
}}
/>
```
<details>
<summary>Reproducrer</summary>
https://github.com/facebook/react-native/assets/104823336/28cfe607-43e8-4f80-bbfb-59085ae0f986
</details>
<details>
<summary>RN tester</summary>
https://github.com/facebook/react-native/assets/104823336/e00cd488-d98f-4ece-9cab-b8a7212acb04
</details>
Reviewed By: arushikesarwani94
Differential Revision: D56441112
Pulled By: realsoelynn
fbshipit-source-id: 82c47f6bcc1f25cfbbd55aedf9652052bb86cf47
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44912
While moving from CircleCI → GHA, we're removing this blocking folks landing PRs and just running on main. We will re-enable once GHA is stable.
Changelog: [General][Changed] Disable GHA on PRs until it's stable
Reviewed By: NickGerleman
Differential Revision: D58478000
fbshipit-source-id: 053ee53455956bf19b6f9113cb796346359ad4ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44803
This change introduces a new prop to the Android `Image` component: `resizeMultiplier`. This prop can be used when the `resizeMethod` is set to `resize`, and it directly modifies the resultant bitmap generated in memory from Fresco to be larger (or smaller) depending on the multiplier. A default of 1.0 means the bitmap size is designed to fit the destination dimensions. A multiplier greater than 1.0 will set the `ResizeOptions` provided to Fresco to be larger that the destination dimensions, and the resulting bitmap will be scaled from the hardware size.
This new prop is most useful in cases where the destination dimensions are quite small and the source image is significantly larger. The `resize` resize method performs downsampling and significant image quality is lost between the source and destination image sizes, often resulting in a blurry image. By using a multiplier, the decoded image is slightly larger than the target size but smaller than the source image (if the source image is large enough).
It's important to note that Fresco still chooses the closest power of 2 and will not scale the image larger than its source dimensions. If the multiplier yields `ResizeOptions` greater than the source dimensions, no downsampling occurs.
Here's an example:
If you have a source image with dimensions 200x200 and destination dimensions of 24x24, a `resizeMultiplier` of `2.0` will tell Fresco to downsample the image to 48x48. Fresco picks the closest power of 2 (so, 50x50) and decodes the image into a bitmap of that size. Without the multiplier, the closest power of 2 would be 25x25, which is half the quality.
## Changelog
[Android][Added] - Adds a new `Image` prop `resizeMultiplier` to help increase quality of small images on low DPI devices
Reviewed By: javache
Differential Revision: D58120352
fbshipit-source-id: e0ebf4bd899170134825a29f72a68621447106c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44885
Cleanup accessibility related props checks to ensure we are doing the minimal amount of work. e.g. reduce duplicate `null` checks and shift checks to conditional branches that use them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58390430
fbshipit-source-id: f2c8989b6520cda9f14f9a04cd4fd6e126c501fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44877
Changelog: [Internal]
We're seeing a sporadic iOS crash that suggests `[RCTBridge dealloc]` is being called off the main queue (despite a comment suggesting it shouldn't be). This exposes a race condition between destroying the `HostTarget` and attempting to unregister the instance+runtime from it . Here we use `RCTExecuteOnMainQueue` to make sure the `HostTarget` destruction is always sequenced after the `unregisterFromInspector()` call.
Reviewed By: huntie
Differential Revision: D58415684
fbshipit-source-id: a22e239c80c3204fe32b9e73719ffaa131feaffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44911
This diff reverts D58288489
D58288489: [RN][Fusebox][iOS] Implement new HostTargetMetadata fields (iOS) by huntie causes the following test failure:
Tests affected:
- [fbsource//xplat/js/react-native-github/packages/react-native/ReactCommon/jsinspector-modern:testsAndroid - main](https://www.internalfb.com/intern/test/844425054538351/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5466028
Here are the tasks that are relevant to this breakage:
T191385299: 50+ tests unhealthy for react_native
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58475289
fbshipit-source-id: 3a4476d1350c4986cdb673bdb4ac52af353a00ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44495
## Summary
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, dark mode support, alignment of buttons, etc.
This change provides a fallback to the original `android.app.AlertDialog` if the current activity is not an AppCompat descendant.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57113950
fbshipit-source-id: ba5109c9d79b6ceb042ff93eebe796a2d14ebd63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44494
Pull Request resolved: https://github.com/facebook/react-native/pull/44880
Migrates the `AlertFragment` from `android.app.AlertDialog` to `androidx.appcompat.app.AlertDialog`. This backports tons of fixes that have gone into the AlertDialog component over the years, including proper line wrapping of button text, alignment of buttons, etc.
## For consideration
- Alert dialog themes may no longer need the `android` namespace, meaning themes can now be specified as `alertDialogTheme` rather than `android:alertDialogTheme`.
- This change requires all implementing activities to have a theme that inherits from `Theme.AppCompat`. Creation of any activities which do not have a descendant of this style will result in an `IllegalStateException`: https://www.internalfb.com/intern/signalinfra/exception_owners/?mid=5ee93f6ecd59f3d8ad82a78c213ea016&result_id=16044073705339118.281475102518721.1715097866
## Changelog:
[Android] [Changed] - Migrated `AlertFragment` dialog builder to use `androidx.appcompat`
Reviewed By: zeyap
Differential Revision: D57019423
fbshipit-source-id: 84d8f69d896d32e72434149c0e31735d358370a9
Summary:
This change migrates the GHA template jobs to the HelloWorld package for iOS.
## Changelog:
[Internal] - Move iOS template jobs to HelloWorld
Pull Request resolved: https://github.com/facebook/react-native/pull/44875
Test Plan: GHA are green
Reviewed By: cortinico
Differential Revision: D58459398
Pulled By: cipolleschi
fbshipit-source-id: 95404445d7375186860af5835b750b4735795434
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44811
Changelog:
[General][Fixed] - Debugger frontend socket-termination countdown now begins after the ping message is actually sent
The debugger is currently disconnected if a ping-pong message is missed.
This causes the debugger to be unusable if it happens to be lagging, e.g. when the initialisation is competing with the flood of log spam T191394188
There are a few ways to fix this as discused with motiz88 and robhogan:
1. Ensure the websocket has a chance to respond, e.g. in via web worker
1. Lengthen the time allowed for the pong resopnse
I've done some digging to find the root cause of the UI being blocked in CDT, However, profiling shows that most of the work is not simple to break up, i.e. the number of expensive re-layout calls. Diving into that rabbit hole could mean accidentally writing React.
Because we ping every 10 seconds, we could get un/lucky where CDT happens to be busy _at that exact moment_, making this a flaky symptom to fix, even if we lengthen the allowed time-to-respond.
# V2+
So upon further investigation, CDT websocket is actually responding to the pings in due time:
{F1679132204}
(CDT doesn't show the ping/pong API as frames, so a custom tick/tock message was used to visualise the timing)
Over here in dev-middleware, we currently start a timeout to terminate the socket after sending the ping:
https://www.internalfb.com/code/fbsource/[813870db697a8701f2512d25a7fed730f0ec6ed9]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/InspectorProxy.js?lines=306-307
If CDT doesn't respond in time, websocket would be terminated.
But we saw CDT respond immediately above, even during the log spam, so the delay must be coming from somewhere else.
The intuition is that during the log-spam, the middleware takes a perf hit too when it's processing the spam from the device and forwarding it to the CDT websocket.
We can confirm this by passing a "sent" callback via `socket.ping(cb)`:
https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/websocket.js#L246-L254
This gives us the timing between calling `socket.ping()` and when the ping is actually sent.
Regular, stress-free operation without log-spam shows most pings are sent within the same millisecond:
{F1679223326}
With the pong response grace period at 5 seconds, there's plenty of time for CDT to `pong` back. That's why it has been working in most cases.
However, during the log-spam, we easily see this send-sent delay over 5 seconds. In extreme cases, almost 30 seconds would have passed before middleware sent a message to CDT, which then responded under 2 seconds:
{F1679163335}
This means while CDT is getting flooded and has observable lag in the UI, the smoking gun is actually the middleware.
Digging a little deeper, we know that incoming messages from the target goes into a Promise queue, including the console logs:
https://www.internalfb.com/code/fbsource/[d5d312082e9c]/xplat/js/react-native-github/packages/dev-middleware/src/inspector-proxy/Device.js?lines=155-157
This means during the flood of logs from the target, the Promise queue keeps getting chained rapidly for each message.
Meanhile, the `ws` lib uses the underlying NodeJS `Socket.write` method for `ping(…)` and `send(…)`:
https://github.com/websockets/ws/blob/9bdb58070d64c33a9beeac7c732aac0f4e7e18b7/lib/sender.js#L349
…which is guaranteed to fire the callback asynchronously:
https://github.com/nodejs/help/issues/1504#issuecomment-422879594
Promise queue is in the macro task queue, which gets priority before the micro task queue. So if the Promise queue is not cleared yet, the websocket queue will have a hard time getting executed in time – explaining the extreme send-sent durations during a log spam.
The fix is simple:
1. Start the terminate-socket-timer until the `ping` is actually sent
1. Treat any incoming message (along with `pong`s) as a terminate-socket-timer reset
1. This also applies if `pong` comes in between `send` and `sent`, which can happen sometimes due to the async nature of the callback:
{F1679288626}
# V1
~~In this diff, a more forgiving mechanism is introduced, i.e. CDT is allowed to miss a ping-pong roundtrip 3 times before the websocket connection is terminated.~~
~~This allows a bit more breathing room for CDT's initialisation during log spam while maintaining the same ping-pong interval for VS Code to keep the auto SSH tunnel alive.~~
Reviewed By: huntie
Differential Revision: D58220230
fbshipit-source-id: 7111c9878492d8755a6110a5cdf4ef622265001d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44894
Adds the new CDP domain `ReactNativeApplication`, with the following messages:
- `ReactNativeApplication.enable` (method) — Sent by the connected frontend to enable features under this domain.
- `ReactNativeApplication.metadataUpdated` (event) — Sent by the backend containing a metadata object about the host.
We intend to use this for displaying richer information in the debugger frontend, such as device information and React Native version.
Changelog:
[General][Added] - Add `ReactNativeApplication.[enable,metadataUpdated]` CDP messages for reading host metadata
Reviewed By: motiz88
Differential Revision: D58288490
fbshipit-source-id: 02384f0cdfaa35f1c5de9fad7ddd5aab483b2768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44878
A refactor moving `SessionMetadata` (now renamed as `HostTargetMetadata`) out of `inspectorTarget->connect()` calls into a `HostTargetDelegate::getMetadata` method. This provides a cleaner interface and location for extending metadata fields in future.
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58288491
fbshipit-source-id: 67e8b9a3fb6d0b7966187fa98d9852222f242b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44897
changelog: [internal]
To get better understanding of where the time is spent, let's split IntBufferBatchMountItem systrace section into individual types.
Reviewed By: javache
Differential Revision: D58080444
fbshipit-source-id: d71dcc74a042c6c40270ca6f1dc7a8735c0471b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44895
Enables the new debugger stack (codename Fusebox) in RNTester.
This feature is experimental and is enabled for testing purposes only. This change **should not** be adopted as the default by React Native frameworks.
Changelog: [Internal]
Reviewed By: cortinico, rubennorte, NickGerleman
Differential Revision: D58366246
fbshipit-source-id: 809a1edb79ced4a7920457ed661cc3d863b35c7b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44879
This sets up publishing of Gradle scans for every build on GHA.
Changelog:
[Internal] [Changed] - Setup publishing of Gradle Scans on GHA
Reviewed By: blakef
Differential Revision: D58419361
fbshipit-source-id: f54365ad259324747248ef0bb726dc64964507f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44810
Adds an example how to use the `EventEmitter` on a (C++) Turbo Module
## Changelog:
[General] [Added] - Add C++ Turbo Module Event Emitter example
Reviewed By: javache
Differential Revision: D57473949
fbshipit-source-id: 1a8d17fb83af4220ef12379e0102b5b2e233ed45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44864
Switch the style normalizer checks to only do a single top level `null` check and remove unneeded flow suppression comments.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58386781
fbshipit-source-id: e4df6fdadb5bfab4c8ae674a420ac453ba262f78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44822
Changelog: [Breaking]
This is to make `getContentOriginOffset` to have `includeTransform` information passed during Layout computation.
Reviewed By: NickGerleman
Differential Revision: D58223380
fbshipit-source-id: 4faa1409d9c87e2c92118941aa193ba0a0f34367
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44809
Adding react-native-codegen parser support for a new `EventEmitter` property type on C++ Turbo Modules.
It is possible to later expand this feature to other languages (Java, ObjC).
## Characteristics
An `EventEmitter` must:
- be non null:
`EventEmitter<string>` works, `?EventEmitter<string>` does NOT
- have a non null eventType:
`EventEmitter<number>` works, `EventEmitter<?number>` does NOT
- have at most 1 eventType, `void` is possible as well:
`EventEmitter<>` or `EventEmitter<MyObject>` work - `EventEmitter<number, string>` do NOT
- have a concrete eventType, `{}` is not allowed
`EventEmitter<{}>` does NOT work
- be used in `Cxx` Turbo Modules only at this time
## Example
For these 4 eventEmitters in on an RN JS TM spec
```
+onPress: EventEmitter<void>;
+onClick: EventEmitter<string>;
+onChange: EventEmitter<ObjectStruct>;
+onSubmit: EventEmitter<ObjectStruct[]>;
```
We now generate this code:
1.) in the spec based header `{MyModuleName}CxxSpec` in the constructor:
```
... // existing code
eventEmitterMap_["onPress"] = std::make_shared<AsyncEventEmitter<>>();
eventEmitterMap_["onClick"] = std::make_shared<AsyncEventEmitter<OnClickType>>();
eventEmitterMap_["onChange"] = std::make_shared<AsyncEventEmitter<OnChangeType>>();
eventEmitterMap_["onSubmit"] = std::make_shared<AsyncEventEmitter<OnSubmitType>>();
```
2.) as `protected` functions
```
void emitOnPress() {
std::static_pointer_cast<AsyncEventEmitter<>>(delegate_.eventEmitterMap_["onPress"])->emit();
}
void emitOnClick(const OnClickType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnClickType>>(delegate_.eventEmitterMap_["onClick"])->emit(value);
}
void emitOnChange(const OnChangeType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnChangeType>>(delegate_.eventEmitterMap_["onChange"])->emit(value);
}
void emitOnSubmit(const OnSubmitType& value) {
std::static_pointer_cast<AsyncEventEmitter<OnSubmitType>>(delegate_.eventEmitterMap_["onSubmit"])->emit(value);
}
```
## Changelog:
[General] [Added] - Add EventEmitter code-gen support for C++ Turbo Modules
Reviewed By: javache
Differential Revision: D57407871
fbshipit-source-id: 2345cc6dacf0cb0d45f8a374ad9d4cbf8082f9d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44734
Fixes https://github.com/facebook/react-native/issues/44671
This integrates functionality for clipping content to padding box into `ReactViewBackgroundManager`, to be shared between several ViewManagers. In practice, this means:
1. `overflow: hidden` now works on `Text` and `TextInput`
2. ScrollView children are now clipped to the interior of borders, included curved ones via borderRadius
This will be made more generic, then start being used in ReactViewGroup, and eventually ReactImage. That abstraction will then hide away extra background management we will use for shadows.
Different places in code currently do clipping in any of `draw()`, `onDraw()`, or `dispatchDraw()`. The distinction between these, is that `draw()` allows code to run before drawing background even, `onDraw()` is invoked before drawing foreground, and `dispatchDraw()` is before drawing children. We don't want to clip out borders/shadows, but do want to clip foreground content like text, so I used `onDraw()` here.
Changelog:
[Android][Fixed] - Better overflow support for ScrollView, Text, TextInput
Reviewed By: rozele
Differential Revision: D57953429
fbshipit-source-id: ca3b788deb4b32706df7db958877d18f525c039c
Summary:
Before all React errors showed junk like this:

This is because `isComponentStack` detected a component stack but `parseComponentStack` couldn't actually parse it (it doesn't deal with React's current format like `in Foo (created by FeedItemInner)`) so `componentStack` was an empty array, resulting in the next block of code pushing stuff into `argsWithoutComponentStack` _again_, thus repeating its args.
The fix is not to do that. Result on my local copy:

Ofc this doesn't actually show the component stack but that was broken before too.
I edited in-place in my `node_modules` so I haven't verified this 100% works on main.
Hope this is useful!
## Changelog:
[General] [Fixed] - Remove accidental duplication in React warnings in Logbox
Pull Request resolved: https://github.com/facebook/react-native/pull/44812
Reviewed By: cortinico
Differential Revision: D58240357
Pulled By: rickhanlonii
fbshipit-source-id: b6ecb659d3b393e497caf5e7b2087a8e529f1b28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44808
Adds an `AsyncEventEmitter` class which can be used as a property of currently C++ only Turbo Modules to send type safe data back to JavaScript.
Adding support for ObjC / Java Turbo Modules is possible, straight forward and can be added as an afterthought.
It implements this interface
```
export type EventEmitter<T> = {
addListener(handler: (T) => mixed): EventSubscription,
};
```
## Hybrid
It is a 'hybrid' object.
1.) You `addListener(handler: (T) => mixed)` in JavaScript for emitted events (coming from C++, native code)
2.) You `emit(...Arg)` events in C++, native code (getting sent to JavaScript)
## Changelog:
[General] [Added] - Add EventEmitter C++ bridging type
## Facebook:
Apps usually create custom functionality to achieve this kind of behavior - e.g. https://www.internalfb.com/code/fbsource/[e72bd42a028a]/arvr/js/apps/RemoteDesktopCompanion/shared/turbo_modules/TMSubscription.h
Reviewed By: javache
Differential Revision: D57424391
fbshipit-source-id: 4999cafe9daeac125712a4bb7679d7acb9a6c389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44841
This change adds native support in Fabric for the remaining CSS cursor style values as defined here: https://developer.mozilla.org/en-US/docs/Web/CSS/cursor. Please note, this functionality is simply for prop parsing capabilities in Fabric, which are shared across all platforms. This does not add any additional cursor behavior support to iOS or Android, and the Flow and TypeScript types for cursor style values are still limited to `auto` and `pointer`.
## Changelog
[General][Added] Fabric prop parsing capabilities for all CSS cursor style values
Reviewed By: NickGerleman
Differential Revision: D58301970
fbshipit-source-id: 37ef8fcb4f62ac8c7613c7f6abcc48303953b71b
Summary:
Sometimes the events map can be a of type `SingletonMap` which will cause this code to throw exception when adding keys to it, so we change it to normal `HashMap`. Creating `SingletonMap` can especially happen in Kotlin when there is only one event added to a map, see:
https://github.com/plaid/react-native-plaid-link-sdk/blob/5ffab5eef576163528f0da504181162da3bef08b/android/src/main/java/com/plaid/PLKEmbeddedViewManager.kt#L21
## Changelog:
[ANDROID] [FIXED] - Cover SingletonMap when parsing events exported by module
Pull Request resolved: https://github.com/facebook/react-native/pull/42354
Test Plan: Create `getExportedCustomBubblingEventTypeConstants` as `SingletonMap` in some example module and see that the code does not throw.
Reviewed By: cipolleschi
Differential Revision: D58417266
Pulled By: cortinico
fbshipit-source-id: 6c46398ddf4d044386a36d0c1663bd071d642fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44874
While reviewing https://github.com/facebook/react/pull/29830, I noticed this file was committed with tab indentation in React Native. I have also used the `.gitignore` entry to clarify how `react-native.code-workspace` interacts with an optional user `.vscode/` config directory.
Note: The `json-stringify` parser can be used with Prettier 3+ only, so we use `json` instead.
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D58413581
fbshipit-source-id: 58c14db6648fed10736062b1f055475154aa74a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44835
As titled. The `vm` field is not part of the CDP spec and will not be used by the modern debugger frontend or proxy.
This change affects modern CDP targets only (using `InspectorPackagerConnection`). We aim to enable sharing of more detailed metadata over 1/ a new, dedicated CDP domain, and 2/ namespaced under the existing `reactNative` field (for the latter, strictly limited to metadata necessary for dev server functionality).
Changelog: [Internal]
(Note: `/json` endpoint behaviour is unchanged for legacy CDP targets)
Reviewed By: robhogan
Differential Revision: D58285587
fbshipit-source-id: dfef3a56b20486ba11891df9940f6c7bef59528e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44858
- Enables an opt-in to the Fusebox stack on Android for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58359907
fbshipit-source-id: d565dc8e00747dff56d3060e36e7f59e7dd2aec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44871
This re-enables and fix `test_android_template`.
The problem was that we were invoking `yarn install` inside the template after we already installed with `npm install --registry`.
So this was invalidating the Verdaccio setup and effectively fetching packages from NPM
Changelog:
[Internal] [Changed] - Fix test_android_template
Reviewed By: cipolleschi
Differential Revision: D58407941
fbshipit-source-id: 9b7b877cfc994eb8db1b5bf71dd35289c3937f5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44860
- Enables an opt-in to the Fusebox stack on iOS for both architectures in open source.
- Templates use of this opt-in in RNTester.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D58364053
fbshipit-source-id: c604b1589174bf7cfd0fe1bfb5624c4edd0a125d
Summary:
Seems like hermesc produced by GitHub Actions is not executable. This fixes it.
Changelog:
[Internal] [Changed] - Make hermesc executable
Reviewed By: cipolleschi
Differential Revision: D58407086
fbshipit-source-id: 84d7ba950b99214dfaed09a6aa499835fd01ede0
Summary:
Just doing some cleanup of the `.github/workflows` folder:
* apply-version-label-issue.yml hasn't been working since 0.72
* ios-tests is unnecessary as it's now covered by test-all
* nightlies-feedback.yml was experimental and last execution was ~5 months ago.
We can still recover them from the Git history if necessary.
## Changelog:
[INTERNAL] - Cleanup the .github/workflows folder
Pull Request resolved: https://github.com/facebook/react-native/pull/44857
Test Plan: Will wait for CI result
Reviewed By: NickGerleman
Differential Revision: D58362912
Pulled By: cortinico
fbshipit-source-id: d886e4f077eebfdf906169f09f96a950a361cab7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44865
This has not yet passed on main since we started testing on main two weeks ago: https://github.com/facebook/react-native/actions/runs/9316380994/job/25688028045
This change disables the GitHub Actions version `test_android_template` as a signal for PRs or diffs, since it isn't stable yet (but we still run it on main, and can manually dispatch it on any branch). This coverage is still enabled in CircleCI.
Changelog: [Internal]
Reviewed By: cortinico, alanleedev
Differential Revision: D58394745
fbshipit-source-id: 3227328b150a89b450d48784190f5d08d510cd1b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44821
Changelog: [Internal]
- Originally D37994809 was attempted to fix `Inverted FlatList` but was put behind Feature Toggle because it was causing problems in other scenarios.
- Later, D45866231 which was trying to fix scaling transform issue helped solve the issue attempted by the original diff.
- But after that points, Unit test around `computeRelativeLayoutMetrics` was having two variants where Feature Toggle for D37994809 was checked in with a wrong expected value.
- This diff revert D37994809 changes and clean up the unit test.
Reviewed By: NickGerleman
Differential Revision: D58197918
fbshipit-source-id: d8ae552018617e785e4010bc5805c53a875e02a3
Summary:
## Changelog
make RNTesterApp take a `customBackButton` prop to enable overriding whether to display back button and the look
by default, only ios platform has a back button, and android app relies on back button on navigation bar that comes with platform
[Internal]
Reviewed By: christophpurrer
Differential Revision: D58218208
fbshipit-source-id: 63a47390cc6d3de057b92a3c522c1b00d942c69d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44792
X-link: https://github.com/facebook/yoga/pull/1663
Fixing https://github.com/facebook/yoga/issues/1658. We had a problem where if a child had a different flex direction than its parent, and it also set a position as a percent, it would look at the wrong axis to evaluate the percent. What was happening was we were passing in the container's mainAxis size and crossAxis size to use to evaluate the position size if it was a percent. However, we matched these sizes with the main/cross axis of the child - which is wrong if the flex direction is different.
I changed it so that the function just takes in ownerWidth and ownerHeight then calls isRow to determine which one to use for the main/cross axis position. This reduces the ambiguity quite a bit imo.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58172416
fbshipit-source-id: eafd8069e03493fc56c41a76879d1ad9b7e9236d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44791
X-link: https://github.com/facebook/yoga/pull/1662
This should fix https://github.com/facebook/yoga/issues/1657. Rather insidious bug but we had code like
```
// The total padding/border for a given axis does not depend on the direction
// so hardcoding LTR here to avoid piping direction to this function
return node->style().computeInlineStartPaddingAndBorder(
axis, Direction::LTR, widthSize) +
node->style().computeInlineEndPaddingAndBorder(
axis, Direction::LTR, widthSize);
```
That comment is NOT true if someone sets both the physical edge and relative edge. So like paddingLeft and paddingEnd for RTL. This diff simply pipes the direction to that spot to use instead of hardcoding LTR. Every file changed is just to pipe `direction`.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D58169843
fbshipit-source-id: 5b4854dddc019285076bd06955557edf73ef7ec5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44852
This attempts to fix#44842 by capturing the accessed field in a new variable.
We don't have a way to reproduce this & this is a best guess fix.
Changelog:
[Android] [Fixed] - Tentative fix for NPE `JavaTimerManager$IdleCallbackRunnable.cancel`
Reviewed By: javache
Differential Revision: D58356826
fbshipit-source-id: d016df9a52f81a8d645a0a100c6bc6111841e24e
Summary:
This change migrates the prepare_release workflow from CCI to GHA
## Changelog:
[Internal] - Migrate from CCI to GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/44833
Test Plan: Test on GHA
Reviewed By: huntie
Differential Revision: D58289050
Pulled By: cipolleschi
fbshipit-source-id: 134fc7ffb66a18eec1187e14500daec2828cae61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44851
This method is available on the (deprecated) CatalystInstance interface, but not on ReactContext, even though it is trivially supported.
Changelog: [Android][Added] - Added getNativeModule(name) to ReactContext
Reviewed By: cortinico
Differential Revision: D58355135
fbshipit-source-id: 0cc76bb2da2b49510dc626cb8b3a3e93db5a16b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44823
Changelog: [internal]
This modifies the example for `IntersectionObserver` in RNTester to test that the API reports changes in intersection also coming from changes in layout (previously is was only from changes in scroll position).
Reviewed By: javache
Differential Revision: D58260057
fbshipit-source-id: 305d5996148730d718da30896f6cc62991b717f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44805
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: tdn120
Differential Revision: D58088036
fbshipit-source-id: 9c035a79cbb96db1cf3b5b5c36242df7453fe205
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44854
In the previous change, I followed the suggestion of the linter but in that case I shouldn't.
This was breaking circleci and GHA
This change will fix it
## Changelog:
[Internal] - Fix OSS CI
Reviewed By: huntie
Differential Revision: D58358164
fbshipit-source-id: eba1f41c17a191aa9d3bd213fddddd8ff3c24a6a
Summary:
As discussed with cipolleschi offline, this PR adds visionOS to the prebuilt Hermes binary for the CI.
## Changelog:
[IOS] [ADDED] - Prebuilt version of Hermes for visionOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44691
Test Plan: Check if CI builds xcframework for visionOS.
Reviewed By: cortinico
Differential Revision: D58189271
Pulled By: cipolleschi
fbshipit-source-id: dc76746b2c1e22670bef4c21411a598e43dad577
Summary:
I've noticed that nightly CI build was also running on my fork. I don't think this is necessary for every React Native fork (there are 24k of forks). This can save lots of unnecessary CI time.
## Changelog:
[INTERNAL] [FIXED] - Enable nightly run only on the main repo
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44844
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D58356192
Pulled By: cortinico
fbshipit-source-id: 1384d06708220d297e67d31433fcf3ac1d58bbbc
Summary:
While migrating from CCI to GHA, we mistakenly set the `ORG_GRADLE_PROJECT_reactNativeArchitectures` wrongly. The result was that the nightly was building only 1 architecture for android instead of all of them.
This change fixes that, but asking GHA to build all the architectures when running nightlies
bypass-github-export-checks
## Changelog:
[Internal] - Build all the architectures for android when running nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/44847
Test Plan: Run a nightly from the branch and see it working
Reviewed By: huntie
Differential Revision: D58347697
Pulled By: cipolleschi
fbshipit-source-id: 43a2b83ba9183e6f5a11d1e6f6a27df622ee8cc6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44850
I'm removing this line from settings.gradle:
```
import com.facebook.react.ReactSettingsExtension
```
and just using a fully qualified class name in the `configure{}` block
as imports cannot be conditionally included and is making hard for RNTA
to integrated those changes.
Changelog:
[Internal] [Changed] - Remove import of `com.facebook.react.ReactSettingsExtension`
Reviewed By: huntie
Differential Revision: D58354443
fbshipit-source-id: bc45516661318021a042e1c5921e28d7217cacbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44829
Another renaming that now we can merge to make clear what's the intent of this header.
Changelog:
[Internal] [Changed] - rncli.h -> autolinking.h
Reviewed By: javache
Differential Revision: D58284662
fbshipit-source-id: 7b69118f72d9b34a88ece7e0855918f5c717999a
Summary:
While writing some Jest tests, I noticed some instances of the following error:
```
Cannot read properties of undefined (reading 'remove')
```
Looks like there were two cases where the `{remove: () => {}}` return result was missing in the provided Jest mocks:
- `AccessibilityInfo.addEventListener`
- `Linking.addEventListener`
## Changelog:
[GENERAL] [FIXED] - Added missing `remove` methods for `Linking.addEventListener` and `AccessibilityInfo.addEventListener` Jest mocks
Pull Request resolved: https://github.com/facebook/react-native/pull/44270
Test Plan: N/A
Reviewed By: christophpurrer
Differential Revision: D58324784
Pulled By: robhogan
fbshipit-source-id: f46bd55db2517413f14182ae1bb81068d8d1e9f6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44828
I was using PackageList2 temporarily as I was migrating to Core Autolinking.
Now we can rename everything to `PackageList` to reduce the number of changes to the template for users.
Changelog:
[Internal] [Changed] - PackageList2 -> PackageList
Reviewed By: blakef
Differential Revision: D58284661
fbshipit-source-id: 8e1cc54e248519ece05336d79bb79e3f4ca706f4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44799
This is the final part of core autolinking:
1. I split RNGP into an `app-plugin` and a `settings-plugin`. This was necessary as the Gradle modules need to be loaded inside the settings.gradle.kts.
2. I've introduced a Settings Plugin to take care of either invoking the `config` command from CLI or receiving a file in input.
3. I've removed the former `RunAutolinkingConfigTask` as now the command is invoked inside the settings plugin
4. I've added hashing computed based on the lockfiles so we won't be re-executing teh `config` command if the lockfiles are not changed.
5. I've updated RN-Tester to use the core autolinking rather than manual linking for the 2 libraries it's using.
Changelog:linking
[Internal] [Changed] - RNGP - Autolinking. Add support for linking projects
Reviewed By: blakef
Differential Revision: D58190363
fbshipit-source-id: 6ab8b36729e77ca715f50a4a00aa0ca4eb5b63b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44818
Introduce a new data source for Perfetto. This one turns on the Hermes sampler, and at the end we flush the state to Perfetto.
This provides JS sampling data in Perfetto traces that can be used to easily spot JS performance problems not otherwise obvious.
Reviewed By: javache
Differential Revision: D57226087
fbshipit-source-id: 77c4a335bb462e73d74345eedc3fa634405bfd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44827
After D57856389 (#44684), the build is now firing an issue as `libmapbufferjni.so` is exposed as a public `.so` and we're missing a pickFirst directive.
Changelog:
[Internal] [Changed] - Add libmapbufferjni.so to pickFirst directives
Reviewed By: javache
Differential Revision: D58284481
fbshipit-source-id: d476bd5df8ec4687177df7a698cbb6595ce62565
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44831
The build_npm_package jobs remains sometimes in queue because there are not enough executors for it to run.
This makes our signals less reliable.
Plus, it is rebuilding part of Android, so it can benefit from a bigger machine
## Changelog:
[Internal] - Bump build_npm_package machine to more powerful ones
Reviewed By: cortinico
Differential Revision: D58284884
fbshipit-source-id: a29b7db843633ff3cfd9373cf4dbe55b24c939b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44830
Now that we have nightlies in GHA, we can safely remove them from CCI.
## Changelog:
[Internal] - Remove Nightlies from CCI
## Facebook:
Once this land, we need to disable the trigger in the CCI setting page.
Reviewed By: cortinico
Differential Revision: D58284941
fbshipit-source-id: 9a6ceb416de1d54f59f784a61509cd93f5684aaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44826
This was rolled out a while back, but some references remained.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58190612
fbshipit-source-id: e7884909959c98eb5617c9dee75f4ce53834b05c
Summary:
In order to host a ReactNative surface whose size is controlled by the RN content rather than the size of the surface, we need the ability to remove the flex:1 style on the root View component.
`SurfaceHandler` has layout functions which take a `LayoutConstraint` (so min/max size). The root View component in `AppContainer` has a hardcoded `flex:1` style. This view is above the `WrapperComponent`, which we can currently override. But I dont see anyway to avoid the root View having that flex style. This flex style means that the rootview will always be the maxheight passed into the layout functions on `SurfaceHandler`. Which prevents allowing RN surfaces that can size themselves based on their content.
This change adds a `setRootViewStyleProvider` method to `AppRegistry`, which works similar to `setWrapperComponentProvider` but allows apps to override the style property on the root View component. In particular, this allows apps to remove the flex:1 style, which is required to enable react surfaces which are sized based on their contents.
## Changelog:
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Added AppRegistry.setRootViewStyleProvider
Pull Request resolved: https://github.com/facebook/react-native/pull/44665
Test Plan: Will be including this change into react-native-windows to enable scenarios with content sized surfaces within Microsoft Office to work with the new architecture. Would like signoff on this direction before I go and integrate it there.
Reviewed By: javache
Differential Revision: D58138443
Pulled By: hoxyq
fbshipit-source-id: 95ab4842aa7f827867788d8787527f9675cf4fcc
Summary:
This change adds a separate workflow for Nightlies. This workflow do not run tests on iOS and Android and proceed to release a nightly.
**🚨 Important 🚨** We need to update the GHA secrets as there is none set.
_Note: This is a first step to ensure that we can release Nightlies from GHA. I'll factor out all the actions in following updates to cleanup and refactor once we know that everything works!_
## Changelog:
[INTERNAL] - Add nightlies workflow on GHA
Pull Request resolved: https://github.com/facebook/react-native/pull/44741
Test Plan:
1. Add the `pull_request` trigger to see the workflow start
2. Monitored the workflow to make sure that it worked
3. Tested the nightly locally
4. Removed the `pull_request` trigger, otherwise we would publish a nightly on each PR! xD
Reviewed By: cortinico
Differential Revision: D58084002
Pulled By: cipolleschi
fbshipit-source-id: 593145392fe686930ccb00beb68d9130b8401cbc
Summary:
Hi, I'm Filip from software mansion. This PR solves a problem I stumbled upon.
On iOS, applications are always in light mode on initial load. Even if the device is turned to dark mode.
### Cause of the problem:
The initial appearance is taken from `RCTKeyWindow()`, but at the time of initialization of `RCTAppearance` it does not exist yet.
### Solution:
This PR moves repeats initialization of the appearance the first time `getColorScheme()` is called if it was not initialized properly before.
## Changelog:
[IOS] [FIXED] - Fix dark mode on initial load.
Pull Request resolved: https://github.com/facebook/react-native/pull/44335
Test Plan:
- Create new React native app with `npx react-native@latest init AwesomeProjec`
- Run the application on iphone using simulator
- turn on dark mode using `cmd+shift+A`
- close application and run it again
### without changes:
The application will turn on in light mode despite the simulator being set to dark mode.
When you reload the application it works as expected (is in dark mode)
### with changes:
Works as expected
#### note:
any change to device ui settings will trigger a listener that will set appearance to correct state, so testing of this problem should happen in as isolated conditions as possible.
Reviewed By: cortinico
Differential Revision: D58189058
Pulled By: cipolleschi
fbshipit-source-id: 9a864f3d045e966bc88601f661d221c4796c5c95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44815
Remove our `test_ios_template` job for `test_ios_helloworld`.
NOTE: There needs to be a followup to do the same in our Github Actions.
Changelog: [General][Changed] use helloworld instead of template for CI tests.
Reviewed By: cipolleschi
Differential Revision: D57122797
fbshipit-source-id: 744c79230b716716fdfc234832f1eb241e091893
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44797
Noticed when profiling bridgeless that that every call into JS would be passed via a (default priority) background thread first. This is inefficient from a scheduling perspective. Instead use the Task's default/immediate executor to immediately execute the success callback on the current thread and avoid a thread change.
This diff adds a new feature flag, to use the immediate executor for any ReactInstance method that doesn't require further synchronization within ReactInstance. For most methods, this is indeed unnecessary as ReactInstance will synchronize internally by scheduling work on the JS thread.
Changelog: [Android][Added] Added featureflag to avoid additional background threads during execution
Reviewed By: cortinico
Differential Revision: D58186090
fbshipit-source-id: 67ffed2d34083a6b6e7871160a2f3d6f1967d630
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44767
Changelog: [Internal]
Fixes a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed.
The solution consists of two parts:
1. If a ReactHost / InstanceManager is asked to destroy itself while it contains no active ReactInstance / ReactContext, we destroy the `HostTarget` immediately.
2. Otherwise, if there *is* a live ReactInstance / ReactContext that has yet to be destroyed, we wait for that to happen before destroying the `HostTarget`. In practice, we do this by checking for the BEFORE_CREATE ( = Host destroyed) lifecycle state every time we destroy a ReactInstance / ReactContext.
Reviewed By: javache
Differential Revision: D58031215
fbshipit-source-id: 321c73e85afd17a1b38c63f73aee5ebb59c00686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44722
Add support for bundling, building and uploading on iOS. I've verified these locally and will enable on CircleCI to validate.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57915365
fbshipit-source-id: 1e73918b31f70d337de4d3aee934c8acf88c86d0
Summary:
This PR adds cocoapods utility to set `SWIFT_ACTIVE_COMPILATION_CONDITIONS` to DEBUG, which is set to this value by default (when generating a new native Xcode project).
This allows to use the `#if DEBUG` compilator directive in Swift to work out of the box, without any changes on user's side:
```swift
override func bundleURL() -> URL? {
#if DEBUG
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
#else
Bundle.main.url(forResource: "main", withExtension: "jsbundle")
#endif
}
```
## Changelog:
[IOS] [ADDED] - Set SWIFT_ACTIVE_COMPILATION_CONDITIONS to DEBUG
Pull Request resolved: https://github.com/facebook/react-native/pull/42330
Test Plan:
Run `bundle exec pod install` and check if the active compilation flags are populated:

Reviewed By: cortinico
Differential Revision: D58188103
Pulled By: cipolleschi
fbshipit-source-id: 64746f3c7bfbdf47c2dea5e5e8cb2962635b719b
Summary:
The new `customizeRootView` does not have the feature parity as `createRootViewWithBridge` where reusing RCTRootViewFactory to create a root view, it does not call `customizeRootView`. This PR moves the `customizeRootView` support from RCTAppDelegate into RCTRootViewFactory and improves the customizeRootView support.
## Changelog:
[IOS] [CHANGED] - Support `customizeRootView` from `RCTRootViewFactory`
Pull Request resolved: https://github.com/facebook/react-native/pull/44775
Test Plan:
Add customizeRootView to **packages/rn-tester/RNTester/AppDelegate.mm** and test whether RNTester has blue background color in both new arch and old arch mode.
```objc
- (void)customizeRootView:(RCTRootView *)rootView
{
rootView.backgroundColor = [UIColor blueColor];
}
```
Reviewed By: dmytrorykun
Differential Revision: D58179693
Pulled By: cipolleschi
fbshipit-source-id: 0fac9a1bd5b2583a2700b3a3d2c80d0f608c4481
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44721
For iOS builds of `react-native`, the [react-native-xcode.sh](https://www.internalfb.com/code/fbsource/[7ad79aae3e8bf565d53f087ac7f7b7622b19acec]/xplat/js/react-native-github/packages/react-native/scripts/react-native-xcode.sh) script is executed as one of the build phases. This phase bundles the JS application (dev or production).
I've updated this to use the new `bundle.js` script instead of calling the `react-native/cli.js`. This is identical except with how the config is captured:
{F1669960016}
This is similar to our approach with the Gradle plugin, giving Framework authors more control.
**Other:** formatting changes for the Privacy Manifest that Xcode keeps updating.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57915368
fbshipit-source-id: f52ea4b3cb94212ac97a3d7edeb68747418fe0a9
Summary:
Fixes a bug where page IDs would collide for multiple connected Android devices running the same React Native app. The `Secure.ANDROID_ID` key (not value!) was being substituted in the ID string (pre-hashing) — now this segment is fixed.
Changelog:
[Android][Changed] - Update constructor signature of `DevServerHelper`
Reviewed By: hoxyq
Differential Revision: D58134323
fbshipit-source-id: 859e2758108e266167205a777bb6a6e87ca0573b
Summary:
## Changelog:
[Internal] - Exclude the windows folder from View in React-Fabric podspec
## Facebook:
The `platforms/windows` folder is internal only, not synched with OSS.
However, the C++ linking was picking up some files from that folder when running RNTester on iOS using the OSS pipeline.
bypass-github-export-checks
Reviewed By: dmytrorykun
Differential Revision: D58182437
fbshipit-source-id: 5397fadbe96d5c2c7980fbf5e74ffab7b237b912
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44790
Was seeing crash due to:
> Abort message: 'terminating due to uncaught exception of type facebook::jni::JniException: java.lang.NoSuchMethodError: no non-static method "Lcom/facebook/react/bridge/ReactInstanceManagerInspectorTarget$
TargetDelegate;.onSetPausedInDebuggerMessage(Ljava/lang/String;)V"
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D58165901
fbshipit-source-id: ceafd5776933fca5abb2e2edcac5e5f677cb7f7d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44788
We disabled the event loop in RN on the main branch after we found some issues in the implementation. Those have been resolved already so we can re-enable it again.
For context, it's already enabled in the latest branch so this is just for main.
Changelog: [internal]
Reviewed By: cortinico
Differential Revision: D58146393
fbshipit-source-id: ab908ecbd507d7087137a36cad5cc917eb7b1311
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44765
Noticed this was not shared with open-source. Needs to be converted to Kotlin still.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58088583
fbshipit-source-id: 51d13f2faddc7bce297dda54f2dd23cefed6a588
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44779
We forked a copy of Bolts when we open-sourced bridgeless, but it contains many features we don't require, since we only use Tasks to orchestrate the bridgeless startup path.
The only meaningful change I made is removing the fallback on stack overflow from the immediate executor, which is not something we expect to hit during startup, and would be better surfaced as a StackOverflowException.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D58087989
fbshipit-source-id: a4908723a04bf47fdc38d91bf47df928b91456f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44766
Changelog: [Internal]
There is currently a lifecycle bug in both the Bridge (`com.facebook.react.bridge`) and Bridgeless (`com.facebook.react.runtime`) integrations of Fusebox in React Native Android, whereby `HostTarget::unregisterInstance` gets called after the `HostTarget` has been destroyed. This manifests as a handful of related C++ crashes depending on the exact circumstances and build flags.
This diff makes the bug trigger a Java assertion instead of a C++ crash for ease of debugging. The next diff in the stack will actually fix the lifecycle issue.
Reviewed By: hoxyq
Differential Revision: D58031217
fbshipit-source-id: 9301b34edf5e526cbc72d86e78b328d29c9921b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44778
We now have the Publish_bumped_packages in GHA, so we should not have two jobs in two different systems that perform the same publishing operation.
## Changelog:
[Internal] - Remove duplicated jobs from CCI
Reviewed By: cortinico
Differential Revision: D58131196
fbshipit-source-id: 408b0a76dff89e9d327fe56d1e6e4c13b55eb2bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44758
Changelog: [Internal]
Adding a unit test to verify that the shadow node references are correctly updated to reference the new shadow node instance after cloning.
Reviewed By: sammy-SC
Differential Revision: D57893880
fbshipit-source-id: 6e36ca3d1b159f7bafb084246f714f3bfec58c1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44773
Changelog: [Internal]
Update runtime shadow node references for cloning happening within `YogaLayoutableShadowNode` during layout. This will update the JS references to shadow nodes with the latest layout metrics used to render the component and improve layout cache usage on the next commit.
Reviewed By: sammy-SC
Differential Revision: D58000071
fbshipit-source-id: 373d41f37a81e81ab8f23006491027473493de61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44771
Changelog: [Internal]
Adding a feature flag for enabling runtime shadow node reference updates only for clones happening within `YogaLayoutableShadowNode` to support layout data changes.
Reviewed By: sammy-SC
Differential Revision: D58000072
fbshipit-source-id: 204c0488edb992511a4b33d098b9df1b04001b9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44770
Changelog: [Internal]
Any shadow node cloning happening outside the execution of the UIManagerBinding `cloneNode` function should update references held to the shadow node to reference the latest revision. All shadow node cloning not requested by the JS runtime should update the references to those shadow nodes within the JS runtime so that these would hold the latest state updated outside of the React renderer (i.e. state data and layout metrics).
This guarantees that the React renderer's current fiber tree holds references to the ShadowNode instances that acually were layed out and committed for rendering on the native side. Maintaining these references up to date on the JS current fiber tree allows to maximize layout cache usage on subsequent commits.
Reviewed By: sammy-SC
Differential Revision: D57860867
fbshipit-source-id: f13e3fa9ad501fb2c8a387fb58b6379d236d7c2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44772
Changelog: [Internal]
React native clones shadow nodes internally without providing the new instances to the React renderer (current fiber tree). To support updating the shadow node references held by the JS side, this diff wraps the returned shadow nodes and adds a link to the runtime reference on the shadow node instance.
This will allow for updating the shadow node references held within the JS runtime from the native side.
Reviewed By: sammy-SC
Differential Revision: D57860869
fbshipit-source-id: 1703f0cd0183e2760436920a122857e17fda8dbb
Summary:
This diff reverts D57878119
D57878119: [RN] [Android] Fix status bar height calculation for all cutout sizes by Abbondanzo causes the following test failure:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/fb4a/__tests__/dating/onboarding/fb4aDatingOnboardingSessionImpressionLogging-e2e.js](https://www.internalfb.com/intern/test/562949977559606/)
Here's the Multisect link:
https://www.internalfb.com/multisect/5267005
Here are the tasks that are relevant to this breakage:
T189149205: 17 critical tests unhealthy for oncall dating_react_native_sop
The backout may land if someone accepts it.
If this diff has been generated in error, you can Commandeer and Abandon it.
Changelog: [Internal]
Reviewed By: Abbondanzo
Differential Revision: D58053899
fbshipit-source-id: c65a1094259f85c8e6084b2f191ca1e4cd149510
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44702
Based on bgirard initial changes in D53478653, this creates an initial integration of the Perfetto SDK with the User Timing API, allowing performance information to be logged from JS to Perfetto traces.
We only enable this for Android right now, but may be able to leverage this on other platforms too in the future.
The logic in `initializePerfetto` may need to moved to another common target (eg reactperflogger) once we want to make this usable in other components, but keeping it scoped to User Timing for now.
Changelog: [Internal]
Reviewed By: bgirard
Differential Revision: D57881823
fbshipit-source-id: 11ba09cbc01a102a72eee65ce6d6aeca508e864a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44480
TextInputs' onTextInput callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists.
Fully remove references on JS side now that no older clients are emitting this event
Changelog: [General][Removed] Remove viewconfigs for onTextInput callbacks
Reviewed By: cipolleschi
Differential Revision: D57092733
fbshipit-source-id: 62dae37d8e8f155969a1ca65131d4ee9a1d5f1c4
Summary:
Based on https://github.com/facebook/react-native/issues/44723.
This PR removes some Old Arch build only jobs on iOS.
Some of the recent changes where unifying the build process across archs, so we don't have to build Old and New Arch
## Changelog:
[Internal] - Remove OldArch jobs when they are not required
Pull Request resolved: https://github.com/facebook/react-native/pull/44729
Test Plan: CCI is green
Reviewed By: cortinico
Differential Revision: D57975238
Pulled By: cipolleschi
fbshipit-source-id: ffd0ff0534f25019d501aa3862baee1442088784
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44733
We are returning a Path to callers, which shouldn't be mutated. This isn't really safe. Return a copy to external callers instead, if they need a path to work with.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57996157
fbshipit-source-id: 53cd95df6e2641d946f7c3fef40f6449b16ca5cb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44732
`getBorderBoxPath()` and `getPaddingBoxPath()` currently assume `updatePath()` will set a path, but this does not happen on Android 24 emulators where it seems like `onBoundsChanged` isn't called to set flag for needing update.
But, the current design tries to be lazy with path generation, and these are probably more expensive to clip, so we should really make these functions return nullable value, then fall back to rect, like the internals of `CSSBackgroundDrawable`, and how I misremembered these as working in the view code added originally in D57668976.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57951852
fbshipit-source-id: 33bc8f738950597822ae9026408ab3a23b0923f3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44668
Enables regenerator for `hermes-canary`. Along with the previous diff, regenerator is the only difference between `hermes-stable` and `hermes-canary`.
Reviewed By: motiz88
Differential Revision: D57742907
fbshipit-source-id: ca14cb50fe976744c7fa2c0b3397e81661359f15
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44728
This makes them identical so the diff that makes them diverge is clear.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D57970711
fbshipit-source-id: 8586ef202ad27796918378832fa62df1708a0218
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44744
Correctly handle TurboModule promise rejections when there is no Exception message.
Changelog: [Android][Fixed] Android exceptions without a message would lead to unexpected crashes
Reviewed By: fabriziocucci
Differential Revision: D58014797
fbshipit-source-id: c94042818a00669a1be2db8e89e84c6b616efbec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44697
Google has discouraged attempting to read the `status_bar_height` resource [since 2017](https://youtu.be/_mGDMVRO3iE?si=qGQd7gLa_qTmfLGL&t=1079). With the introduction of display cutouts there can be a mismatch between the resource value and the true status bar size (and issues like [this one](https://github.com/facebook/react-native/issues/33612) popped up). The recommended approach is to instead call `getInsets` with the proper status bar and navigation flags provided by `WindowInsets`. On older APIs where `getInsets` is not supported, we have access to `systemWindowInsetTop`.
Changelog:
[Android][Fixed] - Fixed StatusBar.currentHeight calculations to honor all cutout sizes
Reviewed By: cipolleschi, alanleedev
Differential Revision: D57878119
fbshipit-source-id: 9fadd33d5f9b617a70a052c98dbd53fd29281650
Summary:
Changelog: [General][Fixed] Fixed LogBox not showing correctly on the New Architecture
We found an incorrect behavior in the event loop, where an error in a task would prevent its microtasks from running. This isn't spec compliant and should be fixed.
This caused LogBox to not work correctly, as error reporting is implemented via microtasks that would never execute.
Reviewed By: sammy-SC
Differential Revision: D58010521
fbshipit-source-id: 7901c5d6e83fb63af148e12ad6c32be490a3999d
Summary:
In the previous months, we worked with a GH engineer to run our test workflow on PRs. The workflow was running properly, so we want to run it on main too.
## Changelog:
[Internal] - Run gha on main too
Pull Request resolved: https://github.com/facebook/react-native/pull/44723
Test Plan: GHA is green
Reviewed By: cortinico, NickGerleman
Differential Revision: D57975230
Pulled By: cipolleschi
fbshipit-source-id: 89d06361ad6f2230b7000e05970e9b16539c9164
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
https://github.com/facebook/react-native/issues/44486 for Android
## Changelog:
[Android] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44526
Test Plan:
Added test in RN-Tester TurboModule test case
{F1660267530}
{F1660287029}
Reviewed By: javache
Differential Revision: D57223328
Pulled By: philIip
fbshipit-source-id: d4a69a16f6ce77c0a0fd63f008bea929b1964ab8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44709
Add some extra logging to try to figure out heisenbug, where we cannot find MapBuffer key that we should expect to be present, only during view preallocation.
ReadableMapBuffer toString() will itself iterate through MapBuffer entries, so this might not return something sane if underlying MapBuffer is corrupt or wrongly oriented, but should give us more context.
We also need to be careful here, to avoid logging the actual state mapbuffer or its binary which may contain text content. Only the paragraph attributes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57925730
fbshipit-source-id: cecca1a1fe53b4b417d520e65c30d47243cb2fb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44707
Changelog: [Internal]
For DrawerLayoutAndroid in New Architecture, when we use ReactDev Tools layout inspection, incorrect node is being shown in the inspector tools.
This is because pointerEvents is not set to either `box-none` or `none` based on the drawer open/close state for the drawer child wrapper `View`.
Reviewed By: hoxyq
Differential Revision: D57873834
fbshipit-source-id: b2b82633969922189a0b96feea2115ddc0b2ebb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44726
Changelog: [internal]
## Context
We ran an experiment to test synchronous state updates in Fabric and we saw some crashes on Android. Those crashes were caused by mounting operations not being applied in the correct order.
There were 2 root causes for that problem:
1. State updates triggered during mount would be committed and mounted synchronously during that specific mount operation. That caused problems like trying to clip views that weren't created already (as we were processing the state update for the content offset before we actually created the child views).
2. Same problem as before, but with mount operations that were processed when the root view wasn't available yet (this is a separate queue).
We tried to fix the problem in https://github.com/facebook/react-native/pull/44015, but the solution for 2) was incorrect, as we didn't account for those operations being in a different queue (it was reverted in https://github.com/facebook/react-native/pull/44724).
## Changes
I think the right solution for point 2) is that, instead of marking the root view as available and then process all pending operations, we flip those operations.
That was, if there are any mount operations as a side-effect of processing that queue, those will also be added to the same queue, instead of being processed immediately in `MountItemDispatcher`.
Reviewed By: sammy-SC
Differential Revision: D57968937
fbshipit-source-id: 93d10cdeced0c837d4301768aee8575d2c940b10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44725
Changelog: [internal]
## Context
We're currently testing synchronous state updates in Fabric (committing shadow trees for state updates synchronously in the thread where they were dispatched, instead of always scheduling it in the JS thread).
In these experiments we saw a problem caused by a recent change in the Android mounting layer (done to fix a problem with the Event Loop) where we were doing the mount operations inside a mutex lock. The problem is that we didn't have recursive commit+mount operations (because we were dispatching state updates in the JS thread) but now that we do we get a deadlock here.
{F1659804385}
These recursive commit+mount operations happen because it's possible to trigger state updates while we mount changes in the host platform (e.g.: we create the scroll view and we update the state to set the content offset). Those state updates trigger more mount operations, which deadlock in the mentioned place.
## Changes
This fixes the described issue by restricting the lock only to access the list of pending operations, but not to apply them. In the current implementation, `mountingManager->executeMount` is protected by the lock, whereas in the new version it isn't (so it can be safely called recursively). The synchronization of the mount operations is done directly at the mounting layer on Android.
Reviewed By: sammy-SC
Differential Revision: D57968936
fbshipit-source-id: 52f996d212cad691646610632b03b5223e7e90ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44724
Changelog: [internal]
Batching operations at this layer was wrong because these are the operations that were already flushed by the mounting layer but were accumulated in `SurfaceMountingManager` because the root view wasn't created.
These operations should be executed before anything else that's scheduled in the `MountItemDispatcher`, so we should never batch them. The problem this was trying to solve is solved in a different way in D57968937.
This was gated so this shouldn't affect any current usages.
Reviewed By: sammy-SC
Differential Revision: D57968939
fbshipit-source-id: e9131614cdc76e9d553540757611bc8b0736c927
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44727
This is a re-land of https://github.com/facebook/react-native/pull/44048
Reverting it caused even bigger regression, so my earlier assessment was wrong. The initial regression was caused by something else.
Changelog: [Internal] - Let's keep the changelog entry form the original diff.
Reviewed By: fkgozali
Differential Revision: D57970133
fbshipit-source-id: c683d661a805d44434f5491e89dd4b7218379bee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44716
Move to listr2 which handle non-TTY environment, outputting to CircleCI logs in a useful way. This gives our CI users more useful debugging information, but limits the output when running locally.
If you want more explicit output locally, do something like:
```
yarn run build | cat
```
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D57915369
fbshipit-source-id: ae9f87b0b9608f16ee035b791c5f7b81544c498c
Summary:
On React Native macOS (I am not sure with the current state of React Native), the Xcode Unit and Integration tests are a bit flaky. Rather than set "retry on failure up to 3 times" through the pipeline config (in our case, Azure Pipelines), I realized my earlier PR to use Xcode test plans (https://github.com/facebook/react-native/pull/36443) means we can have Xcode retry the test. This should be faster than retrying it on the pipeline, because it retries just the failing test, not the entire "test" step. I did this on React Native macOS, so I'm doing it upstream so we can remove a diff.
## Changelog:
[INTERNAL] [CHANGED] - Set `retryOnFailure` for Xcode Unit and Integration tests
Pull Request resolved: https://github.com/facebook/react-native/pull/44642
Test Plan: CI should pass (faster)
Reviewed By: cortinico
Differential Revision: D57662523
Pulled By: cipolleschi
fbshipit-source-id: 8de2ab0ea15ba4d38c3b5bf96108c0c7ff5e9f32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44708
Changelog: [internal]
We had a fallback to use a Hermes internal API if the native module exposing `queueMicrotask` wasn't available. This is no longer necessary as the module is available everywhere we enable the event loop, so we can remove it.
Reviewed By: christophpurrer
Differential Revision: D57922076
fbshipit-source-id: 0ca48abacd77a75ce8559db08f55c78a3e0ec815
Summary:
Add synchronous JS bindings installation for TurboModules. That would help some 3rd party JSI based modules to install JS bindings easier.
Re-create from https://github.com/facebook/react-native/issues/43110 but for iOS
## Changelog:
[IOS] [ADDED] - Add BindingsInstaller for TurboModules
Pull Request resolved: https://github.com/facebook/react-native/pull/44486
Test Plan: Added test in RN-Tester TurboModule test case
Reviewed By: javache
Differential Revision: D57224891
Pulled By: philIip
fbshipit-source-id: fabe5c4f8d2087ac9a465f2cb90d884b83265a68
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44705
`focusable` props behaviors are inconsistent across different flavors of Touchable components. Some use the disabled prop to check if the component should be focusable, others do not.
This ensures all Touchable* component flavors use the disabled prop.
## Changelog
[General][Fixed] Fixed inconsistency in TouchableX component disabled / focusable behavior
Reviewed By: yungsters
Differential Revision: D57910488
fbshipit-source-id: af17227403338fcd5bebd9ba7c3172b4c6776e1f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44706
We didn't ship this, and asking around, I don't think mdvacca was looking at this actively (though is on PTO right now).
Changelog: [Internal]
Reviewed By: rozele
Differential Revision: D57913491
fbshipit-source-id: 86afd5a6bb5e7ce6be540f2295aa407134a6d81c
Summary:
Expose host delegate methods that users can do some customize work.
## Changelog:
[IOS] [ADDED] - Bridgeless: Expose host delegate methods
Pull Request resolved: https://github.com/facebook/react-native/pull/44158
Test Plan: Users can do some customized work by `RCTRootViewFactory`.
Reviewed By: sammy-SC
Differential Revision: D56521470
Pulled By: cipolleschi
fbshipit-source-id: dd22d0978b9fd4385380945a514eb6596b7d874f
Summary:
XCode privacy files might not contain a `NSPrivacyAccessedAPITypes` key, which causes the following error:
```
[!] An error occurred while processing the post-install hook of the Podfile.
undefined method `each' for nil
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
```
## 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
-->
[IOS] [FIXED] - Privacy Manifest aggregation failing due to no `NSPrivacyAccessedAPITypes` key
Pull Request resolved: https://github.com/facebook/react-native/pull/44628
Test Plan: I tested this patch on our own app and it solved the issue.
Reviewed By: christophpurrer
Differential Revision: D57618425
Pulled By: cipolleschi
fbshipit-source-id: 1a36ab5a1bb45b8507d3663b782c95258d97c8a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44699
Changelog: [Internal]
In Fabric, overflow props for ScrollView is not passed down. Hence, the overflow props is ignored and FlatList content is always clipped.
Reported from OSS https://github.com/facebook/react-native/issues/44683
Reviewed By: sammy-SC
Differential Revision: D57895399
fbshipit-source-id: 6ce65bea0803971060e8229b66563123dd6fc114
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44695
Changelog: [internal]
We tested this feature flag at Meta and it's neutral when used outside the event loop. We'll handle its effects on the event loop as part of the event loop experiment itself (when enabling paint blocking).
Reviewed By: tdn120
Differential Revision: D57861195
fbshipit-source-id: 11a208ef5433321a464cfc16f4ff026d52988b42
Summary:
Currently, if the `Animated.sequence` animation is finished, and then the `start()` method is called without a `reset()` method being invoked beforehand, the failure happens: ```undefined is not an object (evaluating 'animations[current].start')```.
Use cases:
- sequence animation started, finished, and then started again
- sequence animation is used in `Animation.loop` with `resetBeforeIteration` set to `false`, which essentially does the same as the previous case
Related issues:
- https://github.com/facebook/react-native/issues/43120
- https://github.com/facebook/react-native/issues/37611
## Changelog:
[General] [Fixed] - Fix sequence restart failure
Pull Request resolved: https://github.com/facebook/react-native/pull/44031
Test Plan: Test cases are included: 1 for regression and 2 for mentioned use cases in the summary
Reviewed By: cipolleschi
Differential Revision: D56015346
Pulled By: dmytrorykun
fbshipit-source-id: 8b0f46c8a33397fece807634463ce630c89d28af
Summary:
When running the Analyzer in Xcode, I got a warning denoting that `viewDidLoad` was not called on `super` in the overridden `RCTRedBox.viewDidLoad`. While I have not observed any anomalies, it is best practice to call on super in the overridden view controller life cycle methods.
## Changelog:
[iOS] [FIXED] - Add missing call to `[super viewDidLoad]` in `RCTRedBox.mm`.
Pull Request resolved: https://github.com/facebook/react-native/pull/44686
Test Plan:
Running the RNTester yielded the following screenshot:
<img width="549" alt="Screenshot 2024-05-27 at 11 26 40" src="https://github.com/facebook/react-native/assets/2263015/b91e126c-9dc1-4e52-8a6b-50ea8bea2c3f">
Reviewed By: fabriziocucci
Differential Revision: D57856354
Pulled By: javache
fbshipit-source-id: d76a4779e02f40af69eed156489e57299968d4be
Summary:
The `mapbufferjni` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `mapbufferjni` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/44684
Reviewed By: fabriziocucci
Differential Revision: D57856389
Pulled By: javache
fbshipit-source-id: 9926b02724950f4025c7f867257e8229d44c43a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44655
Required to compile with clang
This is because previously it was comparing size_t with int which is not allowed under compilation with clang
Changelog: [Internal] [Fixed] - Replaced old style for loop with new style to avoid clang errors with size_t to int comparisons
Differential Revision: D57721635
fbshipit-source-id: 2738f7b415d668c37536f7f93b2e0985fa2cc5e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44672
Swaps out and simplifies the internals of the debugger launch flow.
We observed that we could achieve better launch/windowing behaviour by passing the `--app` argument directly to the detected Chrome path.
This shares the user's default Chrome profile:
- Fixes unwanted behaviour such as a separate dock icon on macOS (which, when clicked, would launch an unwanted empty window).
- Enables settings persistence.
This change also removes the `LaunchedBrowser.kill` API.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57726649
fbshipit-source-id: fc3a715dc852a50559048d1d1c378f64aeb2013f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44638
Reverts the debugger launch flow to use the default `ChromeLauncher` profile. This is the approach used in the current `--experimental-debugger` experiment and by Expo.
This is motivated after a review of the tradeoffs of a guest profile — which allow us to programatically quit the browser process, however takes over system URL handling.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D57619542
fbshipit-source-id: 3713e1cf8eed61e7a70ed1e4eb58f02da845155f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44496
When doing performance profiling on a React Native iOS app and trying to identify bottlenecks on the native side it can be helpful to correlate actions to what is happening inside React Native. We already have the SystraceSection class for this, but it does nothing in open source. This diff allows SystraceSection to feed into the Instruments signpost API on iOS/macOS.
Changelog:
[iOS][Added] - Add Instruments signposts API for SystraceSection
Reviewed By: sammy-SC
Differential Revision: D56280451
fbshipit-source-id: 4e962e932b6b6e09e5953abdc1aa621a2723c91e
Summary:
This PR adds percentage support in translate properties for android. Isolating this PR for easier reviews.
## Changelog:
[Android] [ADDED] - Percentage support in translate
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/43193
Test Plan:
- Checkout TransformExample.js -> Translate percentage example.
- Added a simple test in `processTransform-test.js`. The regex is not perfect (values like 20px%, 20%px will pass, can be improved, let me know!)
Related PRs - https://github.com/facebook/react-native/pull/43191, https://github.com/facebook/react-native/pull/43192
Reviewed By: joevilches
Differential Revision: D57723216
Pulled By: NickGerleman
fbshipit-source-id: c9da007678341b62745df858f043821bcc662a98
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44646
We can remove most of the code for clipping children to border radius, and recalculating paths, in ReactViewGroup, and rely on the padding box path/rect already set.
I will move this to something more generic up the stack so other native components can reuse this logic.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57668976
fbshipit-source-id: 8b8cf956dc8689827bccba5e41751b465fd85eeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44590
emitDeviceEvent is frequently used for perf-critical operations such as sending network responses from native to JS. We don't need to go through JavaScriptModule Proxy (which is missing caching in bridgeless) and instead can immediately invoke the callable JS module.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D57435750
fbshipit-source-id: 1c120073ac80afd95deb8e3e6f1c00c2d3d80133
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44576
Store callable modules as either a factory function or an object, so we can skip invoking the factory function for frequently accessed objects.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57338528
fbshipit-source-id: cd39ccbe7168c6f093a0e62d5880cbbcd5209c8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44631
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module enums
This is a follow up to https://github.com/facebook/react-native/pull/44630
This changes the names of C++ Turbo Modules enums to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export enum EnumNone {
NA,
NB,
}
export interface Spec extends TurboModule {
+getStrEnum: (arg: EnumNone) => EnumStr;t
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxEnumNone
^^^
```
Now the generate name is:
```
NativeMyAbcModuleEnumNone
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
Reviewed By: cipolleschi
Differential Revision: D57602082
fbshipit-source-id: 9ebd68b8059dfbc6e2ec11065915cf049aa3cb0b
Summary:
In https://github.com/facebook/react-native/pull/37510, a check was introduced to check if user is using `latest` version of `npx`, but right now it checks for every command executed, but it should only ensure that `latest` is included when creating a new project.
In this Pull Request I've added a condition to only warn if `init` was fired.
## Changelog:
[GENERAL] [FIXED] - Warn only in `init` command when CLI uses cached `npx` version
Pull Request resolved: https://github.com/facebook/react-native/pull/44644
Test Plan: Warning about using `latest` version CLI should only be presented when running `init` command.
Reviewed By: arushikesarwani94
Differential Revision: D57681864
Pulled By: blakef
fbshipit-source-id: 5c81b9a08141396efcd24539b2560cea16028dd9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44650
Changelog: [Internal]
Adds the missing `DoNotStrip` annotations to methods of `CxxInspectorPackagerConnection.DelegateImpl` that are called from C++.
Reviewed By: huntie
Differential Revision: D57708376
fbshipit-source-id: 8a72b19211b60ce7a6049079e5ecfc2e96bc974f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44630
Changelog:
[General][Breaking] Use hasteModuleName for C++ Turbo Module structs
This changes the names of C++ Turbo Modules structs to use the `hasteModuleName`.
Example: `NativeMyAbcModule.js` with this spec:
```
export type ValueStruct = {
x: number,
y: string,
z: ObjectStruct,
};
export interface Spec extends TurboModule {
+getValueStruct: () => ValueStruct
}
export default (TurboModuleRegistry.get<Spec>('MyAbcModuleCxx'): ?Spec);
```
Before now we generated a base C++ struct with the name:
```
MyAbcModuleCxxValueStruct
^^^
```
Now the generate name is:
```
NativeMyAbcModuleValueStruct
^^^^^^
```
## Changes:
- No `Cxx` injected anymore
- Ensure base struct is `Native` prefixed (all RN JS TM specs start with it)
## Why?
- The `Cxx` extension is a temporary hint to react-native-codegen to enable extra capabilities and might disappear eventually
- The C++ base struct name should be 'stable'
- The name of the exported TM JS spec `TurboModuleRegistry.get<Spec>(...)` is abritrary, the hasteName is not
- The name of the RN JS TM spec must start with `Native` which better guarantees a consistent naming scheme for these generated base class
- The C++ Turbo Module base class has now the same prefix as the generated structs - `NativeMyAbcModule` for the example above
Reviewed By: cipolleschi
Differential Revision: D57599257
fbshipit-source-id: 4fafe6c7e920737fa766bd7e8e68e521f608e775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44620
We added a log message when trying to lock revisions in `LazyShadowTreeRevisionConsistencyManager` when they were already locked, and we've seen that being logged in existing experiments, which could indicate we're doing re-entrance from the JS runtime.
This protects against that case migrating the boolean flag to an integer.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57509193
fbshipit-source-id: 1712aa84d665c9dfe50630818e7f56de7d7e145c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44619
Some methods in `LazyShadowTreeRevisionConsistencyManager` can be called in parallel when using synchronous state updates (which is also behind a flag). This implements thread-safety to cover that case so we don't have issues when testing that variant in production.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D57506540
fbshipit-source-id: 362e1df534bc8c87289882236cfe0d7ee261f507
Summary:
Changelog: [Internal]
bypass-github-export-checks
Currently, Hermes never generates object/array previews for values logged via the `console` API. This makes console logs significantly less readable than in Chrome. Here we enable the preview generation machinery that already exists in Hermes.
We conservatively mimic V8's behaviour of [only generating previews for immediately-emitted messages](https://source.chromium.org/chromium/chromium/src/+/main:v8/src/inspector/v8-console-agent-impl.cc;l=53,64;drc=451a101b0a8bbc323dbf5697dd956b55284ec9ee) and not for buffered messages. I don't know *why* V8 does this, but can only guess it's meant to improve the performance of starting a debugging session, by evaluating less code and sending smaller payloads. (Anyway, we can change our decision later.)
Reviewed By: dannysu
Differential Revision: D57617059
fbshipit-source-id: 1f5a71ce98ac915a5b874ed6c009d971405a9f2d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44637
Setting the wrong thing to {}. `result` should be set here just like in the other early returns.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57617046
fbshipit-source-id: e47dbdb7821879ffa02d11b7e68eec1c9bfbdefd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44226
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55964787).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: cortinico
Differential Revision: D56064036
fbshipit-source-id: 2e380bf7ee46892c5fc0044b03a929f12d122157
Summary:
Goal of this PR is to optimise `Pressable` component, similarly to https://github.com/react-native-tvos/react-native-tvos/pull/724 . `Pressable` `style` and `children` properties can, but doesn't have to be functions. Usually we passing objects or arrays. `pressed` state is used only when `style` or `children` are `functions`, so let's update that state only in such case, otherwise let's skip state updates to improve the performance.
That way we won't have to rerender the component when it is being pressed (assuming that `style` and `children` are not going to be functions)
## Changelog:
[GENERAL] [CHANGED] - Improve performance of `Pressable` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44615
Test Plan: Verify that `Pressable` updates its `pressed` state when `style` or `children` are functions.
Reviewed By: javache
Differential Revision: D57614309
Pulled By: fabriziocucci
fbshipit-source-id: 473e0ab3c4bf7b3ef04ba19f76105ac65371a3fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44582
D54496604 fixed lifecycle methods for JavaTimerManager, which now reveals another bug. Because this codepath ends up creating a `HeadlessJsTaskContext` which in turn creates a `Handler`, ReactInstance destruction doesn't complete cleanly.
```
2024-05-15 17:42:52.935 12681 27113 W fb4a.BridgelessReact: ReactHost{1}.getOrCreateDestroyTask(): React destruction failed. ReactInstance task faulted. Fault reason: Can't create handler inside thread Thread[pool-51-thread-1,5,main] that has not called Looper.prepare(). Destroy reason: FbReactInstanceHolder.destroyReactManager(): FbReactInstanceLogoutCleaner.clearReactInstanceData()
```
The fix is to not create our own Handler, but instead use the shared methods in UiThreadUtil.
Changelog: [Android][Fixed] Fixed error thrown during ReactInstance teardown
Reviewed By: cortinico
Differential Revision: D57378247
fbshipit-source-id: a31dc8e35b5418a71b83c301973f12350f2ee01b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44633
`toDynamic` no longer exists for ParagraphState, so try the MapBuffer value first, before triggering the error introduced in D56963463.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57439386
fbshipit-source-id: 31e6466d9dec5b835551cca6c946b28cfbd4578b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44626
This variable is unused and is shadowed by a function local.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57568098
fbshipit-source-id: e5f56b7ef88497d4b9935275eb7e805660741146
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44237
This adds support for color function values to ColorPropConverter per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It updates the color conversion code so that it returns a Color instance before ultimately being converted to an Integer in preparation for returning long values as needed.
## Changelog:
[ANDROID] [ADDED] - Update ColorPropConverter to support color function values
Pull Request resolved: https://github.com/facebook/react-native/pull/43031
Test Plan:
Colors should work exactly the same as before.
Follow test steps from https://github.com/facebook/react-native/pull/42831 to test support for color() function syntax.
While colors specified with color() function syntax will not yet render in DisplayP3 color space they will not be misrecognized as resource path colors but will instead fallback to their sRGB color space values.
---
After the failure with the tests, I reapplied the changes and test some Jest e2e tests that were failing yesterday:
{F1495277376}
Reviewed By: cortinico
Differential Revision: D56517579
Pulled By: cipolleschi
fbshipit-source-id: ae9b5bc2afe9eb9760dd91afb090385daf7102b8
Summary:
D57197676 reordered the TextExample test cases, but accidentally reused the same string as the case in packages/rn-tester/js/examples/Text/TextInlineViewsExample.js
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57279961
fbshipit-source-id: 60a41eaf13d82538ee149fe4ef5531e42c00b012
Summary:
tsia. Done to allow for easier interaction of the examples, especially those with long descriptions
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57278607
fbshipit-source-id: f0a1d06c97c019fe177c8b9e51c3ca0ae12caef5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44552
Changelog: [Android][Fixed] If the RNTester app is started with a deeplink intent, we now correctly navigate there for Android to facilitate e2e testing. This already worked on ios.
Reviewed By: javache
Differential Revision: D54662737
fbshipit-source-id: 5bbf824c80e226f441bdcbc4fa67e41ab4c3eb33
Summary: Changelog: [Android][Added] add FBEndToEndDumpsysHelper stub to RNTester Android to be able to dump ViewHierarcies internally.
Reviewed By: makovkastar
Differential Revision: D54662739
fbshipit-source-id: 5236ae84ed648d431a8f01558f8f84049480ba39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44618
This change is a prerequisite to converting this file to Kotlin. It adds null checks to potentially nullable window and inset getters that were previously not there.
## Changelog:
[Android] [Changed] - Added null checks, marked null safety in StatusBarModule
Reviewed By: NickGerleman
Differential Revision: D57553395
fbshipit-source-id: 5293bb74a95d22bb82971c0a9d691c9e5e36d81f
Summary:
`pod install` and CocoaPods are actually not macOS specific.
Still, the pod lifecycle scripts of `react-native` depend on macOS-only utilities and will fail on Linux.
This is an attempt to make the scripts portable and make the pod install cleanly on Linux as well as macOS.
## Changelog:
[INTERNAL] [FIXED] - Skip XCode patching when not run on macOS
[INTERNAL] [FIXED] - Fall back to `which gcc`/`which g++` to identify C/C++ compiler when `xcrun` not available
[INTERNAL] [FEAT] - Recognize CC and CXX env vars supplied to the script and prefer them over autodetection
Pull Request resolved: https://github.com/facebook/react-native/pull/44417
Reviewed By: NickGerleman
Differential Revision: D57055928
Pulled By: cipolleschi
fbshipit-source-id: 1c49f70c52b4667abf0a215cbee52ee6aa6dd052
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44602
Fix regression caused by D56943825 where radii set to 0 was not being considered. Also preemptively fix a possible bug with RTL due to incorrect overrides.
Changelog:
[Android][Fixed] - Fix borderRadius incorrect overrides
Reviewed By: NickGerleman
Differential Revision: D57473482
fbshipit-source-id: d22a46bdd271d5f254e7d7e54abc55c00a8da8f2
Summary:
Apple is enforcing that new apps submission to the store mst use XCode 15. There is no reason to keep testing on Xcode 14.3 anymore, hence we are removing those jobs.
While doing that, we are also aligning the tests between Test_All and test_iOS workflows.
bypass-github-export-checks
## Changelog:
[Internal] - Remove CircleCI tests for Xcode 14.3
Pull Request resolved: https://github.com/facebook/react-native/pull/44448
Test Plan: CircleCI must stay Green
Reviewed By: huntie
Differential Revision: D57153939
Pulled By: cipolleschi
fbshipit-source-id: 82278bcb598b134238852e32b667a28619fb74cb
Summary:
One of the last parts of the migration. This PR foucuses on bringing the template jobs to Github actions.
bypass-github-export-checks
## Changelog:
[Internal] - Migrate template jobs from CCI to GH
Pull Request resolved: https://github.com/facebook/react-native/pull/44511
Test Plan: https://fburl.com/workplace/f6mz6tmw
Reviewed By: blakef
Differential Revision: D57202477
Pulled By: cipolleschi
fbshipit-source-id: be562cd3690d221f094dc734dd501aac25c36f59
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44613
We are building a native CSS parser for Fabric, to allow broader support for CSS. One area not yet implemented are features required for color.
<hash-token> is a pre-requisite.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D57180293
fbshipit-source-id: 0932c44d881f205aed55bcdf4fa23ad04b336c11
Summary:
Right now we use layout direction determined by I18NManager to influence the root Yoga layout direction.
Individual views may have a different resolved layout direction (e.g. due to `direction` style prop), and even though we don't rely on Android layout props, Android components still need to inherit or know the right layout direction to still do correct drawing. Example of this was scrollbar showing up on the left, instead of right in RTL, as soon as ScrollView knew it was in RTL.
This has potential to change a good amount of behavior, so this is under QE.
Changelog:
[Android][Fixed] - Propagate layout direction to Android Views and Drawables
Reviewed By: joevilches
Differential Revision: D57248417
fbshipit-source-id: 4bcdf2b23277ff926a796b8377df08d49c7b914c
Summary:
D57285584 was reverted because we have service code with a faulty measure function, and adding logging to Yoga when invalid measurements were received was enough to spike error rate to elevated levels and block release.
This is a reland of the below change, with a couple modifications:
1. We log warnings instead of errors, which from what I heard, shouldn't block release, but should still make signal
2. We only zero the dimension which was NaN, to preserve exact behavior
## Original
We've started seeing assertion failures in Yoga where a `NaN` value makes its way to an `availableHeight` constraint when measuring Litho tree.
Because it's only happening on Litho, I have some suspicion this might be originating from a Litho-specific measure function. This adds sanitization in Yoga to measure function results, where we will log an error, and set size to zero, if either dimension ends up being negative of `NaN`.
This doesn't really help track down where the error was happening, but Yoga doesn't have great context to show this to begin with. If we see this is issue, next steps would be Litho internal intrumentation to find culprit.
Changelog: [Internal]
Reviewed By: sbuggay
Differential Revision: D57473295
fbshipit-source-id: 979f1b9a51f5550a8d3ca534276ec191a3cb7b9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44600
I didn't pay close enough attention during merge between V1 and V2 of D57248205, and what I ultimately checked in is not correct. Fix the logic here.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D57488372
fbshipit-source-id: c9db597a6ae4ca5ae81e6ccd9913a14be268dd57
Summary:
This PR adds percentage support in translate properties for new arch iOS. Isolating this PR for easier reviews.
The approach taken here introduces usage of `ValueUnit` struct for transform operations so it can support `%` in translates and delay the generation of actual transform matrix until view dimensions are known. I have tried to keep the changes minimal and reuse existing APIs, open to changes if there's an alternative approach.
## Changelog:
[IOS] [ADDED] - Percentage support in translate in new arch.
<!-- 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
Pull Request resolved: https://github.com/facebook/react-native/pull/43192
Test Plan:
- Checkout TransformExample.js -> Translate percentage example.
- Added a simple test in `processTransform-test.js`. The regex is not perfect (values like 20px%, 20%px will pass, can be improved, let me know!)
Related PRs - https://github.com/facebook/react-native/pull/43193, https://github.com/facebook/react-native/pull/43191
Reviewed By: javache
Differential Revision: D56802425
Pulled By: NickGerleman
fbshipit-source-id: 978cbbdde004afe1e68ffee9a3c7eb7d16336b46
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44538
Android originated without RTL support. When RTL support was added, Applications needed to set `android:supportsRtl="true"` in their manifest, to allow Android to do RTL specific layout and drawing. This became the default for new projects created by Android Studio at some point.
React Native was not setting this in template, which means apps created from it do not do any of Android's RTL layout, text alignment, or drawing (e.g. in D3652980 8 years ago, a native drawer component came from the wrong side of the screen). RN would still layout the app using Yoga in RTL if in RTL locale though.
This change sets `android:supportsRtl` in template matching default new Android projects, and to avoid mismatched states in the future, will only tell I18NManager that RTL is allowed if `android:supportsRtl` is also set. This is breaking, since existing apps may not get Yoga RTL support unless telling Android that the application should support RTL layout.
Changelog:
[Android][Breaking] - Set and require `android:supportsRtl="true"` for RTL layout
Reviewed By: joevilches
Differential Revision: D57248205
fbshipit-source-id: 3f60c9f855db26f8d34a2e05d460f95961f5ffeb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44561
D57089275 introduced a layer to parse component values out of the token stream. I modeled this similar to the tokenizer, as a flat iterator of component values. Because function components can nest a variable number of child component values, this now looks like storing a fully resolved tree of tokens on the heap during parsing.
This diff changes the model, so that `CSSSyntaxParser::consumeComponentValue()` no longer returns a resolved CSS function value. Instead, users of the parser are expected to provide "visitors" which continue parsing, matched based on component value type pattern matched. Visitors can perform parsing specific to their context, and propagate values up the stack, based on their evaluation of the component value.
Removing the heap allocated list of tokens here also lets this core CSS parsing stack keep constexpr, so I added that back, though we need to keep expression trees for math expressions in uncommon cases, so the layer up probaly won't keep constexpr.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57206706
fbshipit-source-id: 25db84d376ef18f6291e60ed953e29c4000a7a26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44546
# Changelog:
[Internal] -
This is the first chunk of moving all of the interfaces to Kotlin inside `react.bridge`, covering the small-ish (functional/SAM and such) interfaces.
Reviewed By: javache
Differential Revision: D57253634
fbshipit-source-id: aa26d26b9681ac7c6059c249b985ff5121ad1e9d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44583
This native module is only available in the new architecture, stub the methods elsewhere.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D57382785
fbshipit-source-id: f6c988bcfd12633697b45a1f862b2cd4fb5d00d4
Summary:
Currently RCTPerfMonitor won't show up in scene based app, we should first try to extract the window from the connected scenes, and fallback to the window in `UIApplicationDelegate`.
## 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
-->
[iOS] [Fixed] - Fix RCTPerfMonitor not showing up in scene based app
Pull Request resolved: https://github.com/facebook/react-native/pull/43476
Test Plan:
- Tested RCTPerfMonitor in app not using scenes;
- Tested RCTPerfMonitor in app using scenes in iOS 13 & 14;
- Tested RCTPerfMonitor in app using scenes in iOS 15+.
Reviewed By: rshest
Differential Revision: D57381551
Pulled By: javache
fbshipit-source-id: fd6cce20c9a4ed41d7aae84751fc0c83391d0865
Summary:
I used the `createRootViewWithBridge` in a Project and got the hint to migrate to the `customiseView` Method. I searched for the Method, but found it under a different name: `customizeRootView`.
So i thought it would be helpful to use the correct Method name inside the hint message.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - fixed Method name in hint from customiseView to customizeRootView
Pull Request resolved: https://github.com/facebook/react-native/pull/44585
Test Plan:
* Use `createRootViewWithBridge`
* Should get a hint to migrate to `customizeRootView` method
Reviewed By: fabriziocucci
Differential Revision: D57431185
Pulled By: javache
fbshipit-source-id: 14f8c33771551ea3fb66d2c8f3fce4b4e3ef962a
Summary:
The current implementation does not support System font variants. Currently the isCondensed variable is always returning false. This pr adds an extra check to support the 'SystemCondensed' font variant on iOS.
## 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
-->
[IOS][ADDED] - Update font to handle system condensed variant
Pull Request resolved: https://github.com/facebook/react-native/pull/43188
Test Plan:
```
<Text style={{ fontSize: 28, fontFamily: 'System' }}>System</Text>
<Text style={{ fontSize: 28, fontFamily: 'SystemCondensed' }}>SystemCondensed</Text>
<Text style={{ fontSize: 28, fontFamily: 'AmericanTypewriter-Condensed' }}>AmericanTypewriter-Condensed</Text>
<Text style={{ fontSize: 28, fontFamily: 'HelveticaNeue' }}>HelveticaNeue</Text>
<Text style={{ fontSize: 28, fontFamily: 'HelveticaNeue-CondensedBold' }}>HelveticaNeue-CondensedBold</Text>
```

Reviewed By: fabriziocucci
Differential Revision: D57329036
Pulled By: javache
fbshipit-source-id: b0fffde1a568cb498f907e0a007df4da3e11d586
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44554
Noticed than when reload is triggered by Metro (`handleReloadJS`), the application would often get stuck and not respond to further reload commands. Often an IOException would get printed as well, due to concurrent bundle loads happening.
Changelog: [Android][Fixed] Improved resiliency of reloads when bundle loading fails
Reviewed By: RSNara
Differential Revision: D57112152
fbshipit-source-id: b0bf8c8311264504684a137c0910e2eeb008b0c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44574
`emitDeviceEvent` is frequently used for perf-critical operations such as sending network responses from native to JS. We don't need to go through JavaScriptModule Proxy (which is missing caching in bridgeless) and instead can immediately invoke the callable JS module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D57329165
fbshipit-source-id: 6506a7afb522b672a1f3dc7d348c9b80e6734225
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44577
There are no references to `AnimationsDebugModule` and it is also no longer public, so it is dead code. This cleans it up.
Changelog:
[Android][Removed] - Removed `NativeAnimationsDebugModule` (already not Public API)
Differential Revision: D57351893
fbshipit-source-id: 5a78a3b8e93a87ccb0cd5cdf8d2308d6c53d0ffa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44558
Right now this is only exposed to RNTester on iOS, but the prop exists on both platforms.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57281892
fbshipit-source-id: 9effc2b9c6421f8c74a2f4b933ab0fa0f15e7d70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44540
Noticed when running `arc nn`
> Advice xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/mountitems/IntBufferBatchMountItem.java:39
> [Class has 0 issues and can be marked Nullsafe] Congrats! `IntBufferBatchMountItem` is free of nullability issues. Mark it `Nullsafe(Nullsafe.Mode.LOCAL)` to prevent regressions.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57249958
fbshipit-source-id: d38559a3fafae0ad778c19dd85c5da610a650d7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44557
We've started seeing assertion failures in Yoga where a `NaN` value makes its way to an `availableHeight` constraint when measuring Litho tree.
Because it's only happening on Litho, I have some suspicion this might be originating from a Litho-specific measure function. This adds sanitization in Yoga to measure function results, where we will log an error, and set size to zero, if either dimension ends up being negative of `NaN`.
This doesn't really help track down where the error was happening, but Yoga doesn't have great context to show this to begin with. If we see this is issue, next steps would be Litho internal intrumentation to find culprit.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57285584
fbshipit-source-id: 935fcdd28c05bbac0d73e1c7654ae11a74898537
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44562
D56963463 deleted some tests for code it also deleted. This broke the Android GTest OSS build, which is a centralized list of these test files. Remove from there as well.
Changelog: [Internal]
Reviewed By: joevilches, realsoelynn
Differential Revision: D57299969
fbshipit-source-id: 1bf0b718ca5fcee03272dd0142f80ea2f8257902
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44464
Adds `app` to allow building and serving your React Native app in a similar structure to the boostrap and build tasks. This is the more comprehensive followup to D57067040.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067039
fbshipit-source-id: fdbe891657d826535cb779a4d1b71cfd13921684
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44462
Users using the new `react-native/scripts/cocoapods/autolinking.rb` script will expect all of the helper methods previously exposed throug `react_native_pods.rb`.
This was an oversight.
Changelog: [iOS][Fixed] exposes react_native_pods methods through autolinking.rb
Reviewed By: cipolleschi
Differential Revision: D57066094
fbshipit-source-id: d65dc79430101c9c43cbd90d1456630e338a22bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44463
Helper methods to help the cli grab system state, devices and run react-native/core-cli-utils tasks using Listr.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067037
fbshipit-source-id: 28cb4239f3a93558b88417f366a2146f696cc411
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44466
Contains a *light* wrapper to help launch Metro and build bundles or wait for localhost requests against Metro's dev-server.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067040
fbshipit-source-id: 8ab7ecb5d9b98d1abddd5d4f04c7eb25129cd0a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44512
We only ever go through MapBuffer now, so we can remove the code related to storing text fragments in folly::dynamic.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56963463
fbshipit-source-id: 98bce8aa4ccad134ce18bf35028e1b7b5082c3ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44529
The percentage formula was incorrect. We actually want to consider the shorter side as 100%. If we set a radius > minimum side there are no changes reflected. This is correct on iOS.
D56943825's summary also highlights the reasoning.
Changelog:
[Android][Fixed] Border-Radius percentages are now correctly resolved.
Reviewed By: NickGerleman
Differential Revision: D57214561
fbshipit-source-id: 45125b80289506a6dd51d24451e2b0222cd227c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44542
React Native no longer has a `Navigator` component, so let's clean up this reference in a comment in the `StatusBar` component definition.
Changelog:
[General][Changed] - Obsolete comments referencing Navigator
Reviewed By: GijsWeterings
Differential Revision: D57251899
fbshipit-source-id: bf2923bcaf22daf525381efbc3577c3610afaec4
Summary:
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/44524
After D56845572, I've started seeing the following redbox when running apps in bridgless mode:
{F1633641432}
Note sure this is the correct/complete fix but, after this, the error seems to go away.
Reviewed By: RSNara
Differential Revision: D57207925
fbshipit-source-id: c02b9b268c135aabaaa1dc8329abc80ca5c8a500
Summary:
Though the `ReactHost.destroy()` is not being used from OSS code, we use it at Expo for expo-dev-client to change loading apps from different dev servers. Without cleanup the `mAttachedSurfaces`, it will have dangling or duplicated attached surfaces that cause duplicated react trees.
<img src="https://github.com/facebook/react-native/assets/46429/f84d274e-aaad-4352-9e3c-6262571a5625">
This PR tries to cleanup the `mAttachedSurfaces` from destroying.
## Changelog:
[ANDROID] [FIXED] - Fixed dangling `mAttachedSurfaces` after `ReactHost.destroy()`
Pull Request resolved: https://github.com/facebook/react-native/pull/44393
Test Plan: have to manually call `ReactHost.destroy()` and recreate the MainActivity without killing the process. then reload the app will startSurface for the same attached surfaces.
Reviewed By: RSNara
Differential Revision: D56901863
Pulled By: javache
fbshipit-source-id: c7f822501d971810ac6aa7262b15da69ec41355e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44470
CSS component values, as defined in the syntax spec, are either "preserved tokens", CSS functions, or simple blocks. This is distinct from the higher-level "component value type" specified in the [values and units](https://www.w3.org/TR/css-values-3/#component-types) spec.
I was previously short-circuiting a bit, from preserved tokens, to a higher level data structure. This separates them out, adding a layer exposing the preserved token as `CSSSyntaxParser::Token`, and now a `CSSSyntaxParser::Function`, which can represent a named function and its nested component values.
This does not yet wire functions beyond CSSParser returned component values.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57089275
fbshipit-source-id: 97eeb1a7b3363c79d99f9419ba6e022c4c3c31d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44521
changelog: [internal]
mapbuffer leaks into every component even though it is only used by 2: Paragraph and TextInput. Let's isolate it only to those two.
To do that, I added a new template prop: usesMapBufferForStateData. It is false by default and only Paragraph and TextInput set it to true.
Reviewed By: christophpurrer
Differential Revision: D56636011
fbshipit-source-id: 4a99e6e68caaf40111b6b7b205854a71f33c5864
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44493
Just keeping our version of AGP up to date.
Changelog:
[Internal] [Changed] - Bump AGP to 8.4.0
Reviewed By: arushikesarwani94
Differential Revision: D57104079
fbshipit-source-id: 4d5c0dec95bf73696a0274f61e0536e53c11adaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44528
Changelog: [internal]
In the `IntersectionObserver` API we dispatch the initial notification in the `observe` method, but it might be possible that the surface has been removed from the registry by the time we execute that code.
This guards against that case to possibly fix a crash we're seeing in on the `IntersectionObserver` experiments.
Reviewed By: sammy-SC
Differential Revision: D57213994
fbshipit-source-id: 5cd1f16958949cc1ff64153e8012e6a59819d68a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44513
The removed code was moved to LogBoxInspectorContainer, and is not referenced inside the LogBoxStateSubscription component.
## Changelog
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D57168569
fbshipit-source-id: 07f843b2df126cc05f65937dd44781525d6afeb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44525
These examples were added, but their names were duplicated. This caused our internal e2e tests to accidentally target the wrong examples.
Changelog:
[General][Fixed] RNTester examples for border percentages are now properly covered by E2E screenshot tests.
Reviewed By: NickGerleman
Differential Revision: D57207306
fbshipit-source-id: 32ed5cc6b136a8928b11afe8b824c752edcdd9e5
Summary:
Tweaks the Paused Debugger Overlay design on iOS. The tap area to resume the application is now the entire "Paused in debugger" item.
|Before|After|
| {F1578785144} | {F1578734918} |
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D57161216
fbshipit-source-id: 581ebe44e45a57cdfe3e617e8f97f78619f84e73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44516
# Changelog:
[Internal] -
This is a generally cross-platform attribute, which is supported not only on Android, and conceptually does arguably belong in TextAttributes.
Reviewed By: NickGerleman
Differential Revision: D57181633
fbshipit-source-id: 7251f0a90158f0466fbf13b9d855c7a449e6dd0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44518
# Changelog:
[Internal] -
For some inexplicable reason, we had majority of `Text` test examples (42 out of 46) in RNTester stuffed into `<RNTesterBlock/>` components inside one huge "Basic" test case.
This was highly imbalanced, introduced extra nesting, cluttering the UI, but most importantly, none of those 42 out 46 test cases were searchable for.
This change flattens all of the corresponding nested test cases to the top level, making them into valid separate test cases, which are also searchable.
It also corresponds to the general structure we have in other test examples, such as `TextInput`.
Reviewed By: cipolleschi
Differential Revision: D57197676
fbshipit-source-id: 777eb2aa238a91bb3f52d2f0ab10edc6bfad5c85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44479
TextInputs' onTextInput callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists.
We first have to remove the event emitting in native code, and can land the full removal separately in D57092733, once there's no older client references remaining to this event.
Changelog: [General][Removed] Remove deprecated onTextInput callback
Reviewed By: cipolleschi
Differential Revision: D57092734
fbshipit-source-id: 5b0beee3d55b70717216fe8ceaf52444540f5adc
Summary:
The new cocoapod post install script includes aggregation and generation of privacy manifests for iOS, which is great. However, the script doesn't consider the case where the file reference doesn't have a path.
Example, for a project setup like the screenshot:
<img width="249" alt="image" src="https://github.com/facebook/react-native/assets/22592111/45dd1cf4-c2f6-4abb-940f-136a4d502966">
The code
https://github.com/facebook/react-native/blob/05a4232dd591e2d43f192d69ca14a04f4a3fb6a1/packages/react-native/scripts/cocoapods/privacy_manifest_utils.rb#L80-L81
prints `file_refs`:
```
[
<PBXFileReference name=`LaunchScreen.storyboard` path=`learnX/LaunchScreen.storyboard` UUID=`81AB9BB72411601600AC10FF`>,
<PBXVariantGroup name=`InfoPlist.strings` UUID=`D40B9F832B248EF5004BC08C`>,
<PBXFileReference path=`AppCenter-Config.plist` UUID=`D40B9F802B248EC2004BC08C`>,
<PBXFileReference name=`PrivacyInfo.xcprivacy` path=`learnX/PrivacyInfo.xcprivacy` UUID=`D403DD362BCA2BCF00E5295C`>,
<PBXFileReference name=`Assets.xcassets` path=`learnX/Assets.xcassets` UUID=`D40B9F652B248AEB004BC08C`>
]
```
where a `PBXVariantGroup` exists and it doesn't have `path`. The error `undefined method 'end_with?' for nil` occurs as a result.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - In privacy manifest post install script, handle the case where the file reference doesn't have a path
Pull Request resolved: https://github.com/facebook/react-native/pull/44410
Test Plan:
1. Add a new "Strings File (Legacy)" in Xcode to the project.
2. Run `pod install` for iOS.
3. See the error `undefined method 'end_with?' for nil`.
4. Apply the fix and rerun `pod install`.
5. The script runs successfully.
Reviewed By: javache
Differential Revision: D57056159
Pulled By: cipolleschi
fbshipit-source-id: 42caaf1a98efb9111f6ff1014a5c8b7703b042f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44517
# Changelog:
[Internal] -
A follow-up to https://github.com/facebook/react-native/pull/44505, turns out this is also an issue for TextInput examples, which work of assumption of some of the text input fields being of limited width, but in practice growing to occupy the parent window width, which can be quite large on platforms different from the classic mobile ones.
This diff makes the corresponding tests more practical, not expanding to the parent window anymore.
Reviewed By: christophpurrer
Differential Revision: D57196308
fbshipit-source-id: 7018e8c51adb70fe6a03e50d71eff9ba997fd07a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44515
this has been the default for a while
Changelog: [Internal]
Reviewed By: SamChou19815
Differential Revision: D57195561
fbshipit-source-id: b441d972134dba754d714ae5694d94537707ded3
Summary:
Root cause of the fetch memory leak:
The fetch requests store its result inside Blob which memory is managed by BlobCollector. On the JS engine side,
the Blob is represented by an ID as JS string, and the GC don't know the size of the blob. So GC won't have interests to release the Blob.
Fix:
On iOS and Android, use `setExternalMemoryPressure` to acknowledge JS engine the size of Blob it holds.
## Changelog:
[GENERAL] [FIXED] - fix fetch memory leak
Pull Request resolved: https://github.com/facebook/react-native/pull/44336
Test Plan: `RepeatedlyFetch` inside `XHR` example
Reviewed By: javache
Differential Revision: D57145270
Pulled By: NickGerleman
fbshipit-source-id: afa53540e8563db4f9c6657f2dbbdff7bdfa66c0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44429
`Transform::Rotation(x, y, z)` creates an empty transform with the associated operation, then [multiplies by xyz rotation vectors](https://en.wikipedia.org/wiki/Rotation_matrix#General_3D_rotations).
Multiplication chains each transform operation, so afterward, we end up with correct transform matrix, but duplicate operations.
This removes the first transform operation, and lets the per-axis multiplications set them.
Changelog:
[General][Fixed] - Fix duplicate rotation operations
Reviewed By: rshest
Differential Revision: D57025602
fbshipit-source-id: 5eb47dbf9a72eab89a351fd5ae02261566b35ffb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44471
Need to make the current headers a bit more granular to avoid cyclical dependencies, and a lot of bloat.
This code isn't wired up more broadly, so this isn't breaking yet.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D57089140
fbshipit-source-id: f6e0312c207664b0a59f682c673cd00e263915bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44450
Adding some of the tokenization needed for things like `transform` and `filter`. Parsing will be a bit trickier with the model currently built up.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57047886
fbshipit-source-id: 260a681ab60944c8f127d937589fc4c8589a53e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44435
Every CSS prop at this sparse stage is represented as an enum, and each enum can be specialized to different types, according to the global CSS property table.
With this change, we add a string name to each property table entry that we use to generate a function to be able to set CSS value strings, against property name strings. Like `declaredStyle.set("aspectRatio", "4 / 3")`.
I was considering specializing this a bit, to allow DeclaredStyles which only support a subset of CSS props. E.g. so `ParagraphShadowNode` has a more derived declared style than `LayoutableShadowNode` does. But, I am not sure the best way yet to make that compose nicely.
Changelog: [internal]
Reviewed By: sammy-SC, rshest
Differential Revision: D57039255
fbshipit-source-id: c5289254bb97fa355af5f416b79952e426720934
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44505
# Changelog:
[Internal] -
The RNTester/Text tests, that are related to text wrapping (such as "wrap mode", "hyphenation", "ellipsize", "numberOfLines" ones) were written with the mobile form factor in mind, whereas the RNTester window is generally expected to be narrow and tall.
Now, that we are running on other platforms as well, there is no guarantee about the RNTester window width, in general, so these tests relying on particular window width is not practical anymore.
This makes the corresponding tests work in a useful way without making assumptions about the RNTester's window width.
Differential Revision: D57166025
fbshipit-source-id: 3305a31f7ca254d82c85d67c975c1140050adc28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44500
tsia really, added tests for blur, brightness, and chained brightness + blur. I don't really think I need to add them all, as e2e tests can be flaky and I doubt someone changes specific color matrix values ever.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D57127765
fbshipit-source-id: 7644c9493eee176e24922f7c06656360340e00d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44408
Why?
Previously we didn't support using percentages like:
```
style={{
width=100,
height=100,
borderRadius='100%',
}}
```
These percentages refer to the corresponding dimension of the border box.
What?
- Added LengthPercentage class and LengthPercentageType enum. To track when we are dealing with percentage vs points
- Now radius properties start as Dynamic which then get transformed into LengthPercentage.
- Modified certain function parameters so we can consider height and width when resolving BorderRadius values
With this we conditionally calculate the corresponding point (dp) value for a given percentage (considering size). Ex:
```
result = {raw_percentage_value} / 100 * (max(height, width))
```
We know the maximum border radius for our current implementation is half the dp of the shorter side of our view, hence why we consider half our maximum view side as equivalent to 100%.
Note: We still don't support vertical/horizontal border radii
## Changelog:
[Android][Added] - Added support for using percentages when defining border radius related properties.
Reviewed By: NickGerleman
Differential Revision: D56943825
fbshipit-source-id: 3e5a9933ca90e499aff9c7d2561f5f6bb55157da
Summary:
## Summary
Sets up dynamic feature flags for `disableStringRefs`, `enableFastJSX`,
and `enableRefAsProp` in React Native (at Meta).
## How did you test this change?
```
$ yarn test
$ yarn flow fabric
```
DiffTrain build for commit https://github.com/facebook/react/commit/9b1300209eb00a2d6c645fddf6d2729d67d7b10a.
Reviewed By: kassens
Differential Revision: D57026752
Pulled By: yungsters
fbshipit-source-id: 18b2112fce1671bb83f281b1e036991fa7d6d4ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44499
Changelog: [internal]
As [discussed](https://fb.workplace.com/groups/react.devx.team/permalink/930483712103526/), we'll begin segmenting Telemetry signals by Fusebox/non-Fusebox.
* Add new flag in event reporter for `debugger_command` (other events in subsequent diffs)
* Add new column to the Scuba destination
Reviewed By: blakef
Differential Revision: D57140479
fbshipit-source-id: 7ea813b1b4d53a282873fa95c8ee82e5d6f3d1d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44498
Changelog: [internal]
Quick refactor to reduce commit noise in the following diff in the stack
Reviewed By: blakef
Differential Revision: D57140480
fbshipit-source-id: aa1fef83d5347b8a11651d3d5c4112b4adf7a7d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44476
# Changelog:
[Internal] -
This is the last step to converting the whole `modules.debug` module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095966
fbshipit-source-id: 3fcb52528674565a4a2b5c306262e0af11a19e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44475
# Changelog:
[Internal] -
As the title says, this is preparing to complete the conversion of the whole corresponding module to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D57095896
fbshipit-source-id: 87fe08aec974f5f1327189d0e74c3782c4391e85
Summary:
This pull request fixes an issue where the `selectionColor` prop was not applied to the `TextInput` component on iOS, starting from React Native version 0.74.x.
This issue was introduced in PR [1e68e485](https://github.com/facebook/react-native/commit/1e68e48534aedf1533327bf65f26e5cf5b80127b#diff-b6634353ea5b10a91de24605dc51bdfb50e8ddb652ccd5b9dab194168a69d4b1) which relocated `selectionColor` along with `selectionHandleColor` and `cursorColor` out of `otherProps`. This modification inadvertently prevented `selectionColor` from being passed to the iOS native component.
This change ensures that the `selectionColor` prop is explicitly included in the `RCTTextInputView` component's properties, fixing the regression.
Note: `selectionHandleColor` and `cursorColor` are Android-specific and do not require explicit passing on iOS.
## 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
-->
[IOS] [FIXED] - Fixed an issue where the `selectionColor` prop was not being applied on the `TextInput` component.
Pull Request resolved: https://github.com/facebook/react-native/pull/44420
Test Plan:
**Environment:** iOS Simulator, React Native 0.74.0.
**Steps to reproduce:**
- Implement a `TextInput` component with the `selectionColor` prop set.
- Run the application on an iOS device or simulator.
- Focus on the TextInput component, write some text and select it.
**Expected Result:** the selection color should match the color provided to the `selectionColor` prop.
**Actual result before fix:** the selection color did not reflect the specified `selectionColor` prop and fell back to the default iOS selection color (blue).
**Screenshots:**
- Before fix:
<img width="1710" alt="before_fix" src="https://github.com/facebook/react-native/assets/17989553/8660068c-55c9-4f55-a788-f96eb681fb70">
- After fix:
<img width="1710" alt="after_fix" src="https://github.com/facebook/react-native/assets/17989553/93c9eb26-7da0-4957-b54f-8444aff7e374">
Reviewed By: javache
Differential Revision: D57017836
Pulled By: NickGerleman
fbshipit-source-id: 263ce22168e09c15cdfdb4eb4300a2605d8af032
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44319
The files were identical so no need for both. Having both is error-prone as one may be modified without modifying the other.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56659179
fbshipit-source-id: e5f414f0c4a00c126d301a7fcd26eeb17d74a56c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44491
Changelog: [internal]
Ensure only one scroll event is fired per frame by tracking the events in FabricUIManager
Reviewed By: sammy-SC
Differential Revision: D57018741
fbshipit-source-id: c1ad59f934e359edfeb8f3e084106eebd467a0b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44489
Changelog: [internal]
Integrate a synchronous event API to trigger synchronous scroll events in Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: sammy-SC
Differential Revision: D56886403
fbshipit-source-id: 337277c735c0943ce4ba29bb2d646a72fe101ede
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44451
Changelog: [internal]
Exposing the experimental API EventEmitter::experimental_flushSync to trigger synchronous events from Android. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: NickGerleman
Differential Revision: D56886402
fbshipit-source-id: 7b71cd489e3bb65dffcfb53fef2ea7cafbb973f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44458
This is the JS plumbing to get it so that views can now use filters. The typing looks like
`filter: [{brightness: 1.5}, {hueRotate: '90deg'}]`
which is different than web which would look like `filter: brightness(1.5) hue-rotate(90deg)`. I feel like the web version is overly complicated and not very *react native-y*. Transform uses the array based approach (albeit they also accept a string). Open to changing this but really feel like the web format is silly and bad since it would just involve parsing some arbitrary string.
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn filter format into {name: string, amount: string}
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56845572
fbshipit-source-id: 5029b5adac29bb863c89f6c699d5693c58cad711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44457
Most filters are not going to work on iOS. It is a long story but essentially there is not a good way to continuously get a snapshot of the view and its descendants to filter.
We can, however, implement `brightness` using `compositingFilter` and blend mode. This is really not documented at all, but if you assign a string representing the blend mode to the [`compositingFilter`](https://developer.apple.com/documentation/quartzcore/calayer/1410748-compositingfilter?language=objc) property on CALayer, it will actually work. The filter we use is [`multiplyBlendMode`](https://developer.apple.com/library/archive/documentation/GraphicsImaging/Reference/CoreImageFilterReference/index.html#//apple_ref/doc/filter/ci/CIMultiplyBlendMode). As the title suggests this just multiplies the two layers. We can apply this to a `_filterLayer` and set its background color to the brightness amount to get the desired results. Most other color filters either operate on the color components dependently (e.g. new red component depends the value in blue and green), or they have addition operations. We can do addition with `linearDodgeBlendMode`, but the order of operations does not work (we multiply, clamp, then add vs. multiply, add, then clamp).
`opacity` is just a multiplier on the CALayer `opacity` property.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56447175
fbshipit-source-id: 6705673dd9dec9fc3ec89e49b583523eec1028b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44455
Title says it all. Right now this ignores drop-shadow as that will be implemented later. Some of this code will need to be adjusted as it is the one filter that takes multiple amounts. But I feel that can be amended later when we get there - after all the `amount` parsing code is just casting to a float at the moment, so we are not locking ourselves into anything.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640629
fbshipit-source-id: c8e1206ab46accab3c99614241b8bd9aa252e12c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44453
This works similar to how `transform` is parsed in that it sets tags on the View to actually update the prop when all the prop setters are done being called since the parsing of the array is not very trivial. Besides that it is pretty simple and just calls into `FilterHelper` and uses `setRenderEffect`: https://developer.android.com/reference/android/view/View#setRenderEffect(android.graphics.RenderEffect).
That API is only exposed in version 31 of the SDK so it is gated accordingly.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D54640600
fbshipit-source-id: ad4cde2bed9611f476f4ecb2550c2269965d7917
Summary:
In this pr, I updated the deprecated babel-plugins with their new library. When you enter the npm page of the relevant plugins, it is recommended to implement new packages instead of the deprecated package.
For example :
<img width="1305" alt="Screenshot 2024-05-05 at 17 50 16" src="https://github.com/facebook/react-native/assets/113903710/a58fdac3-79db-4b53-98bd-4c5325a1e560">
## Motivation:
We use the react-native package in our project and aim to upgrade pnpm to the latest version. First, we wanted to clear deprecated warnings. Babel plugin deprecated warnings were caused by the react-native package, so I created this pull request.
Deprecation Warnings from package installing :
<img width="581" alt="Screenshot 2024-05-05 at 17 53 05" src="https://github.com/facebook/react-native/assets/113903710/9c5859a5-f194-43ab-ae35-417dfaacebab">
## Changelog:
[GENERAL][FIXED] - Replace deprecated babel-plugin libraries to fix deprecation warnings on installation
Pull Request resolved: https://github.com/facebook/react-native/pull/44416
Test Plan: CI should pass
Reviewed By: huntie
Differential Revision: D57056843
Pulled By: robhogan
fbshipit-source-id: b75b329bbc2105c31da85e861ef71ffdcbbb0623
Summary:
Changelog: [internal]
This is a new attempt at fixing mounting errors during synchronous state updates after what we tried in https://github.com/facebook/react-native/pull/44015.
That fix didn't work because `dispatchMountItems` actually makes a copy of the mount items that it's going to process, so when we added the mount items to the list they were actually not being picked up by the current processing.
This changes the fix to call `dispatchMountItems` as many times as needed, while there are mount items to process in the list.
Reviewed By: sammy-SC
Differential Revision: D57107212
fbshipit-source-id: 46988a71daae15d70399258f850653046d0790ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44445
The `ReactNativeInternalFeatureFlagsMock` module is not references in the open source repository, so there's no reason it should exist there. This cleans that up.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D57052284
fbshipit-source-id: d220eae2ba76f20ed48742779fbffd5de1f77529
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44444
Changelog: [Internal] - Request bundles with `excludeSource=true` and `sourcePaths=url-server`.
Changes RN's bundle client to request more efficient source maps from Metro by relying on lazy-fetching of source contents.
NOTE: Requires a Metro version with D56952064 and D56952063 (not yet released on npm) to work properly.
Reviewed By: robhogan
Differential Revision: D56952065
fbshipit-source-id: 0ed083ecc64adbd7acf209bb9abd40db24ffc86b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44461
Users would have to do this by manipulating the environment before.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D57067036
fbshipit-source-id: 6df16c884412578c3b5cae50e26ca37636a7dc5b
Summary:
Minor inconvenience I noticed while doing some testing in a mono-repo.
The current paths points to the android folder, but should point to the project root. Currently the android build fails if one uncomments the folder paths as they are.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - Fix incorrect paths in app build.gradle react config block
Pull Request resolved: https://github.com/facebook/react-native/pull/44472
Test Plan:
Uncomment the paths are they are and notice the android build error:
```
FAILURE: Build failed with an exception.
* What went wrong:
A problem occurred configuring project ':app'.
> Failed to notify project evaluation listener.
> /xyz/xyz/xyz/xyz/RNPathTester/android/node_modules/react-native/ReactAndroid/gradle.properties (No such file or directory)
```
Use the updated paths and notice the build succeeds 🥳
Reviewed By: GijsWeterings
Differential Revision: D57093768
Pulled By: cipolleschi
fbshipit-source-id: 8472151c74c7aa5c51dc75f9adda6116387bdf99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44436
The backing buffer behind `ReadableMapBuffer` is effectively immutable, so we can make reads of nested MapBuffers work on an inline view of the same buffer. This book-keeping is kept within ReadableMapBuffer (we can not user `ByteBuffer.wrap()` because the fbjni produces ByteBuffer is not array backed).
The main downside I can think of is that the whole buffer is kept in memory until all children buffers leave, but current use-cases don't involve long-term storage of MapBuffer children, so this is probably a better tradeoff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D57020759
fbshipit-source-id: d2f5a76561fa4a4219fe5022ba62cc96f56ce022
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44398
**Problem:**
`selection` prop is not being set on component creation.
Not quite sure which RN version this issue was introduced but fixing it on latest code.
Use playground for testing (refer to following diff)
**Proposed Solution:**
Added notes in comments but `viewCommands.setTextAndSelection()` is called only on text or selection update which relies on comparing data with `lastNativeSelection`. Problem is that `lastNativeSelection` is initially set to the props value that is passed in so does not send the command on component creation.
So assign a default selection value of `{start: -1, end: -1}` so it can be set on component creation.
**Changelog:**
[General][Fixed] - `selection` prop in `TextInput` was not being applied at component creation
Reviewed By: cipolleschi
Differential Revision: D56911712
fbshipit-source-id: 7774b246383f85216536040688b0a8ea85b3478a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44432
Implements a bit more of the tokenizer algorithm, to correctly support dimensions like `.25turn` instead of just `0.25turn`.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57033796
fbshipit-source-id: 6d73de22e3a0f0ca0de432be56bca97f0069ad96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44431
Turn `expectTokens()` function into a macro so that GTest assertion macros point to the right line numbers.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57034303
fbshipit-source-id: f6d18c0d2420e50c75b61a57489e9ddc12653fb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44430
Let's add support for angles so we can correctly represent things like rotation/skew transforms or hue-rotate filter. This should replace `ValueUnit` in prop related transform code.
A couple implementation notes:
1. RN currently uses radians internally, but CSS says the cannonical angle unit is degrees, so we keep to that
2. We have all the information to convert to cannonical value type at parsing layer, so we do that, and clients can only see degreee values instead of units. Less flexible, but simpler/more efficient for now, where higher levels don't care.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D57029378
fbshipit-source-id: 91341f1bf4686d9016823ac8cf91897e933345f9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44427
We only need the default module implementation headers in the C++ file. These were added to the header file for the default module helper by mistake.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D57003838
fbshipit-source-id: d37ebd247eaa2c0cb05ebc6c666a585e6352646d
Summary:
After upgrading my app from React Native 0.74.0 to 0.74.1, iOS builds were failing due to the privacy manifest ruby script failing due to what seemed to be a missing nil check.
```
[Privacy Manifest Aggregation] Appending aggregated reasons to existing PrivacyInfo.xcprivacy file.
[Privacy Manifest Aggregation] Reading .xcprivacy files to aggregate all used Required Reason APIs.
[!] An error occurred while processing the post-install hook of the Podfile.
no implicit conversion of nil into Array
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `+'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:115:in `block (5 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:111:in `block (4 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:106:in `block (3 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:105:in `block (2 levels) in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:104:in `block in get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `each'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:102:in `get_used_required_reason_apis'
node_modules/react-native/scripts/cocoapods/privacy_manifest_utils.rb:18:in `add_aggregated_privacy_manifest'
node_modules/react-native/scripts/react_native_pods.rb:301:in `react_native_post_install'
ios/Podfile:38:in `block (3 levels) in from_ruby'
vendor/bundle/ruby/3.3.0/gems/cocoapods-core-1.15.2/lib/cocoapods-core/podfile.rb:196:in `post_install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1013:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-pod-sign-1.3.0/lib/cocoapods-pod-sign/pod_installer.rb:45:in `run_podfile_post_install_hook'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1001:in `block in run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:149:in `message'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:1000:in `run_podfile_post_install_hooks'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:337:in `block (2 levels) in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer/xcode/pods_project_generator/pods_project_writer.rb:61:in `write!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:336:in `block in create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/user_interface.rb:64:in `section'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:315:in `create_and_save_projects'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:307:in `generate_pods_project'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:183:in `integrate'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/installer.rb:170:in `install!'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command/update.rb:63:in `run'
vendor/bundle/ruby/3.3.0/gems/claide-1.1.0/lib/claide/command.rb:334:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/lib/cocoapods/command.rb:52:in `run'
vendor/bundle/ruby/3.3.0/gems/cocoapods-1.15.2/bin/pod:55:in `<top (required)>'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `load'
vendor/bundle/ruby/3.3.0/bin/pod:25:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:58:in `kernel_load'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli/exec.rb:23:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:451:in `exec'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:34:in `dispatch'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/cli.rb:28:in `start'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:28:in `block in <top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
/Users/swrobel/.gem/ruby/3.3.1/gems/bundler-2.5.9/exe/bundle:20:in `<top (required)>'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `load'
/Users/swrobel/.gem/ruby/3.3.1/bin/bundle:25:in `<main>'
```
Adding some good old `puts` debugging to this file indicated that the problem was that an invalid manifest file was being generated for react-native-image-crop-picker, which I don't understand, because it [doesn't currently have a Privacy Manifest](https://github.com/ivpusic/react-native-image-crop-picker/issues/2040).
```xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyTrackingDomains</key>
<array/>
<key>NSPrivacyCollectedDataTypes</key>
<array/>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<dict/>
</array>
</dict>
</plist>
```
It seems there may be some upstream issue in whatever tool generates these missing privacy manifests, but that seemed beyond the scope of a simple nil check.
## Changelog:
[iOS] [FIXED] - Privacy Manifest aggregation failing due to missing nil check
Pull Request resolved: https://github.com/facebook/react-native/pull/44400
Test Plan: Build completes successfully after making this change.
Reviewed By: cipolleschi
Differential Revision: D56921303
Pulled By: philIip
fbshipit-source-id: 1b6b10b05d403bf71f78f5b80543a2d82f043e23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44439
Changelog: [internal]
(IntersectionObserver isn't enabled yet in OSS).
This fixes a bug in `IntersectionObserver` when observing the same target in multiple observers. In that case, the first time we `unobserve` we clean up some metadata that's shared across observers, and other observers observing the target have problems with the missing data.
This fixes the problem by removing the clean up, as the data structure backing this information is a `WeakMap` anyway, so it'll be cleaned up automatically eventually, and the stored data is very small.
Reviewed By: twobassdrum
Differential Revision: D57046864
fbshipit-source-id: b001cf1ae4f4c91b74b1ad487e01691d5f3be1ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44440
# Changelog:
[Internal] -
As in the title, note that there are more files there to migrate, will come separately, to make reviewing easier.
Reviewed By: javache
Differential Revision: D57046953
fbshipit-source-id: e45316da1ed9caaa4daafa96dfabfd374926bd73
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44394
Lint fix - flip to a guaranteed non-null value instead of the nullable field
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56898951
fbshipit-source-id: 8740ed77d71a827c7ce80b2df941d24985339619
Summary:
TextInputs' `onTextInput` callback was removed way back in React Native 0.62 with https://github.com/facebook/react-native/commit/3f7e0a2c9601fc186f25bfd794cd0008ac3983ab , but remnants of the implementation exists. Let's just remove it altogether?
## Changelog:
[IOS] [REMOVED] - Remove deprecated onTextInput callback
Pull Request resolved: https://github.com/facebook/react-native/pull/44351
Test Plan: CI should pass
Reviewed By: NickGerleman
Differential Revision: D56804590
Pulled By: javache
fbshipit-source-id: 89101fa53cdc628a97ba176cf3deca691784bfdd
Summary:
Cocoapods regression is now fixed (been fixed for a while) but we forgot to remove the upper bound and explicit `activesupport` in Gemfile.
https://github.com/CocoaPods/CocoaPods/releases/tag/1.15.2
## Changelog:
[IOS] [CHANGED] - Update Gemfile in template
Pull Request resolved: https://github.com/facebook/react-native/pull/44434
Test Plan: Run `bundle install/update` should update cocoapods to the latest version and active support should work properly without any issues.
Reviewed By: blakef
Differential Revision: D57046638
Pulled By: cipolleschi
fbshipit-source-id: 9d8e716d4392d7bc5a1940b523e57d2193134f95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44362
Packages that are built and directly run in the monorepo no longer need to worry about
conditionally registering themselves to transpile Flow -> JS at runtime. Our build step
strips this file now.
Changelog: [Internal] changes in published packages no longer require conditional calls to Babel register.
Reviewed By: huntie
Differential Revision: D56839521
fbshipit-source-id: 6bec706c639f1ab4138e0b790be8a07654333046
Summary:
https://github.com/facebook/react-native/commit/7af288e5 introduced a breaking change for whoever importing HermesExecutorFactory.h, because the `hermes/inspector-modern/chrome/HermesRuntimeTargetDelegate.h` is not a public header. Also the nested import is not ideal for CocoaPods or use_frameworks.
I think HermesRuntimeTargetDelegate could be an implementation detail that hide from header. This PR tries to turn the ownership declaration from std::optional to std::unique_ptr, so that we could hide the concrete type.
## Changelog:
[IOS] [FIXED] - Fixed `HermesExecutorFactory.h` build error when importing its private header
Pull Request resolved: https://github.com/facebook/react-native/pull/44423
Test Plan: should introduce no breaking change and ci passed
Reviewed By: cipolleschi
Differential Revision: D57041498
Pulled By: huntie
fbshipit-source-id: bfa10c7307458813d99c52313682dd62bea80f19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44415
# Changelog:
[Internal] -
RNTester Image example used hardcoded `https://www.facebook.com/favicon.ico`, which has an uncommon ICO format, for no good reason aside of just this image being served from `facebook.com`.
This diff:
* Replaces the ICO image with a PNG one (which is still served from `facebook.com`
* Factors out all the multiple hardcoded paths into constants, so that it's easier to make such changes in the future
* Changes another image to something that is a bit better on the eyes when severely downscaled
Reviewed By: christophpurrer
Differential Revision: D56978929
fbshipit-source-id: c627d1671c8cb66e9a78f4382faa56e539b2f7b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44414
# Changelog:
[Internal] -
I noticed that "Image/Fade Duration" test in RNTester is practically useless, as at the moment one scrolls to the test, the fading is most probably had already ended.
This adds a "button" to refresh the image and be able to see the fading in again and again, if desired.
Reviewed By: christophpurrer
Differential Revision: D56978930
fbshipit-source-id: 02873b45600ad319b0b1077467f599dc1a54bee3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44413
## Changelog:
[Internal] -
As in the title, the corresponding module is migrated from Java to Kotlin.
Reviewed By: christophpurrer
Differential Revision: D56978931
fbshipit-source-id: e1e8f22ad9bd2f594bc7cf77c6344f8f23996bcc
Summary:
Followup to D56848799!
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D56935723
fbshipit-source-id: 859cd88c06a972b2fb44525eee075df7c701c83a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44381
Changelog: [Android][Added]
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
this will be forward compatible in the old architecture
Reviewed By: RSNara
Differential Revision: D56866817
fbshipit-source-id: 4096847c52559d9a49feb072a0385da6b64392d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44383
This diff allows the default fallback style to be grabbed from KeyWindow. Previously with the TraitCollections being passed in from overridden views it was not getting the accurate system fallback.
We need this for Twilight, which is adopting a Light/Dark mode toggle. Previously when setColorScheme was getting called it would modify overrideUserInterfaceStyle and that would serve as the "default fallback" for future setColorScheme calls. setColorScheme shouldn't be setting the defaults, it should be setting the user-session theme preference.
Changelog:
[Internal] [Changed] - Added option for treating the KeyWindows's userInterfaceStyle as the source of truth for the system's dark/light mode.
Differential Revision: D56868862
fbshipit-source-id: 229894947baed65ef15cece5bece120e8497462f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44409
This is kind of a mess.
D56800381 moved us away from code relying on legacy TextLayoutManager, under the assumption we weren't using the old one anymore. It turns out we were still using the legacy TextLayoutManager for the sole case of cached spannables, where we ask FabricUIManager to measure using non-mapbuffer path, and pass the cache key (no underlying attributedstring). After the diff, we call default VM measure function, which returns zero size. This specifically breaks measurements of uncontrolled TextInput components.
This updates that path to use the same TextLayoutManager as we use for everything else.
This model breaks some code which assumes the AttributedString is present, instead of just para attributes. The redundant calls to get fragments is expensive and already something on my radar to fix, but for now, we mostly just no-op, the same way the old TextLayoutManager did when fragments were not set. This needs a good cleanup.
Changelog:
[Android][Fixed] - Fix cached spannable measurement path
Reviewed By: javache
Differential Revision: D56963152
fbshipit-source-id: 6dc0e29f6b63d367be1ba0be82dfbc18c4654ab2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44376
Changelog: [Internal]
In order to make migration a little bit cleaner, I thought it would be nice to implement forward compatibility for RCTCallInvokerModule. This way, the consumer doesn't have to have branching logic when they try to retrieve the callInvoker in their code, and can remove a callsite to the bridge.
Reviewed By: RSNara
Differential Revision: D56807993
fbshipit-source-id: 6c9aa74db15e04b8ab632d230b3e525363a4d1ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44399
Improves the result of `mockComponent` in React Native's Jest environment so that it has an accurate `name` property.
This will be important when React enables deriving component stack locations via error stack frames.
Changelog:
[General][Changed] - `mockComponent` now also mocks `name`
Reviewed By: kassens
Differential Revision: D56914915
fbshipit-source-id: 1bea3e8773c56f70a89d2171c436f85178676373
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44380
* setInterval's second argument is optional, and defaults to 0
* setTimeout is spec'ed to return a positive integer.
There's also no need to use HostObjects here to represent the timer index, it just hurts performance and makes this code more complex for no clear reason.
Changelog: [General][Fixed] New architecture timer methods now return integers instead of an opaque object.
Reviewed By: RSNara
Differential Revision: D56863422
fbshipit-source-id: fd3e75303662d865083d01e2bfe8633bac151a0e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44385
The current core autolinking is failing if a dependency doesn't have an `android` block.
Instead we should filter out all the dependencies that don't have an `android` definition when generating code.
Fixes https://github.com/reactwg/react-native-releases/issues/276
Changelog:
[Internal] [Changed] - RNGP - Fix core Autolinking attemping to link dependencies without a `android` block
Reviewed By: blakef
Differential Revision: D56876267
fbshipit-source-id: 900b13bec697fceac50c994f277621a10e281410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44377
Changelog: [iOS][Deprecated] deprecate RCTRuntimeExecutorModule
After we make CallInvoker available to native modules, we don't need this. Document it and mark it as deprecated.
Reviewed By: RSNara
Differential Revision: D56848799
fbshipit-source-id: 5628eef01a53bfd29d5b89c0398a938bdd87b0ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44378
Changelog: [iOS][Added] introduce CallInvoker support in bridgeless native modules
I am adding this API in favor of RCTRuntimeExecutor. CallInvoker is now preferred because after #43375, the CallInvoker has access to the jsi::Runtime. Since the community is using CallInvoker already for their async access use cases, CallInvoker is the preferred choice of RuntimeExecutor / RuntimeScheduler because of easier migration. Also, having a wrapper like CallInvoker will give us more flexibility in the future if we want to expand this API.
Reviewed By: RSNara
Differential Revision: D56807994
fbshipit-source-id: 5c3585356d016a50645eda3af2d3bbe00298b4e4
Summary:
The motiviation of this change is to produce sorted / stable native module schemas which members are alphabetically sorted. The benefit is mainly for verifying test fixtures as now new test cases will be inserted at predicatable spots.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56741776
fbshipit-source-id: 842af73cac3b4859d2074e6a5206015924e87201
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44379
A common pattern to implement `ViewManagerOnDemandReactPackage` is to use a `getViewManagersMap` helper. If we capture `ReactApplicationContext` there, we will indefinitely retain the the very first ReactApplicationContext, and break/leak across reloads. Instead we should pass the `ReactApplicationContext` whenever we construct the ViewManager.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D56838427
fbshipit-source-id: 76583dd7f5564ed29f0dbfcef33d8d288cbb90e0
Summary:
Clean this up, now that there is only one TextLayoutManager.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801446
fbshipit-source-id: 1b81a16031ab520d06d8935000d5019609f8a254
Summary:
No longer used after last diff.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56801475
fbshipit-source-id: 45320418493cb47cc9df192de3dcc73284005fb4
Summary:
These are all either dead, or duplicate code (e.g. for spannable cache). Let's delete it, so we can get rid of the redundant TextLayoutManager that is no longer getting new updates.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56800381
fbshipit-source-id: 264c2ede43b765ff094d3d3976ad8535579cc4d9
Summary:
This prop was introduced into horizontal <ScrollView/> in D35735978.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854758
fbshipit-source-id: 2b25296a065b01f11aa04c2ff06cabf64ff5fce1
Summary:
This prop was introduced for horizontal and vertical scrollview in D40642469.
That diff updated the native view configs only.
**Note:** This prop did not work for bridgeless mode.
Partial fix: Add the prop to vertical scrollview: D54223244
Full fix: this diff.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56854757
fbshipit-source-id: aff2da407f4df4575ceb66d3d381a144fa07a8e9
Summary:
The margin/padding props were introduced in this diff: D41267765
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56846578
fbshipit-source-id: 396cab3fdd63d9c630690157a385f1ae53208bb7
Summary:
The insets props were introduced in this diff: D42193661
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849870
fbshipit-source-id: 7be2a5825086ac954fdb8bc3bb86b57a2fa6d326
Summary:
onClick was made into a capture event in this diff: D45745906
- Partial fix: D51551255
- Full fix: this diff.
**Note:** This prop did not work for bridgeless mode.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D56849867
fbshipit-source-id: 15acc16b162e0dd17513c6452008331e3fee4526
Summary:
As pointed out by liamjones here:
https://github.com/facebook/react-native/pull/44214#discussion_r1587755403
The original PR did introduce a bug in the `find/first` check, but in my testing, we do need to look at `group.name`, so let's make sure we check both.
This also makes it play nice with an existing file even if it is added to a different directory, by appending to it instead of forcing it to exist in the main group.
## Changelog:
[IOS] [FIXED] - Fix privacy aggregation
Pull Request resolved: https://github.com/facebook/react-native/pull/44390
Test Plan: Tested on rn-tester
Reviewed By: cipolleschi
Differential Revision: D56893594
Pulled By: philIip
fbshipit-source-id: b92589bc2bed9d07e9af20c56a8b9f6c61d864f0
Summary:
This is a major sync, featuring our recent rebase of `chromium/6344`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56884975
fbshipit-source-id: bc91f66bfc92464ab8fa99893ab0181077041b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44339
We require the wrapper code for in repository calls to these packages directly from node (i.e. using CommonJS). This wrapper code typically sits at the entrypoint of the build packages (i.e. `index.js`).
NOTE: This unblocks an issue preventing me from landing further work on the `helloworld` cli replacing the community template.
## Problem:
The [flow-api-translator](https://www.npmjs.com/package/flow-api-translator) library doesn't allow CommonJS `module.exports` when generating TypeScript Type Defintions.
## Change
1. At the built time, this strips out our wrapper code and sets up the dist/ folder appropriately for npm distribution.
2. Updated the `package.json` files to consistently share Flow types
Changelog: [Internal] refactor build packages output to remove wrapper.
NOTE: Added better error messages when users deviated from the current pattern:
{F1501571608}
Reviewed By: huntie
Differential Revision: D56762162
fbshipit-source-id: f110b31e4ad780998dbc81a2482891ac8d8c6458
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` & `handleReloadJS()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `shouldShowDevMenuOrReload()` returns true in RELEASE as well which is a bug.
Since there is no need for `shouldShowDevMenuOrReload()` in RELEASE, changing it's logic to introduce that check, early exit and return false in case of RELEASE.
Changelog:
[Android][Fixed] shouldShowDevMenuOrReload() in RELEASE mode
Reviewed By: RSNara
Differential Revision: D56851473
fbshipit-source-id: e9e12b0bec8aead5e9227fcd676459ca54490b61
Summary:
In RELEASE mode, the `devSupportManager` received is ReleaseDevSupportManager for which `showDevOptionsDialog()` is a no-op
https://github.com/facebook/react-native/blob/main/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/devsupport/ReleaseDevSupportManager.java#L66
Which is expected since this is a capability only in Dev mode(useDeveloperSupport = true). However, ATM `onKeyLongPresss()` returns true in RELEASE as well which is a bug.
Since there is no need for `onKeyLongPress()` in RELEASE, changing it's logic to introduce that check and return false in case of RELEASE.
Changelog:
[Android][Fixed] onKeyLongPress() in RELEASE mode
Reviewed By: christophpurrer, RSNara
Differential Revision: D56850466
fbshipit-source-id: 92d2c8572b32d065f5f9d54e22588bb085b9dcc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44361
In order to keep all platforms in sync (Android, iOS, Windows, etc.), it makes sense to consolidate all C++ TurboModules that we want available by default on all platforms to a shared C++ header / implementation.
This moves the duplicated code from Android and iOS to such a shared module provider and updates relevant build specs.
## Changelog
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56835783
fbshipit-source-id: 7322ed054ded5749973885c63257e5caf23b3fc3
Summary:
Changelog: [Internal]
A very similar diff was attempted with D50647971 and reverted in D51617862. The main difference here is all behavior is gated behind the feature flag. Before, we were enqueuing the extra frame callback on start_animating_node even if ondemand choreographer was disabled.
Reviewed By: javache
Differential Revision: D56085369
fbshipit-source-id: fa6335303fe98199b18fa2b4819110afb8efcc0d
Summary:
ViewManagers are all BaseJavaModule, and thus have access to methods like `getReactApplicationContext`. We don't expose the appropriate constructors though to pass this context down from the base class.
Not a breaking change, as the no-arg constructor is still used implicitly.
Changelog: [Android][Fixed] ViewManagers can pass context to their base class.
Reviewed By: fabriziocucci
Differential Revision: D56804318
fbshipit-source-id: b0e6b15dfd7786073da058beccfaba2ff30daf5a
Summary:
In a future release of React Native, string refs will no longer be supported. This increases the severity of the `no-string-refs` lint rule to convey this.
Changelog:
[General][Changed] - `no-string-refs` is now a lint error
Reviewed By: kassens
Differential Revision: D56826663
fbshipit-source-id: 603f5b205bb9fd8a5dcb8ee917f6a2ba1ac47e6e
Summary:
Changelog: [Internal]
Updates the doc comment on `Function::createFromHostFunction` to
mention that (a copy of) the provided `std::function` may be destroyed
on an arbitrary thread, much like `HostObject` (where this is already
documented).
Reviewed By: neildhar
Differential Revision: D56628194
fbshipit-source-id: 1939602135e83a9c36896c395816054376026edc
Summary:
This change removes a couple of method from RCTHost which were not following the iOS convention for names.
We deprecated them in 0.74 and now that the branch is cut, we can remove them.
## Changelog:
[iOS][Breaking] - Remove `getSurfacePresenter` and `getModuleRegistry` from RCTHost
Reviewed By: sammy-SC
Differential Revision: D56633554
fbshipit-source-id: 88fd1525bfe68ca1f6c2d8403d0dec505a23e9f8
Summary:
We [received an issue](https://github.com/react-native-maps/react-native-maps/issues/5042) in OSS where a ViewManager was configured to be initialized on the main queue, but it wasn't.
This was creating a soft crash and showing a RedBox to the user.
The library was going through the Interop Layer.
This change makes sure that, if the ViewManager is configured to be setup in the main queue, we retrieve the constants from the Main Queue
## Changelog
[iOS][Fixed] - Extract the constants from ViewManagers in the UI Thread if needed.
Reviewed By: sammy-SC
Differential Revision: D56762253
fbshipit-source-id: ca807b34d6e61418da9fd6a639a05f3394879f7c
Summary:
Changelog: [internal]
Migrating this feature flag (which is currently unused) to the new system, so we can test it in production and ship it soon.
Reviewed By: NickGerleman
Differential Revision: D56766553
fbshipit-source-id: 42d44cdd163568564e789cdffe1683e78fe91b53
Summary:
This work is based on Ruslan's https://www.internalfb.com/intern/diff/D56185630/
Changelog: [Internal]
`Expectation`: In React DevTools, user should be able to select an element on screen and it will show you what React component rendered it. This doesn't work in RN app that is using JS navigation
`Root Cause`:
In Fabric, when we try to find `ShadowNode` in the `ShadowTree`, `pointerEvents` props are not considered during the lookup of node using coordinate. Hence, in React DevTools when we inspect element, it was hightlighting the overlay `View` with `pointerEvents` props `box-none` was getting highlighted instead of its children view in the hierarchy.
Reviewed By: javache
Differential Revision: D56334314
fbshipit-source-id: ebfe58c5a1516add347c2c21ab5d075f804df8a9
Summary:
This removes the bulk of code added in https://github.com/facebook/react-native/pull/39630.
We're not shipping it, as it caused performance regressions.
Changelog:
[Internal]
Reviewed By: christophpurrer
Differential Revision: D56796936
fbshipit-source-id: 82f3a51cf145bc1695d70393e1f050685a1e6174
Summary:
Changelog: [General][BREAKING] Don't support 'float' enums in Turbo Modules
- The current implementation of 'float enums' in C++ does not work as invalid results are returned.
- At potential fix could still cause rounding errors when crossing language bounaries, e.g. `4.6` can become `4.5599999942..`
- C++ enum classes don't support float: https://eel.is/c++draft/dcl.enum#2.sentence-4
> The type-specifier-seq of an enum-base shall name an integral type; any cv-qualification is ignored.
Hence removing the feature of `float enums` for now
Reviewed By: NickGerleman
Differential Revision: D52120405
fbshipit-source-id: 3685ad0629e16ff9db424ba67e07d09df6027553
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44294
**Problem:**
It was discovered while testing 3 party library, generated member variables in a C++ `struct` in `Props.h` is not initialized.
Also `WithDefault` would not work as well.
(For the problematic case it was a `boolean` but would also apply to other primitive types.)
If there is no default initialization and the component prop is optional and the user of the native component does not set the prop then the variable is never initialized and this is problematic for primitive types in C++ where no initialization results in an undefined behavior.
**Proposed solution:**
(Following C++Core Guideline of [always initialize](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always).)
Reusing `generatePropsString()` used by `ClassTemplate` to generate props for `StructTemplate` as well.
updated relevant test snapshots.
This change is only concerning the `Props.h` file.
**Changelog:**
[General][Fixed] - fixed `Props.h` created from codegen missing default initializers in C++ `struct`
Reviewed By: cipolleschi
Differential Revision: D56659457
fbshipit-source-id: 0d21ad20c0491a7e8bb718cd3156da65def72f23
Summary:
As of now, Apple does not respect privacy manifests added as cocoapods resource bundles. This forces react-native developers to manually copy `.xcprivacy` files content for each native dependency that accesses restricted reason APIs to the root file.
This PR adds an aggregation step that crawls through pod dependencies to collect all reasons into the root privacy info file.
## Changelog:
[IOS][ADDED] – Add privacy manifest aggregation.
Pull Request resolved: https://github.com/facebook/react-native/pull/44214
Test Plan:
When run on RNTester, it appends aggregated entries (while keeping existing ones) to existing .xcprivacy file without modifing .pbxproj:

When run on RNTester with the xcprivacy file removed from xcode beforehand, it creates a new .xcprivacy file, and adds it to Compile Bundle Resources in the same way as in the new template:

When run on RNTester with an empty .xcprivacy file, it appends aggregated entries from pods AND reasons for react-native core.
When run with `privacy_file_aggregation_enabled: false` in `use_react_native`, it falls back to existing behavior:

Reviewed By: cipolleschi
Differential Revision: D56481045
Pulled By: philIip
fbshipit-source-id: 1841bad821511c734d0cc0fcff5065ed92af76d8
Summary:
This enables to code-gen base C++ types for custom exported JS types from a RN TM spec - which have been previously excluded from code-gen as these aren't used in any function.
The only work around so far was to ‘register’ a random function using the custom type which should be used for RCTDeviceEventEmitter events
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D56685903
fbshipit-source-id: add9ca40018b91c9fca98609ba3d1f85d3affec1
Summary:
Changelog: [internal]
`LazyShadowTreeRevisionConsistencyManager` wasn't correctly updating the locked revision, because `emplace` is a no-op if there's already a value for the key in the `unordered_map`.
This fixes the issue and adds tests that actually showed it.
Reviewed By: sammy-SC
Differential Revision: D56761941
fbshipit-source-id: 340e9195b14460a591c48186bd365688c74ade04
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44333
Reviewed By: cortinico
Differential Revision: D56756077
Pulled By: cipolleschi
fbshipit-source-id: 4e8d2f6b83499bd89d6a60de4eede385b7a8ac3c
Summary:
`RCTComposedViewRegistry` extends `NSMutableDictionary` which is a clustered class in iOS.
NSMutableDictionary is techncially an abstract class, but when instantiated by `[NSMutableDictionary new];` the system will return one of concrete classes that inherit from `NSMutableDictionary`, opaquely from the perspective of the caller.
By calling `super`, we are actually calling the not implemented method for the abstract class. If this happen, this can crash the app.
Given that the `RCTComposedViewRegistry` is extending the dictionary only for its interface but is using other mechanisms as storage, is it fair to return `NULL`if the storages don't have the requested view.
## Changelog
[iOS][Fixed] - Avoid calling abstract methods in RCTComposedViewRegistry
Reviewed By: cortinico
Differential Revision: D56755427
fbshipit-source-id: f5c56dc59ccc6b30c00199b4196c42eb9b021e2b
Summary:
I accidentally broke build_android.
Here the two fixes:
1. Make sure the constructor of PackageList2 are actually called `PackageList2`
2. Make sure the package of `OSSLibraryExamplePackage` is `com.facebook.react.osslibraryexample`
Changelog:
[Internal] [Changed] - Fix accidentally broken build_android job
Reviewed By: dmytrorykun
Differential Revision: D56756601
fbshipit-source-id: 862597ca829d702d880624d29276193f8548715d
Summary:
Changelog: [Internal]
The bodies of all `console` methods are currently written as lambdas within `installConsoleHandler` but actually capture nothing meaningful from that scope. This diff rewrites them as free functions instead.
To enable the "forwarding console methods" to be written as free functions, we also replace the runtime loop over `kForwardingConsoleMethods` with a compile-time equivalent using macros. (This technique is inspired by the Hermes source code, which uses it heavily for compile-time code generation.)
Reviewed By: huntie
Differential Revision: D56679956
fbshipit-source-id: babf368ecacb9dc426b2356a4a2091881ca1023e
Summary:
Changelog: [Internal]
Switches to constrained `auto` instead of `std::function` to represent intermediate function types in `RuntimeTargetConsole::installConsoleHandler`. This removes some indirection and potential runtime overhead.
Reviewed By: huntie
Differential Revision: D56675188
fbshipit-source-id: 76cbf8b8be9ca1a9466efbcd187bddd60c921019
Summary:
Changelog: [internal]
This migrates all the classes related to performance in `react-native/src/private` to use private fields instead of regular fields prefixed with `_`.
Reviewed By: yungsters
Differential Revision: D55931659
fbshipit-source-id: e8b2018048dbb6c8d6e8a4d143357bf2ac39dd1e
Summary:
Changelog: [internal]
Quick refactor to use private fields instead of fields with a naming convention, in classes in `react-native/src/private`.
Reviewed By: yungsters
Differential Revision: D56700382
fbshipit-source-id: ee0a7b30a9da20c31b92878be3316227b2d0a0c4
Summary:
Adds changelog for the 0.73.8 patch.
## 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] [Changed] - Add 0.73.8 changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44331
Reviewed By: cortinico
Differential Revision: D56753881
Pulled By: cipolleschi
fbshipit-source-id: eed053cd39a768d6acb40a037a4218ee5e1fbbf8
Summary:
Changelog: [internal]
We have a comment explaining how to update all generated files everywhere but here.
Reviewed By: NickGerleman
Differential Revision: D56717344
fbshipit-source-id: cc538e37dd6ab09f67d67bb13ce4e560870d44d0
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating data classes that will allow us to parse the `config` JSON output.
Code is pretty straightforward and follows the structure as the `config` command output.
Changelog:
[Internal] [Changed] - RNGP - Autolinking - Add model classes for parsing the `config` output
Reviewed By: cipolleschi, blakef
Differential Revision: D55475595
fbshipit-source-id: 3457c008ff0c5bce2b47fd637c7b10a5e7427c01
Summary:
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here I'm creating the `runAutolinkingConfig` task.
This task is responsible of either:
- Invoking the `npx react-native-community/cli config` command (or the one specified by the user)
- Copying the config output file specified by the user (if any).
The task re-executes only if any of the lockfile are actually changed otherwise it just returns as "UP-TO-DATE"
This allows us to
Changelog:
[Internal] [Changed] - RNGP - Setup the RunAutolinkingConfigTask to run the config command
Reviewed By: cipolleschi, blakef
Differential Revision: D55475596
fbshipit-source-id: 3c687f965c59eb82fc447546ebd936ba401f34f2
Summary:
Hermes' ConsoleMessage constructor now accepts StackTrace, so the construction can be done in one go.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738060
fbshipit-source-id: 709b47d8f9cf69994e4c5eaa4f9310e70a4d9ed0
Summary:
## Changelog:
[Internal]-
Even though `TextInput.autoCapitalize` is supposed to be cross-platform, on the C++ side of the props data structures it was only exposed as an Android-specific one.
This would have it still work on the iOS side (as the corresponding prop is passed to Objective C around the C++ structs anyway), however it may also cause subtle scenarios, whereas the prop changes dynamically on the iOS side, but this doesn't get reflected on the native side.
This change fixes this problem by simply hoisting the prop into the `BaseTextInputProps`, which makes it available across all platforms, as it should be.
Differential Revision: D56726940
fbshipit-source-id: 9ba18f1f92095874e07207650b46655c331f3e91
Summary:
RuntimeAdapter.h is only needed when using CDPHandler, which the new code path doesn't need.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D56738299
fbshipit-source-id: 8cb512a3dc8dc303851871021e04aab94aa25d1e
Summary:
`Response` is `Closeable`, so we must close it even if the download is no longer relevant. Found while running with StrictMode enabled and reloading quickly multiple times.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D56629079
fbshipit-source-id: 041bf295313cbf78b7f2bb6580c50fdc2a324728
Summary: Changelog: [General][Removed] `launchId` query param for `/debugger-frontend` is no longer generated automatically for each `/open-debugger` call. Caller of `/open-debugger` is now responsible for generating the `launchId`, which will be passed along to `/debugger-frontend`.
Reviewed By: robhogan
Differential Revision: D55164645
fbshipit-source-id: b83303eda77b6fb86ebf50f699d9f308676533c6
Summary:
Supports the removal of Flipper from the template in 0.74, paried with additional blog post messaging: https://reactnative.dev/blog/2024/04/22/release-0.74#removal-of-flipper-react-native-plugin.
Changelog:
[General][Changed] - Update "Open Debugger" action to print extended Flipper guidance
Reviewed By: cipolleschi
Differential Revision: D56705236
fbshipit-source-id: d7e869625262ebb02bc2454c924f832cccfbcd31
Summary:
Just a minor fix to fix a missing space in the debug message.
Fixes a missing space in the message
```
Invariant Violation: TurboModuleRegistry.getEnforcing(...): 'MmkvPlatformContext' could not be found. Verify that a module by this name is registered in the native binary.Bridgeless mode: false. TurboModule interop: false. Modules loaded: {"NativeModules":["PlatformConstants","LogBox","Timing","AppState","SourceCode","BlobModule","WebSocketModule","SettingsManager","DevSettings","RedBox","Networking","Appearance","DevLoadingView","UIManager","DeviceInfo","ImageLoader","LinkingManager"],"TurboModules":[],"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","BugReporting","HeadlessJsTaskSupport","SoundManager","IntentAndroid","MmkvPlatformContext","MmkvCxx"]}
```
## 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] [FIXED] - Fixed missing space in TurboModule.getEnforcing error message
Pull Request resolved: https://github.com/facebook/react-native/pull/44311
Reviewed By: christophpurrer
Differential Revision: D56702036
Pulled By: rshest
fbshipit-source-id: e339a6ee8c265b2c6d27184e8e9941f3f02e3c85
Summary:
## Changelog:
[Internal] -
I was looking at the logs, troubleshooting a non-dev build issue, and noticed a line:
```
I0429 15:56:42.107558 1874554880: Running "MyApplication
```
In `__DEV__` mode this usually continues with `" with ...`, but in release mode the closing quote was missing, which made me think there may be something going on garbling the log messages.
Which ultimately was a red herring, and it's just a bad formatting in the message in release mode, which this change fixes.
Reviewed By: zeyap
Differential Revision: D56704170
fbshipit-source-id: a28604fffec6be74733c8759f59ee52a67a81746
Summary:
Changelog: [Internal]
Fixes a crash that may happen on Android when the `inspectorEnableModernCDPRegistry` feature flag is true, and clarifies the documentation of `HostTarget::create()` to avoid similar issues in future integrations.
## Context
The executor provided to `HostTarget::create()` ("the inspector executor") is used throughout the CDP backend to schedule work on the inspector thread. (See also D53356953.) To facilitate this, the executor is a copyable `std::function`.
On Android, the executor is backed by a Java object, to which we hold a reference from C++ using JNI. This reference is expressed as a `facebook::jni::global_ref` which gets copied as part of the executor. (`global_ref` is a RAII wrapper around the `NewGlobalRef` / `DeleteGlobalRef` JNI functions.)
## The bug
All the *calls* to the inspector executor from C++ happen on threads that are already properly [attached to the JVM](https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html#attaching_to_the_vm) ( = the UI thread / the JS thread) and are therefore allowed to make JNI calls. However, there are cases where a copy of the inspector executor may have its *destructor* run on an unexpected thread, namely the (Hermes) JS GC thread. (This happens when the executor itself is captured in a lambda that's stored in a `jsi::HostObject` or `jsi::HostFunction`, which is in turn [destroyed on the JS GC thread](https://github.com/facebook/react-native/blob/5a0ae6e2d9d7f2357f9ea6c5dc1d573233075326/packages/react-native/ReactCommon/jsi/jsi/jsi.h#L118-L126).) In such cases, the `DeleteGlobalRef` call mentioned above will crash, because the JS GC thread is not attached to the JVM.
## The fix
First, we document that copies of the inspector executor provided to `HostTarget::create` may indeed be destroyed on arbitrary threads. This is an unavoidable consequence of the existing design. Second, we adapt the Android integration to this requirement.
`fbjni` provides the [`jni::ThreadScope`](https://github.com/facebookincubator/fbjni/blob/968e3815f92aeb0670f5d88ae975fbbd47a4b482/cxx/fbjni/detail/Environment.h#L93-L123) RAII helper to manage attaching C++ threads to the JVM. If we had any explicit control over the setup and teardown of the JS GC thread, we could create a single `jni::ThreadScope` to globally ensure the safety of JS-finalizer-to-JNI calls in React Native. However, neither JSI nor the Hermes API provides such control.
Instead, we essentially resort to creating a temporary `ThreadScope` around each `DeleteGlobalRef` call where we don't control the calling thread. We do this using a new kind of JNI reference wrapper class called `SafeReleaseJniRef`. Retaining a `SafeReleaseJniRef` instead of a plain `global_ref` is all that's needed to make a particular reference safe to destroy on any thread.
Reviewed By: huntie
Differential Revision: D56620131
fbshipit-source-id: 0b6f32a7bd6477d0384af19c42e21d9242ce623d
Summary:
This gives Frameworks more control in selecting specific tasks and integrating the return types data in their UI. For example piping `stdout` to the user or using packages like [Listr2](https://www.npmjs.com/package/listr2) to run tasks in parallel and show progress.
The ordering is suggestive (but also enforced by some assertions). Frameworks are free to do what they want.
The order was implicit in the previous data structure with lists of Tasks, but made it difficult to tap into each async task.
I've also had to rework how we transpile the code if directly executed from the monorepo. This keeps our:
- flow types valid,
- allows the core-cli-utils package to be built (to generate TypeScript types and a valid npm module), and
- allows direct transpiled execution as a yarn script.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D56242487
fbshipit-source-id: a1a18f14a4aef53a98770462c8ebdef4111f0ab4
Summary:
Changelog: [Internal]
In the new CDP backend, calling any `console` method a second time involves a call to a moved-from `std::function`. This shouldn't work, and indeed results in an exception on some platforms, but isn't strictly an error according to the C++ standard: moving from a `std::function` leaves it in an [unspecified state](https://en.cppreference.com/w/cpp/utility/functional/function/function#:~:text=the%20call%20too.-,other,is%20in%20a%20valid%20but%20unspecified%20state%20right%20after%20the%20call.,-5), not necessarily an empty state, so (in particular) it's perfectly legal for the implementation to perform a copy instead of a move and leave the original variable intact.
(See [Compiler Explorer](https://godbolt.org/z/qoo5Mnd68) for proof that libc++ and libstdc++ differ on this - the former performs a copy, while the latter actually performs a move, resulting in a `std::bad_function_call` exception later.)
In the code in question, we're right to want to avoid a copy of the `body` function into the argument of `delegateExecutorSync` - only one copy of this function needs to exist at a time. But the correct way to avoid this copy is to capture `body` by reference, as we can do that repeatedly with no ill effects. (`delegateExecutorSync` is, as its name suggests, synchronous, so there are no lifetime issues.) Doing this also allows us to remove the use of `mutable` so the capturing is by *const* reference.
Reviewed By: sammy-SC
Differential Revision: D56673529
fbshipit-source-id: b235977b2fbc889462c4c78adfe41ae6f509e349
Summary:
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56678530
fbshipit-source-id: c602e065d77fdd649c66ce2d26eee83428ef5ba8
Summary:
Resolved Pull request: https://github.com/facebook/react-native/pull/44296
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: javache
Differential Revision: D56632286
fbshipit-source-id: e942603d3c69d9eebf4d3b64e2f73ee6a5df6de4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44295
changelog: [internal]
mapbuffer is only used on Android. Let's remove the option to have it compile on iOS.
Reviewed By: NickGerleman
Differential Revision: D56635289
fbshipit-source-id: 1a57c271d21b8aef81179d96b1a6832e7615dd27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44283
changelog: [internal]
force_static doesn't need to be in here, let's remove it.
I change one module per diff. It makes it easier to land it and pinpoint where build failures are coming from.
Reviewed By: christophpurrer
Differential Revision: D56630625
fbshipit-source-id: 069587893dbb8866d1a08de256b4612d60bcc3b8
Summary:
changelog: [Android][Fixed] - fix a crash in Modal component
Instance variable `propertyRequiresNewDialog` in `ReactModalHostView` controls if new dialog will be created on next `showOrUpdate` or not. It must be kept in sync with `dialog` ivar.
if `dismiss` is ever called from anywhere but `showOrUpdate`, the class gets into a state where the next `showOrUpdate` call will throw an error because dialog is set to null but `propertyRequiresNewDialog` stays false.
`dismiss` is called from three places: `showOrUpdate` (this is ok), `onDropInstance()` and `onDetachedFromWindow`.
The fix in this diff is to make sure propertyRequiresNewDialog is set to true when dialog is dismissed.
Reviewed By: alanleedev
Differential Revision: D56627522
fbshipit-source-id: e7a16cd022401a7a4a0fbf8fc71a2312d05fcb8e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44140
Why?
Previously we didn't support using percentages like:
```
style={{
width=100,
height=100,
borderRadius='100%',
}}
```
These percentages refer to the corresponding dimension of the border box.
What?
Change the unit type for `BorderRadii` values to `ValueUnit`. This type allows us to have an object containing a `float`, and a `UnitType` properties. With this we conditionally calculate the corresponding point (dp) value for a given percentage (considering size). Ex:
```
result = {raw_percentage_value} / 100 * (max(height, width))
```
We know the maximum border radius for our current implementation is half the dp of the shorter side of our view, hence why we consider half our maximum view side as equivalent to 100%.
Note: We still don't support vertical/horizontal border radii
## Changelog:
[iOS][Added] - Added support for using percentages when defining border radius related properties.
Reviewed By: NickGerleman
Differential Revision: D56198302
fbshipit-source-id: 6cd510b1c7164dcb82ca5ad8a9861c5ce5c8b15b
Summary:
Non-uniform edge insets caused issues on iOS 10. The code nowadays interferes with the rendering for large borderRadii so this diff removes it.
Since we didn't support this behavior before there are some bugs/missing features that happen:
T186810893 Incorrect border rendering with large radii
T186812303 View discoloring with overlapping border radii
T186812736 Add support for vertical and horizontal border radii
## Changelog:
[iOS][Fixed] - Removed Legacy iOS 10 code messing with border radius
Reviewed By: NickGerleman
Differential Revision: D56333637
fbshipit-source-id: 92b1bb1459d1e95476b3d768db725dfbbc1e55ae
Summary:
`flow-api-translator` can't handle `module.exports`. Shift this to ESM style exports like the other built packages.
Changelog: [Internal] - Fixing an internal build script broken by D56243647
Reviewed By: cipolleschi
Differential Revision: D56638506
fbshipit-source-id: f5a4c7bea06b7f95300388e3d37cf0d377bc3b17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44220
This diff is part of RFC0759
https://github.com/react-native-community/discussions-and-proposals/pull/759
Here we're looking into splitting the autolinking into a component that will live inside core (specifically inside the React Native Gradle Plugin - RNGP) and another component that will live inside the Community CLI.
Here I start by adding 2 fields to RNGP extension, that frameworks and templates can use to provide their autolinking config.
Changelog:
[Internal] [Changed] - RNGP - Add autolinking fields to ReactExtensions
Reviewed By: cipolleschi
Differential Revision: D55475597
fbshipit-source-id: 316d1919a113a94c57426710f487f334c6128345
Summary:
We ran CodeQL in react-native-windows and it found a comparison of narrow type with wide type in loop condition in ReactCommon/react/renderer/core/RawPropsKeyMap.cpp
microsoft/react-native-windows#12701
## Changelog:
[INTERNAL] [SECURITY] - Fix comparison of narrow type with wide type in loop condition in RawPropsKeyMap.cpp
Pull Request resolved: https://github.com/facebook/react-native/pull/44262
Test Plan: Tested on windows.
Reviewed By: cipolleschi
Differential Revision: D56628137
Pulled By: javache
fbshipit-source-id: 9ff3bd3cbcfd084efc1e01180ff01529d1be02eb
Summary:
In addition to memoizing `mergedStyle` in `createAnimatedComponent`, this avoids unnecessary object allocations by:
* Not allocating `passthroughProps`, created via a rest spread operator. It is unnecessary because we always override `style` in the JSX.
* Not allocating a new object if either `style` or `passthroughStyle` are null or undefined. Also, create an array of the two style objects instead of spreading them, which is needless.
Changelog:
[General][Changed] - Improved performance of `Animated` components
Reviewed By: sammy-SC
Differential Revision: D56621191
fbshipit-source-id: ac863661c60d87c681284ce5ef5d6774b9c50653
Summary:
Changes two important aspects of `StyleSheet.compose`:
- Extract it from `StyleSheet` so that it can be imported from other internal modules without incurring circular dependencies. (Surprisingly, `StyleSheet` has a lot of dependencies.)
- Avoid a redundant `style1 != null` check.
Changelog:
[General][Changed] - Optimized performance of `StyleSheet.compose`
Reviewed By: sammy-SC
Differential Revision: D56621407
fbshipit-source-id: f899b50d9f13f1514485371c8513a85be78eae24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44239
A simple CLI to build our iOS `helloworld` application. This isn't intended for an audience other that the release team.
Some Framwork authors might be interested in it as an example of how to use our react-native/core-cli-utils to build a React Native application.
Changelog: [Internal]
I'm not going to export because it's not that interesting to folks outside / in need of scrutiny.
Reviewed By: cipolleschi
Differential Revision: D56243647
fbshipit-source-id: a5f1b6d1046bda165aa7c6848938e05f0cca2dc8
Summary:
On the new architecture on Android on the new arch, `textAlign` style was ignored (`Layout.Alignment.ALIGN_NORMAL` was always used) during the measurement of text. During this phase, the positions of attachments are also calculated, which results in inline views being always positioned as if alignment to the left was set. This PR updates the measurement logic to also take `textAlign` into account during measurement.
Fixes https://github.com/facebook/react-native/issues/41008
## Changelog:
[ANDROID] [FIXED] - Fixed `textAlign` not being taken into account when positioning views inlined in text
Pull Request resolved: https://github.com/facebook/react-native/pull/44146
Test Plan:
<details>
<summary>I've been testing on the following code</summary>
```jsx
import { SafeAreaView, Text, View } from "react-native";
function InlineView(props) {
return (<View style={{margin: 10}} >
<Text style={{ textAlign: props.textAlign, backgroundColor: 'cyan' }}>
Parent Text
<Text style={{ fontWeight: 'bold' }}>Child Text</Text>
<View style={{width: 50, height: 50, backgroundColor: 'red'}} />
<Text style={{ fontWeight: 'bold' }}>Child Text</Text>
{props.long && <Text style={{ fontWeight: 'bold' }}>aaaa a aaaa aaaaaa aaa a a a aaaaa sdsds dsdSAD asd ASDasd ASDas</Text>}
</Text>
</View>)
}
export default function Test() {
return (
<SafeAreaView style={{ flex: 1 }}>
<Text style={{textAlign: 'center', fontSize: 20}}>BoringLayout</Text>
<InlineView textAlign="left" />
<InlineView textAlign="center" />
<InlineView textAlign="right" />
<InlineView textAlign="justify" />
<Text style={{textAlign: 'center', fontSize: 20}}>StaticLayout</Text>
<InlineView textAlign="left" long />
<InlineView textAlign="center" long />
<InlineView textAlign="right" long />
<InlineView textAlign="justify" long/>
</SafeAreaView>
);
}
```
</details>
| Old architecture | New architecture |
|------------------|------------------|
| <img width="447" alt="Screenshot 2024-04-18 at 17 08 59" src="https://github.com/facebook/react-native/assets/21055725/b21848ff-3939-4dde-9f78-03ce50c9429a"> | <img width="447" alt="Screenshot 2024-04-18 at 17 04 46" src="https://github.com/facebook/react-native/assets/21055725/fb57a3c4-09e8-4db7-abc3-79747314529b"> |
Reviewed By: NickGerleman, cipolleschi
Differential Revision: D56361169
Pulled By: cortinico
fbshipit-source-id: c3002f65541774e376e315c3076a6157aa330f8d
Summary:
Based on a more recent 14.x.x release of Listr.
Changelog: [Internal]
These are direct copies from `xplat/js/flow/{listr,rxjs_v6.x.x}.js`
Reviewed By: huntie
Differential Revision: D56576985
fbshipit-source-id: c850c89891bf8eb57586a5e2a50f0204fd885f65
Summary:
Any component wrapped via `createAnimatedComponent()` will always re-render, because it creates a new `style` object. It's impossible to memoize.
Adding `useMemo()` here ensures that the `style` object passed to the underlying object is stable: if no `style` is passed to the wrapped component, then memoization can work.
Allowing memoization to function when the `style` object is passed in will require a deeper fix. See https://fb.workplace.com/groups/rn.support/permalink/26084643474490921/
Before:
{F1496803038}
After:
{F1496805410}
## Changelog:
[General] [Fixed] - Fixed memoization for components wrapped with createAnimatedComponent
Differential Revision: D56618868
fbshipit-source-id: a0af8b1a02c34b5cf6e6d7e9f0381fb323b232cc
Summary:
While the class and constructor are referenced from native code, the constructor is only accidentally retained on the Java side without proper keep rules. Adding explicit DoNotStrip in the code here.
Changelog: [Internal]
Reviewed By: beicy
Differential Revision: D56529943
fbshipit-source-id: 5459b7d32ada5eeb1fabff1dfc796c2f81d3bb96
Summary:
One way we register cxx turbo modules with React Native is via cxxreactpackages.
This diff allows the application to pass in cxxreactpackages into the default react host, which allows the application to, in turn, register cxx modules with react native!
Changelog: [Android][Added] - Allow bridgeless apps to register cxx modules via cxxreactpackages
Reviewed By: cortinico
Differential Revision: D56547493
fbshipit-source-id: 4e8f02f0546c4b647a915fc65ea9687aa1592190
Summary:
We might want to publish some new versions of React Native with experimental feature to allow some partners to test whether those versions fixes some reported issues, before creating a proper stable version for the whole ecosystem.
The infra is mostly [setup for this](https://www.internalfb.com/code/fbsource/[496a64d180faab501b8598aa0ec26d47454fb961]/xplat/js/react-native-github/scripts/releases/utils/version-utils.js?lines=149), already. The only detail we need to take care of is not to move the `next` tag.
## Changelog:
[Internal]
Reviewed By: cortinico, huntie
Differential Revision: D56578456
fbshipit-source-id: 8dcc674aab5f85077c1b3e6580c5aeb99226eff8
Summary:
There are a couple scenarios where flattening the child of a ScrollView can cause problems.
1. `maintainVisibleContentPosition` on both Android and iOS rely on reading live positions in the view tree
2. `snapToAlignment` on Android uses live view tree, for items to snap to. iOS seems to have very different behavior, and aligns assuming that children are scroll view height, or that a snap interval has been set.
This change adds a prop `collapsableChildren` which can be used to disable children of scroll content view from being collapsed.
Differentiator is... complicated... but we can mostly just adapt the code dealing with existing traits at the surface level.
Changelog:
[General][Fixed] - Automatically disable flattening of scroll content view children when needed
[General][Added] - Add `collapsableChildren` prop
Reviewed By: javache
Differential Revision: D56226241
fbshipit-source-id: ed81f7fff5a15eac424708f763afc9b844aefa9c
Summary:
Flow shouldn't consider definitions inside this folder. This speeds up working in the OSS checkout if you happen to have Hermes built.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D56575537
fbshipit-source-id: 8e5cdd0436712322a4a7298a24c721d9659d98af
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44256
## Changelog:
[iOS] [Fixed] - Preserve content offset in ScrollView when the component is suspended
# The problem
On iOS, components are recycled. For ScrollView, its content offset has to be reset back to original position. When we call `[UIScrollView setContentOffset:]`, it triggers all of its delegate methods and triggers `scrollViewDidScroll` where we set native state.
So when user scrolls to position 100 and scroll view suspends. it is removed from view hierarchy and recycled. Once the suspense boundary is resolved, scroll view will be inserted back into view hierarchy. But when it was recycled, we set back its original content offset (the default is 0, 0) but this was accidentally propagated through to shadow tree.
# Solution
To avoid this, we simply need to invalidate `_state` before calling `[UIScrollView setContentOffset:]`.
Reviewed By: cipolleschi
Differential Revision: D56573370
fbshipit-source-id: c03d7d2d403af2e1649b4cf189072baeb4c286c8
Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Defines module for `React-jsinspector` that for swift modules to integrate with.
to fix https://github.com/expo/expo/issues/28209, any podspec depends on HermesExecutorFactory should use ` add_dependency(s, "React-jsinspector", :framework_name => 'jsinspector_modern')` to add dependency. otherwise it will encounter the header not found issue because use_frameworks will change "jsinspector-modern" to "jsinspector_modern".
to depend on React-jsinspector from expo-modules-core, we need it to define as a module.
otherwise, it will have the error
```
The Swift pod `ExpoModulesCore` depends upon `React-jsinspector`, which does not define modules. To opt into those targets generating module maps (which is necessary to import them from Swift when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or specify `:modular_headers => true` for particular dependencies.
```
## Changelog:
[IOS] [CHANGED] - Add `DEFINES_MODULE` for React-jsinspector.podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/44252
Test Plan: ci passed
Reviewed By: cortinico
Differential Revision: D56575102
Pulled By: cipolleschi
fbshipit-source-id: 9b7b4568a3e499f0a741a79a846263118ff2d112
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44231
changelog: [internal]
The flag is not used and is statically set to false, let's delete it.
Reviewed By: NickGerleman
Differential Revision: D56473851
fbshipit-source-id: fe1076d20a765ffed2437f080764f2b5fe060bb6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44232
changelog: [internal]
surfaceId parameter is not needed `schedulerDidRequestPreliminaryViewAllocation` as it can be derived from shadow node.
Additionally, conversion to ShadowView can happen on the lower layers.
Reviewed By: NickGerleman
Differential Revision: D56350599
fbshipit-source-id: 9c38cc0df36911bbd6927fe0a0d5e64c248d87c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44167
We received an issue for OSS where, when the main window is inactive and the system tries to present a dialog, the dialog is not presented in the right position on the screen.
This change introduce a fallback to the first inactive window (which is still visible on screen) and it fixes the issues.
## Changelog:
[iOS][Changed] - Fallback to the first `foregroundInactive` window when there are no `foregroundActive` windows in RCTKeyWindow
Reviewed By: dmytrorykun
Differential Revision: D56354741
fbshipit-source-id: fa23131ecd40f6d91c705879a72890506ee21486
Summary:
Inside [Re.Pack](https://github.com/callstack/repack) we consume command's options, to reduce the amount of assumptions that 3rd party tools need to make - we can move assigning default value to config command level, so default values will be aligned across tools.
For default `start` command this change doesn't change any behaviour.
## Changelog:
[INTERNAL] [CHANGED] - Add `localhost` as default host in `start` command config
Pull Request resolved: https://github.com/facebook/react-native/pull/44244
Test Plan: `start` command should work the same way as before.
Reviewed By: huntie
Differential Revision: D56567793
Pulled By: blakef
fbshipit-source-id: fe8f3686ae39a3d2996de11930a0d03364692adc
Summary:
Web props work (somewhere around D41230978 and D39268920) made it so that numeric font weights can be set instead of just strings. This is implemented by converting number to string before passing to native component within the `Text` component.
We have crash with:
```
2024-04-19 09:38:21.360 16963 17190 E ViewManager: Error while updating prop fontWeight
2024-04-19 09:38:21.360 16963 17190 E ViewManager: java.lang.IllegalArgumentException: method com.facebook.react.views.text.ReactBaseTextShadowNode.setFontWeight argument 1 has type java.lang.String, got java.lang.Double
2024-04-19 09:38:21.360 16963 17190 E ViewManager: at java.lang.reflect.Method.invoke(Native Method)
```
`TextStyleProps` can also be passed to `TextInput`, which passes to underlying native component, without going through this logic. And the types for Native props directly derive from JS props, so type system does not catch passing incorrect number type to underlying native component.
This does a quick and dirty replication of the exact logic in `Text.js` to `TextInput.js`. I'd love to potentially fix this up for Fabric in a different way when we rethink CSS parsing.
Changelog:
[General][Fixed] - Handle `fontWeight` normalization for TextInput component
Reviewed By: arushikesarwani94
Differential Revision: D56539571
fbshipit-source-id: 8975886c117d814a624f817bffe408841bb03b88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44236
## Changelog:
[Android] [Fixed] - fix a case when view preallocation or props forwarding on Android lead to dropped props update
# What does this fix
This fixes a bug where prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`.
This affects android only and when batched rendering is enabled.
There are two root causes of this problem:
1. View preallocation on Android: https://fburl.com/code/r62p3vot
2. Prop forwarding on Android: https://fburl.com/code/644f1ppk
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is combination of view preallocation and batched rendering updates.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
# The fix
The fix is to change two things:
1. Ignore view preallocation for shadow nodes which were cloned with new props.
2. Set hasBeenMounted flag on ShadowNode later in the Fabric pipeline to fix it.
Both of these are hidden behind a single feature flag: `fixMountedFlagAndFixPreallocationClone`
## Performance implication:
I estimate that this will impact around 3% of views.
Reviewed By: rubennorte
Differential Revision: D56353589
fbshipit-source-id: 651d3cd2d0f78bfbbe9c05aa1ae1b1690c15e4ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44188
The current approach used for `batchRenderingUpdatesInEventLoop` is not compatible with Android due to limitations in its props processing model. The raw props changeset is passed through to Android, and must be available for the Android mounting layer to correctly apply changes.
We have some logic to merge these payloads when multiple ShadowNode clones take place but were previously assuming that a ShadowTree commit was a safe state to synchronize.
In the current implementation this means that two commits driven from layout effects (triggering states A → B → C) may cause Android to observe only the B → C props change, and miss out on any props changed in A → B.
Changelog: [Android][Fixed] Cascading renders were not mounting correctly when `batchRenderingUpdatesInEventLoop` is enabled.
Reviewed By: rubennorte
Differential Revision: D56414689
fbshipit-source-id: 7c74d81620db0f8b7bd67e640168afc795c7a1d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44233
The package was added to our build scripts, but shouldn't have been. We're not exporting this package or making it public.
Changelog: [Internal]
This should unblock our OSS CI.
Reviewed By: cipolleschi
Differential Revision: D56513694
fbshipit-source-id: f37c75871253b2570fb933175165d8f0a9593a16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44197
Changelog: [General][Breaking] Remove executeAsynchronously and executeSynchronously_CAN_DEADLOCK
these are not used anywhere nor in OSS, we can delete this safely
Reviewed By: javache
Differential Revision: D56447959
fbshipit-source-id: d66c10f676946422385750c1b8825ead2d5d0ed8
Summary:
This is a copy of the current packages/react-native/template that we exclusively use internally for testing.
Changelog: [Internal]
NOTE: Best contribution would be to scan the file list and ensure there isn't anything that shouldn't be in there.
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D56242484
fbshipit-source-id: 0913ff7acff9b0314b49f48e986674b77dbb908e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44209
## Changelog:
[Android] [Fixed] - When React Native is destroyed, unmount all Fabric surfaces.
Previously, Fabric surfaces would not be torn down. Meaning that passive and layout effects wouldn't be unmounted and surface infra wouldn't be cleaned up.
For example:
```
useEffect(() => {
return () => {
console.log('unmounted');
}
)};
```
When calling `ReactNativeHost.clear()` on Android in native code, the above effect should be unmounted.
This is a requirement for Fabric.
Reviewed By: javache
Differential Revision: D56238947
fbshipit-source-id: 5dbf5cdef520f34c78953c2b8f2d42349549e893
Summary:
This decouples the listing of modules from the linking of those modules into Cocoapods. I've made this backwards compatible, but our internal template wont lean on the community config.
The user can now override how they capture a list of React Native modules, providing an escape hatch for Framework authors to build on.
Changelog: [General][iOS] Use our fork of the react-native-communti/cli-platform-ios use_native_modues.rb script
Reviewed By: cipolleschi
Differential Revision: D56242486
fbshipit-source-id: 78505669ab6abd6718348388c3bfba3290f7071b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44206
Changelog: [internal]
We finally managed to implement mount hooks without reliability issues on Android, so we can clean up the feature flag and enable it unconditionally.
Reviewed By: cortinico
Differential Revision: D56467379
fbshipit-source-id: d797ec770b731135332bc9f39df1c1e684b3bde4
Summary:
This change is a preliminary change to add support to `Long` and `long` React props that are required for supporting WideGamut color space.
## Changelog
[Android][Added] - Extend Property Processor to support long props
Reviewed By: cortinico
Differential Revision: D56461183
fbshipit-source-id: 0f70388abe2b414a09df640f04e767f1164d63ce
Summary:
This adds support for enabling wide color gamut mode for ReactActivity per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738).
## Changelog:
[ANDROID] [ADDED] - Add isWideColorGamutEnabled to ReactActivityDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/43036
Test Plan:
Update RNTesterActivity.kt to enable wide color gamut:
```diff
class RNTesterActivity : ReactActivity() {
class RNTesterActivityDelegate(val activity: ReactActivity, mainComponentName: String) :
// ...
override fun getLaunchOptions() =
if (this::initialProps.isInitialized) initialProps else Bundle()
+ override fun isWideColorGamutEnabled() = true
}
```
Reviewed By: cortinico
Differential Revision: D55749124
Pulled By: cipolleschi
fbshipit-source-id: 44dd5631e1a2e429c86c01ed8747bbebbc8bdb3b
Summary:
This adds support for color function values to ColorPropConverter per the wide gamut color [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It updates the color conversion code so that it returns a Color instance before ultimately being converted to an Integer in preparation for returning long values as needed.
bypass-github-export-checks
## Changelog:
[ANDROID] [ADDED] - Update ColorPropConverter to support color function values
Pull Request resolved: https://github.com/facebook/react-native/pull/43031
Test Plan:
Colors should work exactly the same as before.
Follow test steps from https://github.com/facebook/react-native/pull/42831 to test support for color() function syntax.
While colors specified with color() function syntax will not yet render in DisplayP3 color space they will not be misrecognized as resource path colors but will instead fallback to their sRGB color space values.
Reviewed By: cortinico
Differential Revision: D55749058
Pulled By: cipolleschi
fbshipit-source-id: 37659d22c1db4b1a27a9a4f88c9beb703517b01f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44182
## Changelog:
[iOS] [Fixed] - Fixed stale state on TouchableOpacity and TouchableBounce
When TouchableOpacity and TouchableBounce are unmounted, we need to reset their state. This includes animation state. If we don't do that, view is unmounted on the mounting layer and animation will not be applied. This leaves view in undefined state. In TouchableOpacity, it is view with reduced opacity. TouchableBounce that is view with applied transform.
This was reported in https://github.com/facebook/react-native/issues/44044
Reviewed By: rubennorte, cipolleschi
Differential Revision: D56416571
fbshipit-source-id: 01214ec8a5e07c80a609e082b955a30305ad8396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44196
Changelog: [Internal]
BufferedRuntimeExecutor is unnecessarily coupled with these other targets (React-runtime, React-cxxreact), break that dependency so we can modularize this file
Reviewed By: realsoelynn
Differential Revision: D56382644
fbshipit-source-id: ed9725fbddcda04b73c583d927351440b4fc3328
Summary:
After creating a new project with `npx react-native init`, line 39 in `project.pbxproj` contains both spaces and tabs for indentation (accidentally introduced in 520d120375). This line will be unnecessarily touched and rewritten by a subsequent `pod install`.
Fix the indentation by replacing 4 spaces with one tab character (the Xcode managed file exclusively uses tabs for indentation).
## Changelog:
[GENERAL] [FIXED] - Fix space/tab indentation in template project.pbxproj
Pull Request resolved: https://github.com/facebook/react-native/pull/44186
Test Plan: Generate project again with change and observe that the file will be generated with the expected indentation.
Reviewed By: NickGerleman
Differential Revision: D56439289
Pulled By: arushikesarwani94
fbshipit-source-id: ced9f0c94757a4925cd01673c65f2c38d28629e6
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there was a callsite to fstat in our forked copy of glog, so use C617.1.
callsites:
- glog/src/logging.cc
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625116
fbshipit-source-id: b10ea2dad2238cc85b5fe30df56269a5808a35b5
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to fstat variants in our forked copy of boost, so use C617.1.
callsites:
- RCT-Folly/folly/FileUtil.h
- RCT-Folly/folly/portability/SysStat.h
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625114
fbshipit-source-id: fb388f474e62543828218925b0d409d4b558c3db
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
from the audit there were callsites to mach_absolute_time and fstat variants in our forked copy of boost, so use 35F9.1 and C617.1 respectively.
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: cipolleschi
Differential Revision: D55625113
fbshipit-source-id: 0dcd216116595d1bb14e6b843f711aac68f84e5c
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (JSBigString)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55624716
fbshipit-source-id: 400e9852a64e7f9fd9e32225b199f2664a069fc2
Summary:
Changelog: [Internal]
add this to the framework's resource bundle
reasons:
- C617.1 (RCTJavaScriptLoader)
- CA92.1 (RCTI18nUtil, RCTBundleURLProvider, RCTSettingsManager)
current problem with this method is that the required reasons are not currently be aggregated during app store review, so those need to live in the app's. but go ahead and add it here for now, i think apple will try to fix it.
Reviewed By: sammy-SC
Differential Revision: D55622471
fbshipit-source-id: f6ab864f51d4fa6e20f5de4fd56d8126d55dea8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
codegen generates type alias for array enum props with uint32_t which cause wrong overloaded fromRawValue to call at runtime eventually app to terminate
more detailed info at issue https://github.com/facebook/react-native/issues/43821
## Changelog:
[Internal] [Fixed] - Codegen for array enum props
Pull Request resolved: https://github.com/facebook/react-native/pull/44123
Test Plan: TODO
Reviewed By: cipolleschi
Differential Revision: D56414554
Pulled By: dmytrorykun
fbshipit-source-id: 0ec1b65951bc16ff58dd2b119c97a4e3fac2b161
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react-fbsource-import on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
Changelog: [Internal]
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
diff-train-source-id: 13710c68616cf643d3cdfd69e5f39b2dc5a801b4
Generated by: https://www.internalfb.com/intern/sandcastle/job/36028798276627863/
GitHub Repo: facebook/react-fbsource-import
Reviewed By: jackpope
Differential Revision: D56357596
fbshipit-source-id: 171ed7b816869348a1cc3c06a78b3803b86eb7c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44180
Changelog: [General][Changed] Update Chrome launch flags for `--experimental-debugger` launch flow
Internally at Meta, we've been testing the experimental debugger launch flow with a different set of Chrome flags than are currently shipped in open source. This diff fixes those differences:
* Removes `--disable-backgrounding-occluded-windows`
* Adds `--guest`
Reviewed By: EdmondChuiHW
Differential Revision: D56418271
fbshipit-source-id: 884c5746e93cad89f17e4ef9e3ef193a2a454eb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44179
Fix `package.json#exports` main entry point in `react-native/oss-library-example` (which is actually at `packages/react-native-test-library`), to fix a Metro resolver warning on building RN-tester.
`"./": "./index.js"` is intended as an export map entry for the main export, whereas `".": "./index.js"` is correct (see [`PACKAGE_EXPORTS_RESOLVE`](https://nodejs.org/api/esm.html) spec).
Changelog: [Internal]
(This package is not published)
Reviewed By: cortinico, dmytrorykun
Differential Revision: D56414480
fbshipit-source-id: 01874cf11ae687aaf5aa5aa56075232f03d691b8
Summary:
This is a follow-up to https://github.com/facebook/react-native/pull/44075. I've missed the fact that `ReactConstants.UNSET` is `-1` and the default value of `numberOfLines` prop is `0`. This resulted in font size being set to the minimal value when `adjustFontSizeToFit` was used without setting `numberOfLines` to a positive value.
## Changelog:
[ANDROID] [FIXED] - Fixed `adjustFontSizeToFit` when used without `numberOfLines`
Pull Request resolved: https://github.com/facebook/react-native/pull/44165
Test Plan:
<details>
<summary>Tested on the following code</summary>
```jsx
import { Text, SafeAreaView, View, StyleSheet } from 'react-native';
export default function Test() {
return (
<SafeAreaView style={styles.container}>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some text that fits (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some text that fits (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some text that fits (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some text that fits (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some longer text that doesn't fit if displayed in one line (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some longer text that doesn't fit if displayed in one line (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, 2 lines)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, 2 lines)
</Text>
</View>
</SafeAreaView>
);
}
```
</details>
|Old arch|New arch (without this PR)|New arch (with this PR)|
|-|-|-|
|<img width="447" alt="a_old" src="https://github.com/facebook/react-native/assets/21055725/4822f7f1-a19c-4225-9318-0eb2fec6f925">|<img width="447" alt="a_new_no_change" src="https://github.com/facebook/react-native/assets/21055725/ff594673-b362-4a81-8837-624cb1061d28">|<img width="447" alt="a_new_changed" src="https://github.com/facebook/react-native/assets/21055725/1f29c01c-1c91-4c9f-9edd-0950338b5d39">|
Reviewed By: NickGerleman
Differential Revision: D56362020
Pulled By: cortinico
fbshipit-source-id: 2aecbe66043870cf14536850ecbfb7c3890acd72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42115
React Native Android had a concept called JSIModules, which iOS doesn't have. The JSIModule concept was introduced in the early stages of the Fabric project to represent modules that interact with JS through JSI and they are not NativeModules.
In the new architecture this concept is not really necessary and these interfaces were only used to initialize and destroy the Fabric renderer and TurboModule Manager in react native core. Bridgeless mode doesn’t use JSIModule anymore. Also, it has an explicit list of supported JSI module types, so is not open for extension.
In order to simplify RN concepts and reduce confusion with TurboModules, which also "use JSI", deleting everything related to JSIModule. This was already deprecated in 0.74.0.
Please use ReactInstanceEventListener to subscribe for react instance events instead of getJSIModule() and we recommend using TurboModules instead of JSIModules.
Changelog:
[General][Breaking] Delete JSIModule
Reviewed By: javache, cortinico
Differential Revision: D49597702
fbshipit-source-id: bc2bc190aafaf559336b341b50ffabf413474105
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44155
Add ReactSoftException in ReactHostImpl only when `onActivityResult`, `onNewIntent`and `onWindowFocusChange` do not have the context
Changelog:
[Android][Fixed] ReactSoftExceptions in ReactHostImpl only when Context is null
Reviewed By: cortinico
Differential Revision: D56325407
fbshipit-source-id: a9f8fd5772fc05d39e72236fb8edfe5f8a9d6a43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44169
## Changelog:
[General][Changed] Disable new event loop behavior when bridgeless (new architecture) is enabled.
# What is the problem
With event loop, specifically with `batchRenderingUpdatesInEventLoop`, prop change is not delivered to Android mounting layer if the prop change was initiated from state update inside of `useLayoutEffect`, `componentDidMount` or `componentDidUpdate`. Note this has to be a prop change affecting mounting layer directly, not something consumed by Yoga, e.g. background colour or border colour.
This affects android only.
Minimal repro :
```
import React, {useLayoutEffect, useState} from 'react';
import {Button, SafeAreaView, View} from 'react-native';
function Foo() {
const [bgColor, setBgColor] = React.useState('red');
useLayoutEffect(() => {
console.log('useLayoutEffect');
setBgColor('blue');
}, []);
return (
<View
style={{
backgroundColor: bgColor,
width: '100%',
height: '100%',
}}
/>
);
}
function RNTesterApp() {
const [show, setShow] = useState(false);
return (
<SafeAreaView>
<Button title="Toggle" onPress={() => setShow(!show)} />
{show && <Foo />}
</SafeAreaView>
);
}
export default RNTesterApp;
```
# The underlaying problem
The problem is in batched rendering updates and how props are delivered to Android mounting layer.
Here is a step by step what happens in the repro above:
1. React issues asks Fabric to create new shadow node A with background colour **red**.
2. Fabric asks Android to allocate a view for shadow node A with background colour **red**.
3. React commits tree **T1** and calls layout effects. Meanwhile Fabric waits, without trying to mount the tree **T1**, to prevent painting state that is about to be updated and prevent flickering.
4. React clones node A, changing the background colour to **blue** and commits the new tree **T2**.
5. Fabric, will now go ahead and mount the latest tree **T2**. While creating mount instructions, it will drop prop updates because it believes prop updates where delivered already as part of step 2.
At first this might appear as a problem with view preallocation. But the underlaying trouble is that on Android, we currently have no way of knowing how to combine changesets from React into single folly::dynamic.
Reviewed By: javache, cortinico
Differential Revision: D56355863
fbshipit-source-id: f8616ee48e10fc10e129bb632c5d398842220d24
Summary:
On the old architecture `adjustFontSizeToFit` only shrinks the font size when there's too little space, while on the new arch it's also enlarged when there's too much space so that it always takes the entire width. This PR changes this behavior so that it only shrinks the text.
Fixes https://github.com/facebook/react-native/issues/42044
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Fixed font size enlarging when `adjustFontSizeToFit` is set
Pull Request resolved: https://github.com/facebook/react-native/pull/44163
Test Plan:
<details>
<summary>Tested on the following code</summary>
```jsx
import { Text, SafeAreaView, View, StyleSheet } from 'react-native';
export default function Test() {
return (
<SafeAreaView style={styles.container}>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some text that fits (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some text that fits (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some text that fits (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some text that fits (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Some longer text that doesn't fit if displayed in one line (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Some longer text that doesn't fit if displayed in one line (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (no adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit numberOfLines={1}>
Some longer text that doesn't fit if displayed in one line (adjust, 1 line)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, unlimited height)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2}>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (no adjust, 2 lines)
</Text>
</View>
<View style={{margin: 4, borderWidth: 1, borderColor: 'black'}}>
<Text style={{ fontSize: 16 }} numberOfLines={2} adjustsFontSizeToFit>
Even longer text that doesn't even fit if it has as much as two entire lines for itself, what a darn shame (adjust, 2 lines)
</Text>
</View>
</SafeAreaView>
);
}
```
</details>
|Old arch (without this PR)|Old arch (with this PR)|
|-|-|
|<img width="546" alt="old_no_change" src="https://github.com/facebook/react-native/assets/21055725/f9682c0c-9a23-46b3-984d-607f83811d9e">|<img width="546" alt="old_changed" src="https://github.com/facebook/react-native/assets/21055725/c07f88fb-8ca2-415e-95c9-27bf718fc510">|
|New arch (without this PR)|New arch (with this PR)|
|-|-|
|<img width="546" alt="new_no_change" src="https://github.com/facebook/react-native/assets/21055725/173ac140-a836-4a40-83ef-c5365972700f">|<img width="546" alt="new_changed" src="https://github.com/facebook/react-native/assets/21055725/b0b00e45-17d2-4756-8ae5-a21c4ec242d9">|
Reviewed By: cortinico
Differential Revision: D56356139
Pulled By: cipolleschi
fbshipit-source-id: d11a5f4b95fb7da28a24d9136d41349d39851d9e
Summary:
`_textStorageForNSAttributesString` seems to be unused and its implementation is exactly the same as `_textStorageAndLayoutManagerWithAttributesString`. This PR removes it.
## Changelog:
[IOS] [REMOVED] - Removed `_textStorageForNSAttributesString` which was unused
Pull Request resolved: https://github.com/facebook/react-native/pull/44166
Test Plan: Built RN Tester on iOS.
Reviewed By: sammy-SC, cipolleschi
Differential Revision: D56355860
Pulled By: javache
fbshipit-source-id: d9672478c1c914a468b480d9e7cbcbb0eaf8371f
Summary:
This change splits the React-Fabric podspec in two podspecs: React-Fabric and React-FabricComponents.
The reson is that we are codegenerating some of the core components and we want for the FabricComponents to depend on ReactCodegen.
Before this change, we had a circular dependency if we make ReactFabric depends on Codegen because ReactCodegen has to depend on ReactFabric.
Now, the dependency graph would be:
`React-FabricComponents --> ReactCodegen --> React-Fabric`
and no cycle is created
## Changelog
[internal] Split React-Fabric in React-Fabric and React-FabricComponents
Reviewed By: cortinico
Differential Revision: D56306355
fbshipit-source-id: 8b609d9c962913d5d730ac1c4e3614777b5953d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44109
(Following up from suggestion of prior diff)
For consistency with `OnSelectionChange` callback, rename `onPopupDismiss` to `onDismiss`.
Changelog:
[Android][Internal] - rename function
Reviewed By: RSNara
Differential Revision: D56168456
fbshipit-source-id: c4a32637951200736202f43294973d783ecf5ace
Summary:
RCTRootViewFactory is a great work for creating react binding view. we want to reuse the factory inside expo and would be good to have these improvements.
- exposing `reactHost` property so that we can update the RCTHost instance without recreate a factory.
- break bridgeless creation logic to a specific `createReactHost`, so that we can reuse the method for RCTHost creation
## Changelog:
[IOS][CHANGED] - Improve reusability for RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43528
Test Plan: this pr should not introduce any regression and getting all ci passed
Reviewed By: cortinico
Differential Revision: D56056103
Pulled By: cipolleschi
fbshipit-source-id: 9f312707b9013c36863945c9b99a697f949f10b5
Summary:
Changelog: [Internal]
## 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
Pull Request resolved: https://github.com/facebook/react-native/pull/44154
Reviewed By: cortinico
Differential Revision: D56335973
Pulled By: arushikesarwani94
fbshipit-source-id: b481b04e218f34b0760f21106e6b5b583cb7f760
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44131
Stub tree creation is using an old differentiator path we aren't shipping today. This removes that path, so that we can unit test the new one
1. Remove `ForTesting`/`Legacy` functions
3. Update stub view tree code for API/behavior difference of new differentiator functions including unflattened views. Don't create view instructions for those, and use `mountIndex` instead of pair index
4. Remove `V2` suffix, since the old path is deleted
5. Move mounting stub test utils out of the production library
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D56227426
fbshipit-source-id: 0f525097cfb576e0228c9ca20a770fa41ddf1e0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44096
These Android only APIs have been deprecated and are being removed for 0.75 release.
Changelog:
[Android][Removed] - UIManager.showPopupMenu() and UIManager.dismissPopupMenu() have been removed
Reviewed By: RSNara
Differential Revision: D56041827
fbshipit-source-id: e2afebf55860f33d2c8d1887e865adb4dd555e6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44150
Changelog: [Internal]
* Adds the `RuntimeTargetDelegate::captureStackTrace` method for capturing stack traces during JS execution. The returned stack traces are opaque to RN, but may be passed back into the `RuntimeTargetDelegate`, particularly through the `addConsoleMessage` method.
* Implements `captureStackTrace` for Hermes (based on D55757947).
* Integrates `captureStackTrace` into the `console` handler (`RuntimeTargetConsole`)
Reviewed By: hoxyq
Differential Revision: D55474512
fbshipit-source-id: 3547d756844fa24c24cd9bcdc507b33c6ab673a9
Summary:
bypass-github-export-checks
Changelog: [Internal]
Rewrites all `ConsoleApiTest` test cases to use matchers instead of a homegrown solution for buffering `EXPECT_*` calls.
Reviewed By: robhogan
Differential Revision: D55485495
fbshipit-source-id: 1aa50bbbb5a3b02280ed4a0bee59682716b4fd7e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44139
I added logic to make useEffect() work w/ fragment-based nav, but I mixed up some logic. Fixed it here
Changelog: [Internal]
Differential Revision: D56264138
fbshipit-source-id: b551f0cb93cb4a0291733edbd341d3508b61e392
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44124
This API was introduced as part of Backwards Compat effort recently but now this backwards comptability is supported through BridgelessCatalystInstance. The major OSS usages are through Catalyst Instance and not through Bridgeless React Context which is why deleting this makes sense so that people do not start depending on this.
Changelog:
[Android][Removed] - Remove getJavaScriptContextHolder() from BridgelessReactContext since now it can be accessed through BridgelessCatalystInstance in Bridgeless mode
Reviewed By: RSNara
Differential Revision: D56205699
fbshipit-source-id: 175463e17c526359c2e04fec4b2104aea3949d5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44102
Remove `getRuntimeExecutor()` from ReactContext since now it can be accessed through BridgelessCatalystInstance.getRuntimeExecutor() directly
Changelog:
[Android][Removed] - Remove getRuntimeExecutor() from ReactContext since now it can be accessed through BridgelessCatalystInstance in Bridgeless mode
Reviewed By: RSNara
Differential Revision: D56151365
fbshipit-source-id: 42bb6a6a3d729339cfb83ffdd3f7cbec314b687a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44133
# Changelog: [Internal]
Previous implementation doesn't have support for one specific case, when RN runtime was initialized and frontend is ready to be connected, but then it gets disconnected and re-connected again for the same runtime.
The issues were:
- For Fusebox: backend and frontend are correctly re-connected if user had Chrome DevTools opened, frontend invalidated via reload, then Chrome DevTools closed and re-opened again
- For DebuggingOverlayRegistry: it didn't subscribe to events from new `react-devtools-agent`, which emits events such as `showNativeHighlight` or `drawTraceUpdates`
Reviewed By: motiz88
Differential Revision: D56239185
fbshipit-source-id: ffa886b396790cb46de1d86fb000ff907edc1437
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44076
Removes fields in the root `package.json` manifest left over from the monorepo migration. `react-native/monorepo` is not a package published to npm, but is a root project configuration for the monorepo. Therefore it **doesn't need**:
- npm metadata fields (or even a `name` or `version` — I'm leaving these included due to 1/ references in fbsource, 2/ some non-Yarn tooling may complain).
- Fields used by tooling that are present in packages/react-native: `jest-junit`, `types`.
- A `peerDependency` on `react` (again, present in packages/react-native/package.json).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D56134668
fbshipit-source-id: bc3449eb4c122eb5d885fabda9af7d19bb71faff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44097
There are two places where we use a feature specific to the system version of 'cp', the:
-X Do not copy Extended Attributes (EAs) or resource forks.
This feature isn't available in GNU's cp, which is commonly installed on macOS using:
brew install coreutils && brew link coreutils
We can avoid the problem alltogether by being specific about the path of the system cp.
Changelog: [General][Fixed] don't break script phase and codegen when coreutils installed on macOS
Reviewed By: cipolleschi
Differential Revision: D56143216
fbshipit-source-id: f1c1ef9ea2f01614d6d89c4e9eedf43113deb80c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44132
Changelog: [Breaking][Android] `DevSupportManagerFactory.create()` changed to take an additional parameter of type `PausedInDebuggerOverlayManager` (nullable)
Enables integrators of React Native Android to supply their own implementation of the Fusebox "paused in debugger" overlay. This is primarily intended for legacy Meta-internal integrations that can't use the built-in implementation based on `Dialog`. **The API will likely go away once those integrations have been migrated.**
Reviewed By: javache
Differential Revision: D56215119
fbshipit-source-id: 9cd79a6948c268a952ac28e5563ae57c90756da7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44065
React Native will try to use static view config if native view config is not available.
This will allow Fabric-only native components in Bridge mode.
Changelog: [General][Added] - Add support for Fabric-only native components in Bridge mode.
Reviewed By: cortinico
Differential Revision: D56062759
fbshipit-source-id: e562700695c14c88d11056aec1e66f8aa10a3957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44081
Changelog: [Internal]
Migrates the Fusebox "pause in debugger" on Android from `AlertDialog` to a custom dialog, with a look and feel based closely on the equivalent Chrome feature. I've adapted the layout slightly to be mobile-appropriate (touch target sizes etc) and drawn new icon assets that are effectively hand-upscaled versions of the Chrome ones.
Reviewed By: hoxyq
Differential Revision: D56105051
fbshipit-source-id: 42d7472c8dd8f842c0dbd82c12eba102bcf59b87
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44082
Changelog: [Internal]
Adds the ability to interactively resume/step from the Fusebox "paused in debugger" overlay on Android. This uses HostCommands (D56098083) and extends the AlertDialog-based overlay (D56068445). In an upcoming diff on this stack, we'll update the design of the overlay to match Chrome's.
Reviewed By: hoxyq
Differential Revision: D56098084
fbshipit-source-id: 587b8bac7b0dd636363fc28ea7d0577b1a52d5c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44079
Changelog: [Internal]
Implements an unstyled, non-interactive version of the "paused in debugger" in-app overlay in Fusebox on Android, based on the event introduced in D56068444. The implementation in `DevSupportManagerBase` is shared across Bridge and Bridgeless.
In upcoming diffs in this stack, we'll add interactive features (namely "resume" and "step over" buttons, like in Chrome) and improve the visual styling of this overlay.
Reviewed By: hoxyq
Differential Revision: D56068445
fbshipit-source-id: a9ac2765d29d64615751b5cdf03939e0b84d2545
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44085
Changelog: [Internal]
Styles the Fusebox "paused in debugger" overlay on iOS to look similar to the Chrome implementation (and the Android implementation as of D56105051) instead of using a plain `UIAlertController`.
The only thing missing at this point is the custom asset for the "step over" icon. Unlike on Android, RN doesn't currently ship any built-in images for iOS, so I'll figure out how to do that in a separate diff and use a system-provided icon in the interim.
Reviewed By: hoxyq
Differential Revision: D56116881
fbshipit-source-id: a07e1a7592c4210606a0e61366ad750faf6148bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44083
Changelog: [Internal]
Adds a working, interactive "paused in debugger" overlay to Fusebox for iOS (similar to what D56068445 + D56098084 did on Android). The overlay is rendered using a standard `UIAlertController`. In upcoming diffs on this stack we'll style the overlay to look more like the Chrome implementation.
Reviewed By: hoxyq
Differential Revision: D56105959
fbshipit-source-id: d752d6611b2d9e48b67a82f3a9a96c7785c31a7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44114
In OSS, we should use the ClassFinder wrapper as the `Class.byName` calls will never succeed (we don't run the annotation processor in OSS).
Changelog:
[Internal] [Changed] - Use ClassFinder inside ViewManagerPropertyUpdater
Reviewed By: arushikesarwani94
Differential Revision: D56191175
fbshipit-source-id: a67195e983774872e27d35456b45651540411e2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44128
Changelog: [Internal]
idk what happened but this link got abbreviated when i copypastad it, fixing it here
Reviewed By: javache
Differential Revision: D56228228
fbshipit-source-id: 35c5c9fb44e82083773302618474c1e3bbc71712
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44080
## Design
Adds a new public `HostTarget::sendCommand` method, enabling integrators to send simple imperative commands to the target.
As an implementation detail, the commands are translated internally to CDP and sent over a dedicated `HostTargetSession` (encapsulated in `HostCommandSender`). Any response from the underlying Agent is ignored.
From the caller's perspective, these commands don't occur in the context of a session at all, and from the frontend's perspective, only the *effects* of the commands (if any) are seen.
## Use case
HostCommands are specifically useful when we want to resume/step execution in response to a UI action. The commands map directly to the `Debugger.resume` and `Debugger.stepOver` CDP methods.
NOTE: This is inspired by Chrome/V8's existing support for multiple concurrent CDP sessions. Any CDP client can successfully send `Debugger.resume` and `Debugger.stepOver` (without even subscribing to debugger events using `Debugger.enable`) and affect the state of other ongoing debugging sessions.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D56098083
fbshipit-source-id: 013ab748b360f700c453cf1447fb82d6d0d77c6f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44105
Previously, we skipped calling the ReactDelegate callback functions when the ReavtNavigationFragment was destroyed because it set the current activity to null when we need to actually keep the reference to the activity. However, skipping this entirely also skips core clean up logic, such as running the return() function for useEffect().
Instead of skipping the callback function entirely, we just need to make sure we don't set mCurrentActivity to null. I followed D30504616 to configure an option to not set mCurrentActivity to null if mKeepActivity flag is set on the ReactInstanceManager.
Changelog: [Internal]
Reviewed By: keoskate
Differential Revision: D56167533
fbshipit-source-id: cb3620e21599683e0c6bbc5a6a9c4f384fdbcc51
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44104
We previously added the option to skip calling the delegate lifecycle events in D55646221 to support fragment-based navigation. However, we don't actually want to skip calling these events as they run some core clean up logic, such as calling the return value of useEffect(). There's a better way to get this working with fragment-based nav (see next diff).
Changelog:
[Internal] [Changed] - Remove option to skip calling delegate on ReactFragment lifecycle events
Reviewed By: keoskate, cortinico
Differential Revision: D56167614
fbshipit-source-id: 3a4b91a303a27c0e19644a4e6611229211a1e530
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44120
changelog: [internal]
Prevent measuring the same text twice in `ParagraphShadowNode`.
The current implementation calls `TextLayoutManager::measure` twice for a single `ParagraphShadowNode`. The first time to measure the node for Yoga. The second time inside `ParagraphShadowNode::layout`. I think the original author counted on the cache inside of `TextLayoutManager` to deal with this, but this is not always the case and `TextLayoutManager::measure` is called with two different available widths, leading to cache miss and fills the cache faster.
Reviewed By: NickGerleman
Differential Revision: D55757264
fbshipit-source-id: 0bf8b49f062f802a4e2f04cad1bf1d4bf001b870
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44094
# Changelog: [Internal]
This script was added in D54770207.
This will be DEV-only for 2 reasons:
1. We need to double-check if Fusebox is ready to be used with production bundles, I don't think so.
2. Previous integration with RDT was DEV-only
Reviewed By: motiz88
Differential Revision: D56141041
fbshipit-source-id: 1141c65a5811d0f56c944e25a319ba21211b7836
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44088
This is a power user option for Release Crew members when testing locally — a flag to bypass being blocked on the latest in-progress CircleCI job and instead fetch build artifacts from the most recent successful pipeline (typically `HEAD~1`).
Example use cases where the latest pushed commit isn't impactful:
- An iOS-only fix, meaning Android can be tested now.
- A trivial fix that applies to CI only (e.g. RNTester Podfile.lock update).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D56138727
fbshipit-source-id: f9884bdb289a92486807e8e033b756466fcec559
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44116
This is just the bridgeless analogue to .hasCatalystInstance()
Changelog: [Android][Added] - Introduced ReactContext.hasReactInstance() to replace .hasCatalystInstance()
Reviewed By: fabriziocucci
Differential Revision: D56164488
fbshipit-source-id: 8be4676e18dc7df4765746f46cf36e62405b4ffa
Summary:
As part of decoupling our dependency on the react-native-community/cli, the `react-native.config.js` which is
a part of the community's config ecosystem should probably be entirely removed from the react-native package.
As part of this, we're making the config fail gracefully if these dependencies aren't available in a user's project:
- react-native-community/cli-platform-android
- react-native-community/cli-platform-ios
Changelog: [Internal]
This isn't going to be a visible change to any users.
bypass-github-export-checks
Reviewed By: cortinico
Differential Revision: D56137820
fbshipit-source-id: 528e25809a83b90e79b806a875001fc0f06db1cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44078
Changelog: [Internal]
Adds stub support for the [`Overlay.setPausedInDebuggerMessage`](https://cdpstatus.reactnative.dev/devtools-protocol/tot/Overlay#method-setPausedInDebuggerMessage) CDP method to `HostAgent` in the Fusebox backend, and propagates it into the Android and iOS integrations through `HostTargetDelegate`.
We take care to call `HostTargetDelegate::onSetPausedInDebuggerMessage()` a final time with a null `message` parameter, regardless of whether the client has actually sent the corresponding CDP message. Since multiple clients might be connected concurrently, we only send the `null` message when the *last* client which has requested a non-null message has disconnected.
Reviewed By: robhogan
Differential Revision: D56068444
fbshipit-source-id: c26e1cf17dec8d7dbb7edd5ab7fa3133642628ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44092
In a setup where a device retrieves a bundle from `http://127.0.0.1:8081`, but this is tunnelled to a remote host with only an IPv6 stack (eg, FB dev servers), the host running the inspector-proxy will fail to fetch source or source maps from 127.0.0.1 despite typically being on the same host (indeed, process) as Metro.
This causes a surprising inconsistency where using a bundler URL of `localhost` from the device results in source maps being inlined into `Debugger.scriptParsed`, but using a bundler URL of `127.0.0.1` causes inspector-proxy to fall back to preserving URLs, which are typically fetched lazily by CDT later.
This should be unnecessary once we've implemented CDP `Network.loadNetworkResource` and removed `Debugger.scriptParsed` rewriting, but for now it brings IPv6 tunnelled servers in line with local servers.
Changelog:
[General][Changed] Inspector proxy: Rewrite 127.0.0.1 to localhost in source map URLs for better IPv4->IPv6 tunnelling support.
Reviewed By: motiz88
Differential Revision: D56138742
fbshipit-source-id: b65c9cc8225a0ed54cf32171f640ef9e6408c762
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44103
Changes here fixes events in PopupMenuAndroid not being triggered correctly.
Issuses were:
1) naming mismatch
2) wrong parameters were set for the Event Map
3) missing code in .cpp
Applied fixes:
1) consistent event naming
2) fixed key used for event mapping
3) re-ran codegen to update .cpp files
## Changelog:
[Android] [internal] - Fix issue with PopupMenuAndroid event callback not working
Steps took to run codegen for this diff: https://www.internalfb.com/intern/phabricator/paste/markdown/P1214671854/
This diff is patching issues from D55531870
Reviewed By: RSNara
Differential Revision: D56164235
fbshipit-source-id: 4cf66ad3cfd753c146c5e219f27910834731e183
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44098
This sets `QualiferAlignment` so that code is automatically formatted to west const.
I did a pass at this before, but now that we are on new Clang Format, we can enforce it automatically, and I think a couple more cases not previously changed now are.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D56143678
fbshipit-source-id: 8f12b288476ea6019fd7d7a93a39b4fe2e75af14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44089
While doing the release of 0.74.0-RC.9, we encountered some failures while building because the committed project had some new flags that have been added by cocoapods and that required Ccache.
However, Ccache is not a hard requirement to run React Native and the build started failing on systems that does not have ccache installed.
That happened because we were missing the piece of code that removed Ccache from the project in case the tool is not installed in the system.
We already committed such commit in the stable branch of 0.74, with [this commit](https://github.com/facebook/react-native/commit/2b18fdf8063b423a0fb5762f2c6044244b4c35e6). This change will port the same fix in main.
## Changelog
[iOS][Fixed] - Make sure to remove ccache scripts when ccache is not installed
Reviewed By: cortinico
Differential Revision: D56140015
fbshipit-source-id: 24e7ebb4e5c08766b29705e8b6f03c3f164a96ab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44086
When a debugger frontend is connected to inspector-proxy via another proxy or tunnel that times out on idle (such as [VS Code's remote tunnel](https://github.com/microsoft/vscode/blob/main/src/vs/platform/tunnel/node/tunnelService.ts)), the connection between proxy and debugger may be dropped.
In addition, when the connection is dropped without a closing handshake, the proxy does *not* detect the disconnection - no disconnect is logged to the reporter and no notifications are sent to any connected devices.
This adds a mechanism using the WebSocket-standard `ping` and `pong` frames to:
1. Keep the connection alive
2. Detect when the debugger has gone away
Note that as all WebSocket clients already **must** reply to a ping with a pong, this is non-breaking for compliant implementations: https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.2
Changelog:
[General][Added] Inspector proxy: Add ping/pong keepalive to debugger connections.
Reviewed By: hoxyq
Differential Revision: D56069185
fbshipit-source-id: e322de631c652a502f3d554c15ed5412a751ee04
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44087
The `mFabricEnabled` field is initialized to false. This is a misalignment with how other classes are behaving like
ReactActivityDelegate.
Changelog:
[Internal] [Changed] - ReactFeatureFlags.mFabricEnabled should default to ReactFeatureFlags.enableFabricRenderer
Reviewed By: arushikesarwani94
Differential Revision: D56013057
fbshipit-source-id: fcab903ab42d3b30094dcebbcf5b662cd2f2c506
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44040
This is just a clarification for the KDoc of this property.
Changelog:
[Internal] [Changed] - Clarify documentation for debuggableVariants
Reviewed By: andrewdacenko
Differential Revision: D56012825
fbshipit-source-id: 837d2dbc0f7ca5853ba1cedf71a4a5c36661318f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43722
This change adds a drawable, when when drawn on the bounds of a border-box sized view, will draw a spec compliant box-shadow outside the box. This is reliant on Android `RenderNode` and `RenderEffect` APIs provided by API 31.
Inset box shadows can also be added using a similar method, but this is not done yet.
The code which manages this is in flux, but the underlying drawable should be good. Will add some tests once it's more wired up.
Changelog: [Internal]
Reviewed By: javache, cortinico
Differential Revision: D55561465
fbshipit-source-id: 6180568cff2779b826e73bb9184dbe042863b262
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43983
We duplicate some pretty hairy code related to conversion between logical and physical edges, along with the grafting between uniform and non uniform radii. This encapsulates border radius resolution/assignment logic.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D55635743
fbshipit-source-id: 906c35af2bf18f0586d71d05f9cf61d4248ede1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43721
Makes some changes to `FilterHelper` to expose RenderEffects for filters publicly to other classes in the module. We use this in box-shadow, in order to reuse logic for sigma accepting blur filters.
Also fixes a crash related to the conversions back and forward between sigma and radius, where small values would cause a crash.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55563775
fbshipit-source-id: fabc888eecb451e75a88c8633fe5cca1f6644faa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43720
This lets us use BG drawing code in rules which view depends on. I also removed some lib usage.
The original class is still present, subclassing the class in its new location, but is marked deprecated.
Next diffs in stack clean up some of our own now deprecated usage.
Changelog:
[Android][Breaking] - Deprecate `ReactViewBackgroundDrawable` in favor of `CSSBackgroundDrawable`
Reviewed By: javache
Differential Revision: D55565035
fbshipit-source-id: 501b3e2f674c09a88b1825657ba6349823054e8c
Summary:
After a [recent change](https://github.com/facebook/react-native/commit/90296be1d4fab09a52e02dd09f34f819136d0a07) we break part of the integration with the debug menu, which is was using the presence/absence of the bridge to decide whether we were in bridge or bridgeless.
For backward compatibility reasosn, the bridge ivar is now populated with the bridgeProxy, so just checking whether is nil or not is not enough to verify whether we are in bridge or in bridgeless mode anymore.
## Changelog:
[iOS][Fixed] - Make sure that the Open Debugger appears in bridgeless mode
Reviewed By: fkgozali
Differential Revision: D56067897
fbshipit-source-id: e2501ed730ff35bc755c24ef400130c551032e28
Summary:
We would set the value of _bridge ivar to bridgeProxy for turbo module in bridgeless mode in https://github.com/facebook/react-native/issues/43757 , so we need to change the way of bridgeless/bridge check.
## Changelog:
[IOS] [FIXED] - Change bridgeless check in dev menu
Pull Request resolved: https://github.com/facebook/react-native/pull/43976
Test Plan: Dev menu shows bridgeless/bridge mode correctly.
Reviewed By: christophpurrer
Differential Revision: D56056640
Pulled By: cipolleschi
fbshipit-source-id: 1358c3027c1d5f12c70dd4486cc1d5975c7a185a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44056
## Changelog:
[Internal] -
Was looking into how devsupport is exactly implemented on different platforms (in the context of doing it for a new platform) and figured I may just well convert this to Koltin in the process (helped to understand inner working details as well).
Reviewed By: christophpurrer
Differential Revision: D56058560
fbshipit-source-id: 1e2ffcec480c5fa3fd8b6494c29a0db6f94aec78
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44055
## Changelog:
[Internal] -
Was looking into how devsupport is exactly implemented on different platforms (in the context of doing it for a new platform) and figured I may just well convert this to Koltin in the process (helped to understand inner working details as well).
Reviewed By: christophpurrer
Differential Revision: D56052137
fbshipit-source-id: 25280a57f46bec95dc1437ea6eb2eef08332797f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44058
## Changelog:
[Internal] -
This was revealed when running an ASAN build on MacOS - we were doing an unsafe downcast from `LayoutableShadowNode->ViewShadowNode` inside `ShadowTree::emitLayoutEvents`.
Which, even though incidentally worked, is generally unsafe, as we may get e.g. `ImageShadowNode` there, which doesn't inherit from `ViewShadowNode`.
That downcast to `ViewShadowNode` wasn't even required, to begin with, as all the needed information can be already extracted from the `LayoutableShadowNode` itself.
Reviewed By: christophpurrer, javache
Differential Revision: D56062334
fbshipit-source-id: 08d5b3f5e0c57dc51b051d23506c7933581fea29
Summary:
The goal of this PR is to allow the usage of `RCTRootViewFactory` from Swift. The issue with `RCTTurboModuleManager.h` is that it uses C++ in its header file, which is not allowed in Swift, making this initializer unavailable.
This PR allows users to just pass configuration + adds a nullable annotation to bundleURL.
Example usage:
```swift
import Foundation
import UIKit
import React
import React_RCTAppDelegate
main
class AppDelegate: NSObject, UIApplicationDelegate {
var window: UIWindow?
private var rootViewFactory: RCTRootViewFactory?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
) -> Bool {
// Create config
let config = RCTRootViewFactoryConfiguration(
bundleURL: self.bundleURL(),
newArchEnabled: true,
turboModuleEnabled: true,
bridgelessEnabled: false
)
// Create rootview factory
rootViewFactory = RCTRootViewFactory(configuration: config)
// Create rootview
let rootView = rootViewFactory?.view(withModuleName: "RN0740RC4")
let rootViewController = UIViewController()
rootViewController.view = rootView
// Create window and assign view controller
window = UIWindow(frame: UIScreen.main.bounds)
window?.rootViewController = rootViewController;
window?.makeKeyAndVisible()
return true
}
func bundleURL() -> URL? {
RCTBundleURLProvider.sharedSettings().jsBundleURL(forBundleRoot: "index")
}
}
```
## Changelog:
[IOS] [FIXED] - Allow usage of `RCTRootViewFactory` from Swift
Pull Request resolved: https://github.com/facebook/react-native/pull/43590
Test Plan: CI Green, check usage of initializer without turbo module delegate
Reviewed By: christophpurrer
Differential Revision: D56055938
Pulled By: cipolleschi
fbshipit-source-id: c80d9f7f707c376f590f3dc4c9bb8f88f2e57e6a
Summary:
Changelog: [Internal]
With the Hermes fix in D55250610, we're able to make stronger assertions in `CDPAgentReentrancyRegressionTest`, which is an integration test covering a class of related bugs.
bypass-github-export-checks
Reviewed By: mattbfb
Differential Revision: D55962593
fbshipit-source-id: 09d03effc51d6f1904842f1c7c2f7e4407fefc63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44022
changelog: [internal]
move the new state reconciliation algorithm to the unified feature flag system.
Reviewed By: rubennorte
Differential Revision: D55965530
fbshipit-source-id: 3edde0858a670e86dc2d1cb561f03f584ff21896
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44021
changelog: [internal]
This is an evolution of cloneless state progression, introduced in D49012353.
# Problem
## When React clones the wrong node revision
Whenever React wants to commit a new change, it first needs to clone shadow nodes. React sometimes clones from the wrong revision. This has mostly been fine, Fabric does state reconciliation to pass newest state forward. State reconciliation is needed, as we need to keep native state in the shadow tree.
However, when React clones a node that has never been through layout step, it will clone a node without any layout information and its yoga node is dirtied. Even though there might be a subsequent revision of the node with layout information already calculated. As a result, Yoga needs to traverse bigger parts of the tree, even though layout has been calculated before. It is just cached on a different revision that was used as a source.
There are two main sources (there is more but they don't help to paint the picture) when this can happen. Background Executor and State Progression. Let's start with the simpler one but less severe: Background Executor.
Background Executor moves layout from JavaScript thread. React can start cloning nodes right away, even though they might not have layout information calculated yet. This is a race condition and depending on when the node is cloned, we can see different results. In this case, React eventually clones node from the correct revision with the layout cache. It will be in a correct state in the end. This case is not as bad as far as I can tell but I included it here because it better illustrates what is going on.
State Progression is where things get worse. In this scenario, React will never clone from the correct revision and will never recover from this. Anytime React clones node with a state that needs to be progressed, it will get cloned one more time during commit but React will hold the wrong revision. Depending on where this node is located in the view hierarchy, it may lead to expensive layout calculations.
Example:
Let's use notation A/r1 as node of family A revision 1.
- React calls create node. Node A/r1 is created and React holds reference to this. It will later use it to clone it.
Node A has native state that was updated. New revision A/r2 is created. Now React and RN do not observe the same node anymore (this is sometimes necessary).
- React now clones node A to create A/r3. This revision may have the wrong yoga cache. Now this might sound like one off but let's explore what happens next.
- During commit, Fabric must do state progression to give node A/r3 state from A/r2. This requires cloning and new revision A/r4 is created. React has again a wrong node that does not have Yoga cache and can't recover from this state.
The blast radius of this varies depending on where in the tree the node is.
# Solution - State Alignment Mechanism
The main principle for new state progression is to make sure React references the correct shadow node after commit to avoid layout cache miss on subsequent commit.
Agenda for the diagrams below:
- Black colour: node was not cloned.
- Blue colour: node was cloned by React.
- Orange colour: node was cloned by host platform.
- Blue and Orange colour: node was cloned by both React and host platform.
## Simple cases
### Base case
{F1483309510}
### React Cloned
{F1483308354}
### React and host platform clone the same node
{F1483309324}
## Medium difficulty
### React clones a different branch than host platform
{F1483349393}
### React deletes a branch that was cloned by host platform
{F1483349259}
### React changes structure of the tree, node cloned by host platform remains
{F1483349758}
### React reorders nodes that were cloned by host platform
{F1483350283}
Reviewed By: rubennorte
Differential Revision: D53405702
fbshipit-source-id: c7d4b0772c144c86d72e39965e9626a2daefa6fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44020
changelog: [internal]
This diff only adds more tests for state reconciliation to cover more cases.
Thanks to this, I discovered bugs in my previous implementation of cloneless state progression.
Reviewed By: rubennorte
Differential Revision: D55926491
fbshipit-source-id: 5945ba9bc1d6fed111fbca07e19589cbef50712d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44019
changelog: [internal]
use size_t instead of int32_t so that caller of `ShadowNode::replaceChild` does not need to cast.
Reviewed By: rubennorte
Differential Revision: D55923333
fbshipit-source-id: 8f8062708d9aaddedb600aa7dac419a177e2ab24
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44018
changelog: [internal]
New trait ClonedByNativeStateUpdate is used to mark the path that was cloned by native state update.
This is a pre-requisite for new state reconciliation algorithm. It will mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55922776
fbshipit-source-id: 6d4515460346c341af3ee6117d570b3201328bc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44017
changelog: [internal]
Add an option to mark all nodes clone indirectly by `ShadowNode::cloneTree`.
This is a pre-requisite for new state reconciliation algorithm. It will be used to mark part of shadow tree that was affected by native state update.
Reviewed By: rubennorte
Differential Revision: D55745323
fbshipit-source-id: 5e2a2e8a572cc5077d907608f83992a43625d58e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44016
changelog: [internal]
Add option to set traits when node is created or cloned via ShadowNodeFragment.
This is a pre-requisite for new state reconciliation algorithm.
Reviewed By: rubennorte
Differential Revision: D55691094
fbshipit-source-id: 0bdf024c3c9b28304969ddc9b9c63b0f0b924bb0
Summary:
IOS builds started failing due to Xcode version checks falsely claiming newer versions are not installed
TODO affecting Xcode version checking reads: Remove this code after April 2024, when Apple will push the lower version of Xcode required to upload apps to the Store.
## Changelog:
remove deprecated Xcode version check
Pick one each for the category and type tags:
[IOS] [REMOVED] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/43949
Test Plan: Should run as before, only the deprecated version check has been removed.
Reviewed By: dmytrorykun
Differential Revision: D56056701
Pulled By: cipolleschi
fbshipit-source-id: 47288e04bd1cfc989cf05994cb47421fd2379af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44026
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Yet another attempt to land this (last one was D55505416).
Copy-pasting below the amazing summary from RSNara.
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
NOTE: Intentionally not converting `BridgeReactContext` to Kotlin to minimize the risk of these changes.
Reviewed By: RSNara
Differential Revision: D55964787
fbshipit-source-id: b404efe0c7095894fa815165cc8682f78dccfa17
Summary:
X-link: https://github.com/facebook/react-fbsource-import/pull/5
Pull Request resolved: https://github.com/facebook/react-native/pull/44046
changelog: [internal]
`passthroughAnimatedPropExplicitValues` from sticky header were removed in D46703731 with assumption that native animations trigger on complete callback and it can be used as a synchronisation point for Fabric.
On complete callback is triggered for native animations do trigger on complete callback with one exception: when the native animation is driven by scroll view's content offset.
As a result, synchronisation between React and Fabric doesn't happen and Pressability stops working if there is a pressable element in the sticky header.
Reviewed By: rubennorte
Differential Revision: D56005408
fbshipit-source-id: daead3a566e157593aa3f1b3ae3553ec1094b6da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43418
Changelog: [Internal]
This diff adds a script, which will be later imported from `InitializeCore` to setup a required global for communication between React Native runtime (RDT Backend in it) and Chrome DevTools Frontend (RDT Frontend in it).
See README for the architecture overview and how bidirectional communication is established.
Corresponding PR in Chrome DevTools frontend - https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/15
Reviewed By: motiz88
Differential Revision: D54770207
fbshipit-source-id: 0f0f04a338b5c7eab817c843a99b07cca95e57fd
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js` I'll find that `TouchableHighlight` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/44d59ea6f9a1705487314e33de52f7056651ba25/packages/react-native/Libraries/Components/Touchable/TouchableHighlight.js#L382-L391
So the TS type isn't correct : (
```tsx
<TouchableHighlight ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableHighlight`)
```
---
**Breaking changes**
As `TouchableHighlight` isn't class anymore it can't be used as value & type
```tsx
import {TouchableHighlight} from 'react-native';
const ref = useRef<TouchableHighlight>();
// ^^^ TS2749: TouchableHighlight refers to a value, but is being used as a type here.
// Did you mean typeof TouchableHighlight?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<React.ElementRef<typeof TouchableHighlight>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableHighlight>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform TouchableHighlight from JS class to ForwardRef component
Pull Request resolved: https://github.com/facebook/react-native/pull/44038
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56015309
Pulled By: dmytrorykun
fbshipit-source-id: fee346536787a5921626ed69a4c01da2b599dc2f
Summary:
If you check the source of truth `packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js` I'll find that `TouchableOpacity` is a result of `React.forwardRef(...)` :
https://github.com/facebook/react-native/blob/f7eaf63881b23216c06ab3c81ea94d0312cd6a7b/packages/react-native/Libraries/Components/Touchable/TouchableOpacity.js#L326-L335
So the TS type isn't correct : (
```tsx
<TouchableOpacity ref={ref => { }} />
// ^^^ ref should be a `View` (but now it's `TouchableOpacity`)
```
---
**Breaking changes**
As `TouchableOpacity` isn't class anymore it can't be used as value & type
```tsx
import {TouchableOpacity} from 'react-native';
const ref = useRef<TouchableOpacity>();
// ^^^ TS2749: TouchableOpacity refers to a value, but is being used as a type here.
// Did you mean typeof TouchableOpacity?
```
**Recommend solution:** use build-in react type `React.ElementRef`
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<React.ElementRef<typeof TouchableOpacity>>();
```
Also, it possible to use `View` as type:
```diff
-const ref = useRef<TouchableOpacity>();
+const ref = useRef<View>();
```
## Changelog:
[GENERAL] [BREAKING] - [Typescript] Transform `TouchableOpacity` from JS `class` to `ForwardRef` component
Pull Request resolved: https://github.com/facebook/react-native/pull/44030
Test Plan: See: `packages/react-native/types/__typetests__/index.tsx`
Reviewed By: NickGerleman
Differential Revision: D56017133
Pulled By: dmytrorykun
fbshipit-source-id: 58f4c1a14c9b3bd2407ea6c825a90b355acb16bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44005
When using frameworks on iOS, there is a possibility that modules import the Spec.h file twice and this might end up in a Redefinition of some symbols and duplication of symbols which ends up in build errors, as reported here: https://github.com/facebook/react-native/issues/42670.
This change adds some [`#include guards`](https://en.wikipedia.org/wiki/Include_guard) in codegen to avoid the redefinition of those symbols if the header is imported/included multiple times.
Note: I also experimented with `#pragma once`, but it looks like Apple is not happy with that directive. [It seems](https://forums.developer.apple.com/forums/thread/739964) that it started working flakely from Xcode 15.
## Changelog:
[General][Fixed] - Make sure that we can't include Codegen symbols multiple times
Reviewed By: cortinico
Differential Revision: D55925605
fbshipit-source-id: 15ca076aace2ffbd03ab8fa8a68a3d8ce0d1ea65
Summary:
this PR cleans up an outdated compatibility function in AndroidExecutors. the function in question was checking whether the code was running on Gingerbread or later - this is no longer needed, as RN requires Marshmallow or later.
## Changelog:
[INTERNAL] [FIXED] - Clean up outdated compatibility function
Pull Request resolved: https://github.com/facebook/react-native/pull/43958
Test Plan: this should work as normal.
Reviewed By: cortinico
Differential Revision: D55877661
Pulled By: dmytrorykun
fbshipit-source-id: 02eac50b0898d683f6abf731bf8e438ae4219a41
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43979
changelog: [internal]
using `availableSize` instead of `measurement` to avoid dependency on calling `textLayoutManager_->measure` before dispatching `onTextLayout` event.
This is important in subsequent optimisation.
Reviewed By: javache
Differential Revision: D55796594
fbshipit-source-id: 06b516e2afaf668c6359ad86b570229824933bae
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/44008
Reviewed By: christophpurrer
Differential Revision: D56017161
Pulled By: dmytrorykun
fbshipit-source-id: 512c576a055a17b37a1f9fd5e328a1ff5165b398
Summary:
Using version information previously housed in react-native-communtiy/cli
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55960009
fbshipit-source-id: 38f8b2310942a9337a7b64b51a87ae629d9bbbaf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44039
Changelog: [Internal]
Get label color from theme to fix dark mode.
Reviewed By: NickGerleman
Differential Revision: D56011777
fbshipit-source-id: 3ef14d6437c51118f0c0db3950b24f7e71d33fb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43914
changelog: [internal]
This QE with caching text measurement and NSTextStorage did not deliver the desired results. Let's remove the code to simplify the text measure infra.
Reviewed By: javache
Differential Revision: D55753670
fbshipit-source-id: b194c4ca1eded70b0d00da748716628c264a47b9
Summary:
Capturing the correct attribution in the licenses as well as adding some documentation.
I think the code will have changed significantly enough across the files that once we change to flow, we can drop the attribution in the files but leave the mention in the README.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55752899
fbshipit-source-id: b436d745d5ad439661d2af840b2cc8df4bff0038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44041
changelog: [internal]
Building rn-tester left artifacts that would be picked up by mercurial.
```
❯ hg s
? rn-tester.xcodeproj.local/Project Settings.plist
? rn-tester.xcodeproj.local/Project Settings.plist.lock
```
To mitigate this, add `rn-tester.xcodeproj.local` introduce .gitignore for rn-tester.
Reviewed By: fabriziocucci
Differential Revision: D56006193
fbshipit-source-id: 5701f1adf395e98f84ca59574dbd8747cf7e85db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44010
X-link: https://github.com/facebook/yoga/pull/1641
Yoga has quirk where newly constructed nodes are clean, which isn't really correct. Normally never shows in in real code because setting a style or children will dirty. Fabric doesn't use the public APIs that do this dirtying, so it ends up getting creative instead.
We should fix so that newly constructed nodes are dirty. Copy-constructed Nodes (also only a Fabric thing, will retain original dirty flag.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55855328
fbshipit-source-id: be49efaf8ac29351f8e5ec509bd9912546944332
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44028
Changelog: [Internal]
While testing something completely unrelated (i.e. D55964787), I've noticed that [test_android](https://github.com/facebook/react-native/actions/runs/8635097933/job/23673157303?pr=44026) actually failed on Github with this error:
> Task :packages:react-native:ReactAndroid:compileDebugUnitTestKotlin
e: file:///__w/react-native/react-native/packages/react-native/ReactAndroid/src/test/java/com/facebook/react/views/image/ReactImagePropertyTest.kt:62:38 Smart cast to 'CatalystInstance' is impossible, because 'catalystInstanceMock' is a mutable property that could have been changed by this time
Reviewed By: RSNara
Differential Revision: D55982797
fbshipit-source-id: a49e766ae95e22603293326da93007d78250da6a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43998
Another library with an empty JNI_OnLoad method.
Moving it to `INTERFACE` so it exposes only the Header it has declared.
This removes the `libreactperfloggerjni.so` from the final APK.
Changelog:
[Internal] [Changed] - Move reactperfloggerjni to INTERFACE library
Reviewed By: javache
Differential Revision: D55919228
fbshipit-source-id: 634f4f6013825b0de8827b3143a012e6c880509d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44015
Changelog: [internal]
## Context
When we introduced synchronous state updates in Fabric, we saw some crashes on coming from the mounting layer on Android.
It seems some of these crashes are caused by nested mount operations. When we're mounting some views, like [scroll views](https://github.com/facebook/react-native/blob/881c0bc8970b9e402df6b4f87e1759b238b24735/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactHorizontalScrollView.java#L383), we dispatch state updates that end up doing more mutations. When we were doing these state updates asynchronously, all the original mutations were processed before these updates, but now that we do them synchronously, the mutations are interleaved causing errors.
## Changes
This introduces a new flag that will force all the mutations going through `MountItemExecutor` in `FabricUIManager` to be batched instead of executed synchronously. This fixes the issues I saw locally and I'm expecting this will unblock synchronous state updates in production.
Potentially, this might fix other crashes we've been seeing with a low frequency.
Reviewed By: sammy-SC
Differential Revision: D55942125
fbshipit-source-id: b8d9c145ec307de7318dbbed14880bc9a84fdb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43992
# Changelog:
[Internal] -
While looking into implementing native DevLoadingView on non-Android/iOS platform, I realized that the current code inside `LoadingView.android.js`/`LoadingView.ios.js` is functionally identical, and can be transformed into each other with simple code transformations.
This diff:
* Renames `LoadingView` into `DevLoadingView` (as it's arguably more fitting name, given that it also relies on `NativeDevLoadingView` native module implementation)
* Merges the iOS/Android specific JS files into one
* Factors usage of the colors out of the actual logic, to better separate presentation from the business logic
From the perspective of public APIs there should be no changes.
Reviewed By: christophpurrer
Differential Revision: D55914787
fbshipit-source-id: 656311db80e5ee03f60ee7ffcf5f405ca99a9ce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43068
This diff adds `react-native-test-library` package.
It contains native module and native component example, and targets both the new and the old architecture. It has structure similar to many OSS React Native libraries, and is supposed to be used to test the integration with third-party libraries.
It is integrated with RNTester as the **OSS Library Example** screen.
{F1457510909}
**Change Background** tests native commands.
**Set Opacity** tests native props.
**Get Random Number** tests native module.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D50793835
fbshipit-source-id: ff6daefab10e6e9f13049e3013f8f63cfa8a929e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43995
With a previous change, we started taking snapshots of the Modal every time a Fabric mounting event was happening. this might cause perf regression when a modal is presented, and there is no need to take a snapshot that often.
This change moves the snapshotting code right before the dismissal of the Modal.
## Changelog
[iOS][Changed] - Move the snapshotting code before the dismissal.
## Facebook
This should fix T179288585, T184520225
Differential Revision: D55914776
fbshipit-source-id: 6679babf7f72aef7254113497116d5482640e789
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43999
Currently NewArch-BridgeMode is partially broken when creating views via `ReactDelegate`.
That's because we're using the ctor that doesn't account for `Boolean: fabricEnabled`.
That means that the `RootView` that it will be created are all having setIsFabric(FALSE).
This is causing problems like whitescreens on several reload + multiple warnings such as:
```
E com.facebook.react.bridge.ReactNoCrashSoftException: Cannot get UIManager because the context doesn't contain an active CatalystInstance.
```
Fixes#43692
See for more context on this issues: https://github.com/facebook/react-native/issues/43692
Changelog:
[Android] [Fixed] - Fix bridge mode by constructing ReactDelegate correctly
Reviewed By: cipolleschi
Differential Revision: D55921078
fbshipit-source-id: 2c21d089a49538402d546177bcdb26c8d7d5fbc1
Summary:
This current consists of a bunch of TypeScript code, which will be ported to Flow in the stack.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D55741526
fbshipit-source-id: 1dc30d2ab63e0526dd6fed17ccf7cce9f57bdbee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43994
We received [this issue](https://github.com/facebook/react-native/issues/43764) from OSS where an app can't connect to Metro on reloads in the following scenario:
* Start the App when metro does not run.
* Observe the error screen
* Start Metro
* Press Reload
* Observe the error message again
While the desired behavior should be to connect to Metro now that this is running.
The root cause of the problem is that the RCTHost is initialized with a value of the `bundleURL` that is `nil`. Upon reload, the RCTHost is **not** recreated: the instance is restarted, but with the previous `bundleURL`, which is still `nil`.
The solution is to initialize the `RCTHost` with a closure that re-evaluate the `bundleURL` whenever it is invoked and to evaluate it only on `start`, to keep the initialization path light.
This way, when the app is started with Metro not running, the `bundleURL` is `nil`. But when it is reloaded with Metro starting, the `bundleURL` is properly initialized.
Note that the changes in this diff are not breaking as I reimplemented (and deprecated) the old initializer so that they should work in the same way.
## Changelog:
[iOS][Fixed] - Let RCTHost be initialized with a function to provide the `bundleURL` so that it can connect to metro on Reload when the url changes.
Reviewed By: dmytrorykun
Differential Revision: D55916135
fbshipit-source-id: 6927b2154870245f28f42d26bd0209b28c9518f2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43963
changelog: [internal]
This experiment did work out. Let's clean it up
Reviewed By: cortinico
Differential Revision: D55797519
fbshipit-source-id: a5da97a7d31b9395b25bfd37db567054721599b0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43971
It turns out that we forgot to add a listener for the orientation change event in Bridgeless.
We used to have `UIApplicationDidChangeStatusBarOrientationNotification` but this is slightly unreliable because there might be use cases where the status bar has been hidden and, therefore, the event is not triggered.
This should fix an issue reported by OSS.
## Changelog:
[iOS][Fixed] - Make sure that the New Architecture listens to orientation change events.
Reviewed By: cortinico
Differential Revision: D55871599
fbshipit-source-id: c9b0634ec2126aa7a6488c2c56c87a9610fa1adf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43852
Changelog: [internal]
Just a small refactor so we rely less on shared pointers within `RuntimeSCheduler_Modern`.
Reviewed By: javache
Differential Revision: D55646389
fbshipit-source-id: d01dcba7b1551d349d21717ba585828ed7fb3259
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43853
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the logic to report the timing of events to a separate class (outside `PerformanceEntryReporter` that now is agnostic to the rendering infra).
Reviewed By: sammy-SC
Differential Revision: D55646392
fbshipit-source-id: 5032a36b23d0741b19fb74cb04f0af3d3d476ef0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43854
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This moves the `PerformanceEntryReporter` and related classes to their own target in `ReactCommon/react/performance/timeline` that's not coupled with any rendering logic.
Reviewed By: sammy-SC
Differential Revision: D55646391
fbshipit-source-id: a759ed39c893a0bc14246c7ee608b1727e6ee4cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43849
Changelog: [internal]
## Context
This is part of a refactor to decouple the performance entry reporter from the rendering infra and from the native module that uses it.
## Changes
This refactors `PerformanceEntryReporter` to make the class not depend on the native module that uses it. Instead of using the `RawPerformanceEntry` type from the native module, we define `PerformanceEntry` in `PerformanceEntryReporter` and use it as the source of truth in the native module instead.
Thanks to the bridging template sytem we have, we can convert the raw objects passed from JS to the C++ structs, defining how the enums are converted from and to JS.
Reviewed By: sammy-SC
Differential Revision: D55646394
fbshipit-source-id: 9cf5a7db6ecb221ca08320d0aaae7e7bc8d91804
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43848
Changelog: [internal]
This makes it easier to see the behavior of the new Event Timing API in RN.
Reviewed By: sammy-SC
Differential Revision: D55646393
fbshipit-source-id: 441fed789a980211783f04095303a139e7b08483
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43847
Changelog: [internal]
(This is an internal change because the API hasn't been released in OSS yet)
This fixes 2 problems in how we dispatch `PerformanceObserver` notifications:
1. If an observer callback throws an error, the remaining observers don't receive notifications.
2. We're notifying observers with an empty list of events when they don't match the filters.
Reviewed By: javache
Differential Revision: D55646390
fbshipit-source-id: 6511c7babd45517baf42076308268ea89afe1265
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43993
changelog: [internal]
clean up tests. The logic is exactly the same, just renaming few variables and deleting unused ones.
Reviewed By: javache
Differential Revision: D55689499
fbshipit-source-id: fffef1051798f1787210cced5e681fa3fe47842b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43985
This is just personal preference.
The name "OnJsError" makes the intent of the abstraction clear: an instance of OnJsError is a function that gets called when a js error is caught.
The name "JsErrorHandlingFunc" is not as good.
Changelog: [General][Breaking] - JsErrorHandler: Rename JsErrorHandlingFunc to OnJsError
Reviewed By: christophpurrer
Differential Revision: D55563580
fbshipit-source-id: 4d20bc984e6633aeac6193b9276a88d76961df2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43957
Right now, JsErrorHandler is only used to handle fatal exceptions.
So, let's just scope handleJsError down to handleFatalError.
Changelog: [General][Breaking] - JsErrorHandler: Rename handleJsError to handleFatalError
Reviewed By: cortinico
Differential Revision: D55547901
fbshipit-source-id: 261e0c8fea2852bc95e53c688d90d012d4abea34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43956
I think we should try to centralize all things js error handling related inside JsErrorHandler. So, I moved this bool into JsErrorHandler.
This makes ReactInstance easier to understand: it removes one member variable from ReactInstance.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547897
fbshipit-source-id: 73d1e0eedf3896c42cda4ce1013863960585da2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43955
Just makes it easier to pass around JsErrorHandler.
We'll need this in D55547897, when we start storing the "has fataled" boolean inside the JsErrorHandler.
Changelog: [internal]
Reviewed By: cipolleschi
Differential Revision: D55547898
fbshipit-source-id: 162faaeff43bada0301de29111b2c17f7ef878c6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43952
getRuntimeScheduler() allows things to schedule work on the js thread by bypassing main bundle buffering.
This is unsafe: almost everything should be using the buffered runtime executor, unless it sets up bindings used in the main bundle.
I filed a task for the investigation to see if there's any problems. And added it to the code in this diff.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D55547899
fbshipit-source-id: 7785b9777e93f36ea0278993332662ed45a20cf2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43861
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/22517999373069959/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725451
fbshipit-source-id: fea231c0f11f41013bcf7a8a9b5cf65badf82503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43981
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/27021599000417439/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725602
fbshipit-source-id: b8b77bf97de5a0eda5b077d6c5441b9af36fc26b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43967
Following up https://github.com/facebook/react-native/issues/43943, the metro loading banner is presented twice in Bridgeless mode.
This happens because both the RCTInstance and the RCTHost are listening to the Reload Command and issuing the instructions to refetch the JSBundle and to present the banner.
The RCTInstance should not concern itself with lifecycle events, owned by the RCTHost.
## Changelog:
[iOS][Fixed] - Avoid to show Metro Loading banner twice.
Reviewed By: cortinico
Differential Revision: D55870640
fbshipit-source-id: addb67d3226f7d7db20736309172a42fc15f3aa3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43864
This change tries to vendor boost. It has several sustainable benefits:
- Reduce the download time to download boost
- Reduce the time to install pods
- Reduce the time to build the project
- Protects us from SEVs due to boost download link being down (happened twice already)
- Fixes how we build boost: currently it is a pseudo-target in iOS with no code, this makes all the symbols weak and this does not plays nicely with the new Apple linker.
## Changelog:
[Internal] - Vendor boost from React Native
Reviewed By: cortinico
Differential Revision: D55742345
fbshipit-source-id: 75abb5a2875e949b3dae299d2e18cb648c46151e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43968
Changelog: [Internal]
When going from a Fusebox build to a non-Fusebox build of the same app, users can accidentally connect a previously opened Fusebox frontend to a non-Fusebox backend (or vice versa).
To prevent this, here we assign a distinct "device ID" to the Fusebox backend on both Android and iOS. This will prevent a mismatched CDT frontend from reconnecting to the app after a backend change, forcing the user to close and reopen the debugger.
Reviewed By: hoxyq
Differential Revision: D55870800
fbshipit-source-id: 8552e009ef1e43b512d35035c98d1a859e3ccf91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43966
The `context` field was confusing. I've renamed it to `currentActivityContext` +
I've made sure the `onKey` method is using the right context with a this@ accessor.
Changelog:
[Android] [Fixed] - Fix ClassCastException in `ReactModalHostView`
Reviewed By: GijsWeterings
Differential Revision: D55870250
fbshipit-source-id: a25a31452fb0d21cf8e2807eca62cf09fe4fd74b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43742
## Changelog:
[Internal] -
As in the title - taking a subset of the views/image Java files, those that are related to interfaces, and convert them to Kotlin.
Reviewed By: tdn120
Differential Revision: D55589946
fbshipit-source-id: 60f03eaaca467821634d5b0195e42bfb931f65fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43920
React native is shipped as a whole, so it makes no sense for individual pods to specify which version of boost they support.
With this change we let the `react_native_pods` and the `boost.podspec` file to decide which version of boost is supported and all the other podspecs will follow.
## Changelog:
[Internal] - Remove explicit boost version from other podspecs
Reviewed By: NickGerleman
Differential Revision: D55801708
fbshipit-source-id: 3dcbbfb25010d2ee615afc4acfd5232fdc0c2a14
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43951
## Context
The **early js** error reporting pipeline catches javascript exceptions.
After errors are caught, the pipeline parses the exception, and puts the data into into a map buffer. 🤨
## Problems
We don't need to use a mapbuffer here: The structure of this exception data is known and never changes. (A map buffer is a type-unsafe bag of key/value pairs).
Instead, we could just use lower-level type-safe language primitives: regular C++ struct, and java class w/ fbjni.
## Changes
Migrate the **early js** error handling infra to C++ structs/fbjni.
## Impact
Now, there is no mapbuffer usage on iOS. We could re-introduce it when there is a need.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55265170
fbshipit-source-id: cda97633d4c6ccaad541e5d416067390fe6f61b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43913
changelog: [internal]
We have this turned on in ParagraphShadowNode, let's roll it out for TextInput as well.
I came across this while profiling scroll performance when TextInput is part of the view hierarchy.
Reviewed By: javache
Differential Revision: D55751341
fbshipit-source-id: 2af20ddb5a4fb9b0ccd33217e60e8b9e8a95b920
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43939
## Problem
If we link the default tmmdelegate with our vr apps, we get this issue:
```
ld.lld: error: duplicate symbol: facebook::react::NativeDevLoadingViewSpecJSI::NativeDevLoadingViewSpecJSI(facebook::react::JavaTurboModule::InitParams const&)
>>> defined at firsttimenux_v2AppModulesCodegen-generated.cpp:1367 (buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/arvr/libraries/react-panellib/FirstTimeNux/__firsttimenux_v2AppModulesCodegen-codegen-modules-jni_cpp__/out/firsttimenux_v2AppModulesCodegen-generated.cpp:1367)
>>> firsttimenux_v2AppModulesCodegen-generated.cpp.pic.o:(facebook::react::NativeDevLoadingViewSpecJSI::NativeDevLoadingViewSpecJSI(facebook::react::JavaTurboModule::InitParams const&)) in archive buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/arvr/libraries/react-panellib/FirstTimeNux/__firsttimenux_v2AppModulesCodegen-jni__/libfirsttimenux_v2AppModulesCodegen-jni.pic.a
>>> defined at rncore-generated.cpp:606 (buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/xplat/js/react-native-github/__rncore-codegen-modules-jni_cpp__/out/rncore-generated.cpp:606)
>>> rncore-generated.cpp.pic.o:(.text._ZN8facebook5react27NativeDevLoadingViewSpecJSIC2ERKNS0_15JavaTurboModule10InitParamsE+0x0) in archive buck-out/v2/gen/fbsource/bcbe7a50bd5ff29a/xplat/js/react-native-github/__rncore-jniAndroid__/librncore-jniAndroid.pic.a
```
## Cause
My best understanding of the problem:
- Default tmmdelegate links against rncore, which contains codegen for react native's standard library of modules.
- But, the default delegate also pulls in this appmodules.so library. That library also contains codegen for react native's standard library of modules + the app's modules.
So, two so libraries define the same symbols. Hence the build fails.
## Solution
Remove the codegen for react native's standard library of modules from the default tmmdelegate.
Prereq: In open source, also make appmodules.so include the codegen for react native's standard library of modules.
Changelog: [Android][Breaking] - Make the app responsible for returning core turbomodule jsi hostobjects
Reviewed By: cortinico
Differential Revision: D55613024
fbshipit-source-id: 6406a9f388ff9de01288de0e263a78a079e7a0da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43860
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/1239557953/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: cortinico
Differential Revision: D55725322
fbshipit-source-id: 8f78d221a8f04136019055a6ea64d8ec05bfd8a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43923
Another round of Kotlin migration.
This time I'm doing `com.facebook.react.views.text.internal.span` which has been recently been annotated as `Nullsafe`
Changelog:
[Internal] [Changed] - Convert the whole `com.facebook.react.views.text.internal.span` package to Kotlin
Reviewed By: tdn120
Differential Revision: D55802155
fbshipit-source-id: 4bed023557f45a43d921df73dfc685e547788fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43930
We don't need `libreact_cxxreactpackage.so` as there is nothing to load. I'm moving this to be an INTERFACE library as there is only a Header file now to load.
Move libreact_cxxreactpackage.so to INTERFACE library
Changelog:
[Internal] [Changed] - Move libreact_cxxreactpackage.so to INTERFACE library
Reviewed By: javache
Differential Revision: D55805573
fbshipit-source-id: 9ef99c430c19250439b8ace5d26b0984a8fb759e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43931
RN Tester is crashing on back navigation with this stacktrace:
```
04-05 17:14:22.906 25051 25051 E AndroidRuntime: FATAL EXCEPTION: main
04-05 17:14:22.906 25051 25051 E AndroidRuntime: Process: com.facebook.react.uiapp, PID: 25051
04-05 17:14:22.906 25051 25051 E AndroidRuntime: java.lang.NullPointerException: Parameter specified as non-null is null: method com.facebook.react.devsupport.DoubleTapReloadRecognizer.didDoubleTapR, parameter view
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.devsupport.DoubleTapReloadRecognizer.didDoubleTapR(Unknown Source:2)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactDelegate.shouldShowDevMenuOrReload(ReactDelegate.java:302)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactActivityDelegate.onKeyUp(ReactActivityDelegate.java:158)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.facebook.react.ReactActivity.onKeyUp(ReactActivity.java:89)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.KeyEvent.dispatch(KeyEvent.java:2878)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.app.Activity.dispatchKeyEvent(Activity.java:4164)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.app.ComponentActivity.superDispatchKeyEvent(ComponentActivity.java:126)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.view.KeyEventDispatcher.dispatchKeyEvent(KeyEventDispatcher.java:86)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.core.app.ComponentActivity.dispatchKeyEvent(ComponentActivity.java:144)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.app.AppCompatActivity.dispatchKeyEvent(AppCompatActivity.java:604)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.view.WindowCallbackWrapper.dispatchKeyEvent(WindowCallbackWrapper.java:60)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at androidx.appcompat.app.AppCompatDelegateImpl$AppCompatWindowCallback.dispatchKeyEvent(AppCompatDelegateImpl.java:3413)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.policy.DecorView.dispatchKeyEvent(DecorView.java:404)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ViewPostImeInputStage.processKeyEvent(ViewRootImpl.java:6377)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess(ViewRootImpl.java:6243)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5725)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5913)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5756)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.apply(ViewRootImpl.java:5970)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5729)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.apply(ViewRootImpl.java:5756)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.deliver(ViewRootImpl.java:5729)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.onDeliverToNext(ViewRootImpl.java:5782)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$InputStage.forward(ViewRootImpl.java:5748)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$AsyncInputStage.forward(ViewRootImpl.java:5946)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.ViewRootImpl$ImeInputStage.onFinishedInputEvent(ViewRootImpl.java:6104)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager$PendingEvent.run(InputMethodManager.java:3159)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager.invokeFinishedInputEventCallback(InputMethodManager.java:2723)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager.finishedInputEvent(InputMethodManager.java:2714)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.inputmethod.InputMethodManager$ImeInputEventSender.onInputEventFinished(InputMethodManager.java:3136)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.view.InputEventSender.dispatchInputEventFinished(InputEventSender.java:154)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.MessageQueue.nativePollOnce(Native Method)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.MessageQueue.next(MessageQueue.java:335)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.Looper.loopOnce(Looper.java:161)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.os.Looper.loop(Looper.java:288)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at android.app.ActivityThread.main(ActivityThread.java:7842)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at java.lang.reflect.Method.invoke(Native Method)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
04-05 17:14:22.906 25051 25051 E AndroidRuntime: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
```
This is happening because the `view: View` parameter is actually null at that point. I'm fixing it.
Changelog:
[Internal] [Changed] - Fix crash of RNTester on back navigation
Reviewed By: tdn120
Differential Revision: D55805574
fbshipit-source-id: 368109ef70725dad2cf72789b259726f859f05b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43918
Changelog: [Internal]
_____
## Why?
We recommend to use Kotlin for any new code and are actively migrating Java code to Kotlin. This codemod service attempts to migrate existing Java code to Kotlin.
## How was this diff generated?
This codemod service scans through qualified paths and looks for Java modules. Then it runs `kotlinator.sh` on each module, which generated this diff.
## What if I see problems in this diff?
We recommend commandeering and fixing the diff. If you reject or abandon the diff, the codemod service will regenerate it in a few days
- Script for easily commandeer & open diff: In fbandroid, `scripts/commandeer_and_checkout.sh <DIFF>`. It not only commandeer the diff, but also rebase & open diff in Android Studio.
- Report repeating issues in [Kotlinator Papercut](https://fburl.com/papercuts/1g4f4qas)
See more useful tips & scripts in [Kotlin Auto-Conversion Codemod Wiki](https://fburl.com/wiki/c68ka0pu)
_____
## Questions / Comments / Feedback?
**Your feedback is important to us! Give feedback about this diff by clicking the "Provide Feedback" button below.**
* Returning back to author or abandoning this diff will only cause the diff to be regenerated in the future.
* Do **NOT** post in the CodemodService Feedback group about this specific diff.
_____
## Codemod Metadata
NOTE: You won't need to read this section to review this diff.
https://www.internalfb.com/intern/sandcastle/job/1239558926/
|Oncall|[kotlin_in_fb4a](https://our.intern.facebook.com/intern/oncall3/?shortname=kotlin_in_fb4a)|
|CodemodConfig|[fbsource/kotlinator.json](https://www.internalfb.com/codemod_service/fbsource%2Fkotlinator.json)|
|ConfigType|configerator|
Rules run:
- CodemodTransformerFBSourceScript
This diff was created with [CodemodService](https://fburl.com/CodemodService).
Reviewed By: javache
Differential Revision: D55725326
fbshipit-source-id: f0960e42cf248ea78613299c16c6a47aa6169c7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43844
This converts the last class inside `com.facebook.react.views.modal` to Kotlin
Changelog:
[Internal] [Changed] - Convert ReactModalHostManager to Kotlin
Reviewed By: javache
Differential Revision: D55739386
fbshipit-source-id: 6bf85449c2bfd6d81a2d899bd044835b9b72c185
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43845
This class is quite legacy and requires a couple of eyes before merging it.
I've tested that modals are working fine on RN-Tester both Old & New Arch.
Changelog:
[Internal] [Changed] - ReactModalHostView to Kotlin
Reviewed By: javache
Differential Revision: D55739128
fbshipit-source-id: 740d24df39ceb7b6a8120ae5315cf0684d1e6e27
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43928
This is a patch version for Kotlin, no practical changes expected.
Changelog:
[Internal] [Changed] - Bump Kotlin to 1.9.23
Reviewed By: cipolleschi
Differential Revision: D55803534
fbshipit-source-id: 99fcf444885cbc7b95baec2983303cfee88874a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43859
This frees up the `reactnative` CMake target so we could use it as single .so
for the CMake build.
Changelog:
[Internal] [Changed] - Rename reactnative.a -> react_cxxreact.a
Reviewed By: javache
Differential Revision: D55745640
fbshipit-source-id: 3cad512cc07a277af2a0cea696863c85a17dabc1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43907
JSC is currently instacrashing because we missed a JvmStatic.
Android will attempt to load JSCInstance.initHybrid which is missing unless we specify JvmStatic.
Changelog:
[Internal] [Changed] - Fix Android instacrashing on JSC with NoSuchMethodException
Reviewed By: GijsWeterings
Differential Revision: D55795290
fbshipit-source-id: 5d10344e3f481dc5832706d77ccf2bf163dfb30f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43865
Some of the includes in the task that prepares prefabs are duplicated. Removing the duplication
## Changelog:
[Internal] - Cleanup android prefabs
Reviewed By: cortinico
Differential Revision: D55751660
fbshipit-source-id: 2ea610937f122f82bc91e09fac1a2c78efa83410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43717
As we are going to bridgeless in new architecture, we want to clean up the usage of RCTBridge to use RCTModuleRegistry to access NativeModule.
Changelog:
[iOS][Breaking] Remove `RCTRedBox` access through `RCTBridge`
Reviewed By: philIip
Differential Revision: D55532209
fbshipit-source-id: 62aa2a24b60ab54d7f3cf25c34beda4449aaeaed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43824
Changelog: [Internal]
# Feature flag cleanup/migration
This migration is part of the new Feature Flag system built by rubennorte. The goal of this migration is to clean up our Feature Flags and consolidate them into a single place, accessible by all platforms.
# In this diff
Replaced `RCTSetUseNativeViewConfigsInBridgelessMode` and `RCTGetUseNativeViewConfigsInBridgelessMode` with `ReactNativeFeatureFlags.useNativeViewConfigsInBridgelessMode()` and ReactNativeFeatureFlags::override
Reviewed By: javache
Differential Revision: D55705805
fbshipit-source-id: 861675a1a94da0fcef8d8a02ccbd8ecdd97ec700
Summary:
With 0.74.rc-5 one bug which related to errors was fixed (https://github.com/facebook/react-native/issues/41950). However, the fix introduced another one: the shape of Error objects that come from native modules has changed. This PR attempts to fix that, though it's not (yet) doing it in a way that would be 100% compatible with the old arch.
The problem was observed on iOS, not sure what the situation is on Android but believe it's okay there.
edit: on Android, there are no issues but the `message` field is enumerable, so that part is different from ios (see logs below).
Consider this code, where `error` is produced from a promise rejection inside of a native module.
```ts
console.log(
'own properties: ',
JSON.stringify(Object.getOwnPropertyNames(error), null, 2),
);
console.log(
'own enumerable properties: ',
JSON.stringify(Object.entries(error), null, 2),
);
```
These are the results for
<details>
<summary>Old architecture</summary>
```
LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{}}
LOG own properties: [
"stack",
"code",
"message",
"domain",
"userInfo",
"nativeStackIOS"
]
LOG own enumerable properties: [
[
"code",
"-5"
],
[
"message",
"RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}"
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x0000000102f4a6d8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000102eeedd0 __41-[RCTModuleMethod processMethodSignature]_block_invoke_2.73 + 152",
"2 ReactTestApp 0x0000000102e2ae24 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000102e2aa8c -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102e2a8e0 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000102e28628 __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x0000000102dc9d80 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
]
]
```
</details>
<details>
<summary>RN 74 rc-5 (with bridgeless on)</summary>
```
(NOBRIDGE) LOG Bridgeless mode is enabled
(NOBRIDGE) LOG Running "google-one-tap-example" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"cause"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"cause",
{
"code": "-5",
"message": "RNGoogleSignIn: The user canceled the sign in request., Error Domain=com.google.GIDSignIn Code=-5 \"The user canceled the sign-in flow.\" UserInfo={NSLocalizedDescription=The user canceled the sign-in flow.}",
"nativeStackIOS": [
"0 ReactTestApp 0x00000001023a7b38 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x00000001026cf774 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000102270958 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x00000001022705c0 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x0000000102270414 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x000000010226e15c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x000000010220f328 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
],
"domain": "com.google.GIDSignIn",
"userInfo": {
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
}
]
]
```
</details>
<details>
<summary>with the diff from this PR</summary>
```
(NOBRIDGE) LOG own properties: [
"stack",
"message",
"code",
"nativeStackIOS",
"domain",
"userInfo"
]
(NOBRIDGE) LOG own enumerable properties: [
[
"code",
"-5"
],
[
"nativeStackIOS",
[
"0 ReactTestApp 0x000000010083b8f8 RCTJSErrorFromCodeMessageAndNSError + 112",
"1 ReactTestApp 0x0000000100b63534 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.57 + 332",
"2 ReactTestApp 0x0000000100704718 +[RNGoogleSignin rejectWithSigninError:withRejector:] + 548",
"3 ReactTestApp 0x0000000100704380 -[RNGoogleSignin handleCompletion:serverAuthCode:withError:withResolver:withRejector:fromCallsite:] + 184",
"4 ReactTestApp 0x00000001007041d4 -[RNGoogleSignin handleCompletion:withError:withResolver:withRejector:fromCallsite:] + 236",
"5 ReactTestApp 0x0000000100701f1c __40-[RNGoogleSignin signIn:resolve:reject:]_block_invoke_2 + 100",
"6 ReactTestApp 0x00000001006a30e8 __35-[GIDSignIn addCompletionCallback:]_block_invoke_2 + 132",
...
]
],
[
"domain",
"com.google.GIDSignIn"
],
[
"userInfo",
{
"NSLocalizedDescription": "The user canceled the sign-in flow."
}
]
]
```
</details>
You see there is a change compared to old arch because `message` is no longer own enumerable property. If that needs to change (I guess it should), it'd be nice if someone more familiar with JSI pointed me in the right direction. Even with this inconsistency, the PR is an improvement and would be nice to have this fix included in the next RC.
This is output from Chrome's console for completeness, just to have something to compare to:
```
let err = new Error('hello')
undefined
Object.getOwnPropertyNames(err)
> ['stack', 'message']
Object.entries(err)
> []
```
bypass-github-export-checks
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - add missing fields to native errors in new arch
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43649
Test Plan: Tested locally with an example app running RN 74-rc 5
Reviewed By: cortinico
Differential Revision: D55690184
Pulled By: cipolleschi
fbshipit-source-id: 60a857b9871af888dcd526782b5e6b73c07c051a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43851
## Summary
Adds a `react-native.code-workspace` workspace file when using VS Code. This disables the built-in TypeScript Language Service for `.js` files, recommends extensions, enables `formatOnSave`, and configures Flow language support.
We will recommend this workspace config in our contributing guide: https://github.com/facebook/react-native-website/pull/4075.
**Motivation**
This is a DevX benefit for **React Native contributors** using open source VS Code — in particular to help with recent/trivial papercuts in PRs such as inserting a final newline in files (configured by EditorConfig).
**Recommended extensions**
NOTE: The recommended extensions list is currently minimal — happy to extend this now or in future, but let's aim to keep these conservative.
- Flow — language support
- EditorConfig — formatting based on `.editorconfig`, all file types
- Prettier — formatting for JS* files
- ESLint — linter for JS* files
**Why `react-native.code-workspace`?**
`.code-workspace` files have slight extra behaviours over a `.vscode/` directory:
- Allows user to opt-in or skip.
- Allows double-click launching from file managers.
- Allows base folder (and any subfolders in future) to be opened with local file tree scope (useful in fbsource!)
- (Minor point) Single config file over multiple files.
https://code.visualstudio.com/docs/editor/workspaces
Changelog: [Internal]
## Test plan
Aganst a new unconfigured copy of Visual Studio Code Insiders.
**Without workspace config**
❌ `.js` files raise errors by default (built-in TypeScript language service)
{F1478195672}
❌ When using the Flow VS Code extension, the wrong version (global) of Flow is used.
**With workspace config**
✅ Workspace config is suggested when folder is opened in VS Code
{F1478194795}
✅ Dialog is shown on workspace launch with recommended VS Code extensions
{F1478196003}
✅ Built-in TypeScript Language Service is disabled for `.js` files
✅ Flow language support is configured correctly against `flow` version in `package.json`
{F1478291085}
{F1478200649}
Reviewed By: motiz88
Differential Revision: D55698495
fbshipit-source-id: b0b2f459cf05afc3e7862c9845066a66aaa1985b
Summary:
In the Old Architecture and for Swift Libraries, these two methods are used to initialize a new disctionary but their implementation was missing so some libraries like lottie were failig to build.
## Changelog:
[Internal] - Implement missing `count` and `keyEnumerator` methods for RCTComposedViewRegistry
Pull Request resolved: https://github.com/facebook/react-native/pull/43850
Test Plan: Tested locally with the repro provided by SWM
Reviewed By: javache
Differential Revision: D55743648
Pulled By: cipolleschi
fbshipit-source-id: 7bdb92625341cd704b8b09920ab3223a2ca61a54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43857
Changelog: [Internal]
There seems to be a weird problem with OkHttpCallUtil:
* D55707704 works in fbsource but breaks the CircleCI build with
> using 'dispatcher(): Dispatcher' is an error. moved to val
* D55744165 fixes the CircleCI build but breaks in fbsource with
> cannot access 'dispatcher': it is package-private in 'OkHttpClient'
Not sure what's the real fix to migrate `OkHttpCallUtil` to Koltin but at this point is probably safer to backout the original migration! 😥
Reviewed By: cortinico
Differential Revision: D55745345
fbshipit-source-id: 3ec6e4d99c950098fae974aa5f0e5be0b6663249
Summary:
Working with gabrieldonadel, we realized that static frameworks of the React-RendererRuntime are not following the proper folder structure.
When a user tries to import `ReactCommon/RCTHost` in the app delegate, for example, the user ends up with an error and they can't find the files.
These changes fixes this by establishing the right folder structure in the static frameworks
## Changelog:
[Internal] - Make sure that React-RuntimeCore and JSErrorHandler are created with the proper structure for static frameworks
Pull Request resolved: https://github.com/facebook/react-native/pull/43846
Test Plan:
Tested locally on an app with 0.74.
Before: it failed to build.
After: it build successfully.
Reviewed By: cortinico
Differential Revision: D55741581
Pulled By: cipolleschi
fbshipit-source-id: 11ac0882d3feea05ef8904d55856ba5704b7a3b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43785
Deprecated `UIManager.showPopupMenu()` had success callback that would be triggered on 1) item selection or 2) dismiss.
New `PopupMenuAndroid` only has item selection callback so adding in missing dismiss callback.
Changelog:
[Android][Added] - Add (optional) onPopupDismiss() callback for PopupMenuAndroid
Reviewed By: cortinico
Differential Revision: D55531870
fbshipit-source-id: 26f3992ef6c85fbc6d8dfff00cb723ac4aae3762
Summary:
The React Native ESLint preset currently endorses the Prettier integration that is [explicitly recommended against by Pretier itself](https://prettier.io/docs/en/integrating-with-linters). Notice the difference between these two packages:
- `eslint-config-prettier` is the config that turns off all formatting rules. It's **recommended by Prettier** to be used together with Prettier. You'd still use Prettier itself to actually do the formatting.
- `eslint-plugin-prettier` is a legacy plugin developed a long time ago and that predates most modern Prettier integrations. It runs Prettier as if it were an ESLint rule, applies formatting on `--fix`, and **is not recommended**.
Unfortunately, RN uses the latter one (and always has).
This PR removes `eslint-plugin-prettier` and instead enables `eslint-config-prettier`, as recommended by Prettier.
As a consequence, you'll no longer see squiggly lines in your editor for stuff that isn't actually errors:
<img width="558" alt="Screenshot 2024-04-01 at 20 00 50" src="https://github.com/facebook/react-native/assets/810438/91ae2cec-a9ef-4205-a9ce-6ab858785ed2">
As another consequence, **you'll have to set up your own Prettier step in your pipeline**.
For example, if your precommit hook only contained `eslint --fix`, you'll now also need to run `prettier --write` there as well. Similarly, if you want Prettier to fail CI, you'd need to find where you call `eslint` and also do `prettier --check` there.
Here's an example for how to do it: https://github.com/bluesky-social/social-app/pull/3373
## 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
-->
[GENERAL] [BREAKING] - RN ESLint config no longer runs Prettier during ESLint
Pull Request resolved: https://github.com/facebook/react-native/pull/43756
Test Plan:
Tested locally, verified formatting changes no longer get flagged as violations by the RN config.
<img width="470" alt="Screenshot 2024-04-01 at 20 33 55" src="https://github.com/facebook/react-native/assets/810438/515db971-18bc-4625-bb6d-b9d072692923">
Reviewed By: motiz88
Differential Revision: D55643699
Pulled By: yungsters
fbshipit-source-id: 97df774275922086f0356ac857d6425713184e39
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43816
We should not attempt to load generated classes by the Annotation processor in OSS because we simply don't run it, so those classes will fail to load. I'm short-circuiting the logic here.
This is sustainability work as we got a report for this in OSS a while ago and I never got the time to work on it.
Changelog:
[Internal] [Changed] - Do not attempt to call Class.forName in OSS
Reviewed By: rshest
Differential Revision: D55693479
fbshipit-source-id: 3ec84e2c7940011b48f354058b5099b46065166d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43822
Changelog: [Internal]
# Feature flag cleanup/migration
This migration is part of the new Feature Flag system built by rubennorte. The goal of this migration is to clean up our Feature Flags and consolidate them into a single place, accessible by all platforms.
# In this diff
Replaced `ReactFeatureFlags.useNativeViewConfigsInBridgelessMode` with `ReactNativeFeatureFlags.useNativeViewConfigsInBridgelessMode()`
Reviewed By: cortinico
Differential Revision: D55695173
fbshipit-source-id: e5158a9d5606f16f8e333321bad472f7eb315d0b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43811
This class was really old and had a lot of potential NPEs as it was accessing fields that could have been not initialized properly. I'm fixing it here ahead of a Kotlin migration.
Changelog:
[Internal] [Changed] - Mark ReactModalHostView as NullSafe
Reviewed By: fkgozali
Differential Revision: D55690285
fbshipit-source-id: 3e910da6dc43a30f2f86d4f1e9d02ead006a31c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43814
This is just an example on how to use the NullSafe annotation
Changelog:
[Internal] [Changed] - Annotate AndroidUnicodeUtils as NullSafe
Reviewed By: alanleedev
Differential Revision: D55419929
fbshipit-source-id: 4eac059c5992661ada4ef8d35327dd9a4bc11d25
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43815
This moves a lot of classes from Java to Kotlin from the `package com.facebook.react.views.modal`
Changelog:
[Internal] [Changed] - Convert several classes inside `com.facebook.react.views.modal` to Kotlin
Reviewed By: rshest
Differential Revision: D55692067
fbshipit-source-id: 67e93c9d5d5f58add31ca6726c9f1e4ac2e8ffc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43789
This diff introduces some changes to React Native needed to enable fragment-based navigation (see next diff for usage).
Fragment-based navigation will enable us to, instead of re-creating the entire main activity on navigation, create a fragment instead - allowing us to bypass a lot of unnecessary onCreate() logic in our main activity to improve user experience and performance.
Changelog:
[Internal] [Changed] - Add option to skip calling delegate on ReactFragment lifecycle events
Reviewed By: keoskate
Differential Revision: D55646221
fbshipit-source-id: 45b148cb9ecdb1484f1ac714ac2b93ce09c52237
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43810
This bot never works because facebook bot is faster.
I'm updating the logic to always publish the thank you message + update the link with the correct one.
Changelog:
[Internal] [Changed] - Always quote the user + add links to the release support policy
Reviewed By: rshest, cipolleschi
Differential Revision: D55643675
fbshipit-source-id: d2e726580c82d7f89b37d17846675b7c4c38e908
Summary:
PR https://github.com/facebook/react-native/issues/43468 landed in main which uses UIMenuAutoFill that is available only in iOS 17.
Despite having the `available` checks, these are only runtime checks. The symbol is not stripped on older versions of Xcode and therefore our jobs which uses older Xcode versions started failing.
This change wraps the offending code in a compilation pragma that strips away the symbol when building with Xcode versions that does not know iOS 17.
## Changelog:
[iOS][Fixed] - wrap UIMenuAutoFill in compilation checks for iOS 17
Pull Request resolved: https://github.com/facebook/react-native/pull/43808
Test Plan: CircleCI is green
Reviewed By: cortinico
Differential Revision: D55688255
Pulled By: cipolleschi
fbshipit-source-id: d69874b60e73da1fbdfc61d594870a48f97c3797
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
Changelog: [iOS][Added]
this change will be included in the RN CLI. so all new apps running the RN CLI to get created will get this manifest. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53682756
fbshipit-source-id: 0426fe0002a3bc8b45ef24053ac4228c9f61eb85
Summary:
This pull request resolves the issue https://github.com/facebook/react-native/issues/43452
Previously, when utilizing `contextMenuHidden`, the context menu wasn't entirely hidden as the "AutoFill" option remained visible. However, it's now possible to eliminate it using the menu builder.
## 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
-->
[IOS] [FIXED] - hide AutoFill from context menu when using `contextMenuHidden`
Pull Request resolved: https://github.com/facebook/react-native/pull/43468
Test Plan:
Manual tests in RNTester:
https://github.com/facebook/react-native/assets/39670088/dc0f828c-f613-412d-b560-f3b795dd3ffb
Reviewed By: javache
Differential Revision: D54902269
Pulled By: tdn120
fbshipit-source-id: e0f3d3b5a0817db1c072caf2f01648432c7d868d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43777
It's best to avoid mutex reentrancy, even when using "read" locks (i.e., std::shared_lock). Since we already have a read lock on the ShadowTree in `UIManager::setNativeProps_DEPRECATED`, we can avoid the reentrancy by grabbing ancestor node from the shadow tree instead of relying on a recursive call to ShadowTreeRegistry::visit
## Changelog
[GENERAL][FIXED] - Avoid ShadowTreeRegistry::mutex_ read lock reentrancy
Reviewed By: rubennorte
Differential Revision: D55640201
fbshipit-source-id: 7a5c6674d290ea280ab584ae734733f12a65f6f8
Summary:
This PR removes forward declaration of `loadSourceForBridge` methods from the RCTRootViewFactory as it was causing an issue on old architecture, where the RedBox wouldn't popup when metro wasn't running.
As stated by Kudo [here](https://github.com/reactwg/react-native-releases/issues/177):
> the problem was coming from the implementation
> https://github.com/facebook/react-native/blob/00725fadff28bb3c7fed65f208e647f0dab69e75/packages/react-native/React/CxxBridge/RCTCxxBridge.mm#L519-L540
>
> we should dynamically override loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: in RCTRootViewFactory only when AppDelegate override it. one way to achieve this might be tricky that we may need to override respondsToSelector:.
>
> otherwise, we could just skip the loadSourceForBridge:onProgress:onComplete: and loadSourceForBridge:withBlock: support.
There is no straight forward solution to implement this without some _hacks_ so I'm removing this forward block for now.
## Changelog:
[IOS] [FIXED] - remove loadSourceForBridge in RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43656
Test Plan: CI Green
Reviewed By: rshest
Differential Revision: D55485094
Pulled By: cortinico
fbshipit-source-id: 1e391e0795c3d99686f2805165f64a7715b013f6
Summary:
With D55574528 and D55623682 having landed concurrently, and the latter enabling warnings-as-errors for Kotlin files vs the former having one such warning, this caused a build breakage.
This diff fixes it.
Reviewed By: andrewdacenko
Differential Revision: D55636176
fbshipit-source-id: 781b8cf40a4e9aa8a3da3005d26dca975f146c09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43706
Changelog: [internal]
Just a small improvement of the UI for the Performance API examples in RNTester.
Reviewed By: christophpurrer
Differential Revision: D55489933
fbshipit-source-id: a1fe4f4962227941827f02cf18a0d4685e18f006
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43701
Changelog: [internal]
We were defining an `UNDEFINED` type of entry that should never happen in practice and we were using unnecessarily to signal "no type" where an optional type would be more suitable. Most importantly, **we were incorrectly allocating a buffer for entries of this type**.
This removes that type and the unnecessary buffer.
Reviewed By: rshest
Differential Revision: D55478890
fbshipit-source-id: 145210a9c4e2614a342f2d913b9eb6b3d62f676f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43702
Changelog: [internal]
Just a minor refactor to use C++20 designated initializers in `PerformanceEntryReporter` and its tests, while removing unnecessary initialization for optional fields.
Reviewed By: rshest
Differential Revision: D55477745
fbshipit-source-id: a643adf7ae48df23c5c383420fd4c4dd550e1322
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43703
Changelog: [internal]
(internal because this API isn't available in OSS yet)
I found a bug in the current implementation of `performance.measure` where the API would use the first `mark` reported under a specific name instead of the last one (found it in the new example in RNTester in D55477746 that re-logs the marks every time we click on a button).
The root cause for this problem is that we were using `insert` from `std::unordered_set` to update the value, but `insert` doesn't modify the value if it's already present.
This fixes the issue by doing a lookup and removing the value prior to inserting it.
Reviewed By: rshest
Differential Revision: D55477743
fbshipit-source-id: e72aa784a936828db64b572988fe0acb2ad78214
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43704
Changelog: [internal]
Adding examples of the rest of APIs in `Performance`/`PerformanceObserver` starting with marks and measures.
Reviewed By: rshest
Differential Revision: D55477746
fbshipit-source-id: 965796b6a97dc527192093e3c93af837a4d5b714
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43752
Gentest tests started failing because Chrome changed behavior of overflowed align-content container. Spec says should fallback to "safe center", which is really just "start", instead of previous "center" behavior. This changes behavior accordingly.
There is one bit where I think we are doing the wrong thing wrt alignment of flex start vs start (which we don't support yet), but couldn't repro a failing chrome test.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D55617689
fbshipit-source-id: 08f23d198c75f2c2f51ccaa8795289e6e4a92cb8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43730
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/devsupport/LogBox*.java` to Kotlin.
Reviewed By: NickGerleman
Differential Revision: D55574528
fbshipit-source-id: 56cf5de75d18cd73929cb7f0c9375a3f62e83574
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43755
This is another place where the OSS build went ahead of the internal source of truth, which has caused build breaks more than once.
This enables warnings as errors in `rn_android_library` for consistency. This is used for a couple libraries outside of ReactAndroid that might need fixup/suppression.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623682
fbshipit-source-id: 37da30c642de2c3d8390334a0d0bff365a4ed7a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43754
Moves off of deprecated `DisplayMetrics.scaledDensity` API to builtin font scaling API, while still clamping to max multiplier using previous logic.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55623674
fbshipit-source-id: 2668eea8dbd154cc046e2c515323ad66b289dc64
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43729
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/*Util.kt` to Kotlin.
Reviewed By: tdn120
Differential Revision: D55574531
fbshipit-source-id: 974234bd57c77e863aa723388e48ffc455e73a96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43728
# Changelog:
[Internal] -
As in the title, converts corresponding type declarations in `react/uimanager/layoutanimation/*Type.kt` to Kotlin.
Differential Revision: D55574530
fbshipit-source-id: 8527b5c9b491435c60ed9c05092ffeccd7552f9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43727
# Changelog:
[Internal] -
As in the title, converts this one particular Java file to Kotlin.
Reviewed By: arushikesarwani94
Differential Revision: D55574526
fbshipit-source-id: 04af5b870670a5560eaba7ab8c029c580032d09a
Summary:
Fix version checker not considering nightlies:
```
WARNING: You should run npx react-native@latest to ensure you're always using the most current version of the CLI. NPX
has cached version (0.74.0-nightly-20240214-b8ad91732) != current release (0.73.6)
```
## Changelog:
[GENERAL] [FIXED] - Fix version checker not considering nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/43712
Test Plan: On a recent nightly version, run any cli command.
Reviewed By: rshest
Differential Revision: D55525055
Pulled By: zeyap
fbshipit-source-id: 6dd08e30e542d9ddd191bf95c968a26c0cc14e4e
Summary:
Currently the react-native-gradle-plugin does not allow the "react" plugin extension to already exist when running its apply block. I had a use-case where I wanted to create a new gradle plugin which would take care of applying the react plugin including setting some of its options. Without the change in this PR, this would currently turn into a build failure.
## Changelog:
[ANDROID] [FIXED] - prevent error when the "react" extension was already created by another gradle plugin
Pull Request resolved: https://github.com/facebook/react-native/pull/43694
Reviewed By: rshest
Differential Revision: D55478611
Pulled By: zeyap
fbshipit-source-id: cc743a99cb72ed315d21c52597efd5ee92a3be62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43677
Remove `RCT_ENABLE_LOADING_FROM_PACKAGER` from `RCTDefines`, as it is not referenced anywhere and does nothing.
Changelog: [Internal]
Reviewed By: hoxyq, realsoelynn
Differential Revision: D55421282
fbshipit-source-id: ae29a8a421a6cc23d863b489eae2175392f684cd
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
---
Reviewed By: fkgozali
Differential Revision: D55505416
fbshipit-source-id: ce1e3ab379eb788d26130dd44a66544aada3db02
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43697
Currently, messages from a device are handled by async handlers added to a promise chain.
If a handler rejects, the end of the chain becomes a rejected promise, picked up only asynchronously by Metro's global `unhandledRejection` handler.
This triggers a warning from Node.js, and worse, prevents any `then()` callback chained by subsequent messages from being invoked at all.
Handlers *should* attempt to gracefully deal with errors (as we do with source map fetching errors, for example), but this diff adds a catch-all fallback for anything we might've missed (in this case, a frontend socket disconnecting while we're busy fetching a source map). Errors are caught and logged to EventReporter.
**To follow**: Gracefully handle socket disconnections while an async handler is working or queued.
Changelog:
[General][Fixed] Inspector proxy: prevent errors proxying a device message from blocking the handler queue or spamming logs.
Reviewed By: EdmondChuiHW
Differential Revision: D55482735
fbshipit-source-id: bb726218495e105f9cb4f723a1d110c9815abdef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43599
iOS E2E tests non-deterministic rendering happens around examples with a border set to `StyleSheet.hairlineWidth`. That value has special subpixel math, that doesn't seem to render consistently on iOS (this is its own bug).
To unblock adding some new E2E iOS TextInput tests, this removes usage of `hairlineWidth` in styles, and more generally, tries to unify TextInput styles in the examples.
This will break a whole bunch of RNTester Jest E2E baselines on different apps, which I will update from land-time runs or after continuous builds are available for different endpoints.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55213090
fbshipit-source-id: 6d81b9355adc538a3ade6f50ef93c3ca08782ae7
Summary:
Stacked on top of #28498 for test fixes.
### Don't Rethrow
When we started React it was 1:1 setState calls a series of renders and
if they error, it errors where the setState was called. Simple. However,
then batching came and the error actually got thrown somewhere else.
With concurrent mode, it's not even possible to get setState itself to
throw anymore.
In fact, all APIs that can rethrow out of React are executed either at
the root of the scheduler or inside a DOM event handler.
If you throw inside a React.startTransition callback that's sync, then
that will bubble out of the startTransition but if you throw inside an
async callback or a useTransition we now need to handle it at the hook
site. So in 19 we need to make all React.startTransition swallow the
error (and report them to reportError).
The only one remaining that can throw is flushSync but it doesn't really
make sense for it to throw at the callsite neither because batching.
Just because something rendered in this flush doesn't mean it was
rendered due to what was just scheduled and doesn't mean that it should
abort any of the remaining code afterwards. setState is fire and forget.
It's send an instruction elsewhere, it's not part of the current
imperative code.
Error boundaries never rethrow. Since you should really always have
error boundaries, most of the time, it wouldn't rethrow anyway.
Rethrowing also actually currently drops errors on the floor since we
can only rethrow the first error, so to avoid that we'd need to call
reportError anyway. This happens in RN events.
The other issue with rethrowing is that it logs an extra console.error.
Since we're not sure that user code will actually log it anywhere we
still log it too just like we do with errors inside error boundaries
which leads all of these to log twice.
The goal of this PR is to never rethrow out of React instead, errors
outside of error boundaries get logged to reportError. Event system
errors too.
### Breaking Changes
The main thing this affects is testing where you want to inspect the
errors thrown. To make it easier to port, if you're inside `act` we
track the error into act in an aggregate error and then rethrow it at
the root of `act`. Unlike before though, if you flush synchronously
inside of act it'll still continue until the end of act before
rethrowing.
I expect most user code breakages would be to migrate from `flushSync`
to `act` if you assert on throwing.
However, in the React repo we also have `internalAct` and the
`waitForThrow` helpers. Since these have to use public production
implementations we track these using the global onerror or process
uncaughtException. Unlike regular act, includes both event handler
errors and onRecoverableError by default too. Not just render/commit
errors. So I had to account for that in our tests.
We restore logging an extra log for uncaught errors after the main log
with the component stack in it. We use `console.warn`. This is not yet
ignorable if you preventDefault to the main error event. To avoid
confusion if you don't end up logging the error to console I just added
`An error occurred`.
### Polyfill
All browsers we support really supports `reportError` but not all test
and server environments do, so I implemented a polyfill for browser and
node in `shared/reportGlobalError`. I don't love that this is included
in all builds and gets duplicated into isomorphic even though it's not
actually needed in production. Maybe in the future we can require a
polyfill for this.
### Follow Ups
In a follow up, I'll make caught vs uncaught error handling be
configurable too.
---------
DiffTrain build for commit https://github.com/facebook/react/commit/6786563f3cbbc9b16d5a8187207b5bd904386e53.
Changelog:
[Internal]
Reviewed By: kassens
Differential Revision: D55408481
Pulled By: yungsters
fbshipit-source-id: 598aa306369e21cb3e93ad6041a87bfbaa9eef9e
Co-authored-by: Ricky Hanlon <rickhanlonii@gmail.com>
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43686
Under Node 20, the use of `new Buffer(string)` is deprecated and logs a warning. This replaces it with the recommended `Buffer.from(string)`.
Changelog:
[General][Fixed] FIx "Buffer() is deprecated" warning from debugger proxy.
Reviewed By: huntie
Differential Revision: D55472025
fbshipit-source-id: 8b5af9e2d7e026cbdf6aa68f71ff0f856fb164db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43698
changelog: [internal]
RCTViewComponentView was missing isAccessibilityElement override. Here I add it and use contentView to determine if element is accessible.
Reviewed By: rubennorte
Differential Revision: D55483944
fbshipit-source-id: f29c82a42d17140ae421f27871a3bf6f7f36bc12
Summary:
## Context
Prior, ReactContext used to implement bridge logic.
For bridgeless mode, we created BridgelessReactContext < ReactContext
## Problem
This could lead to failures: we could call bridge methods in bridgeless mode.
## Changes
Primary change:
- Make all the react instance methods inside ReactContext abstract.
Secondary changes: Implement react instance methods in concrete subclasses:
- **New:** BridgeReactContext: By delegating to CatalystInstance
- **New:** ThemedReactContext: By delegating to inner ReactContext
- **Unchanged:** BridgelessReactContext: By delegating to ReactHost
## Auxiliary changes
This fixes ThemedReactContext in bridgeless mode.
**Problem:** Prior, ThemedReactContext's react instance methods did not work in bridgeless mode: ThemedReactContext wasn't initialized in bridgeless mode, so all those methods had undefined behaviour.
**Solution:** ThemedReactContext now implements all react instance methods, by just forwarding to the initialized ReactContext it decorates (which has an instance).
Changelog: [Android][Removed] Delete ReactContext.initializeWithInstance(). ReactContext now no longer contains legacy react instance methods. Please use BridgeReactInstance instead.
Reviewed By: javache
Differential Revision: D53145010
fbshipit-source-id: 2405bc24afb00864117d3c504fc9c4cbffd7203a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43696
This just sets explicitApi to true for every module inside ReactAndroid
Changelog:
[Internal] [Changed] - Flip explicitApi to True for everyone
Reviewed By: tdn120
Differential Revision: D55478674
fbshipit-source-id: c9aeba89ad5b0f88bca7fd480c6aa66e0152a456
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43699
This diff initializes `RELEASE_VERSION` with the value that is provided by the `get_react_native_version` job (it stores its output into `/tmp/react-native-version`).
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D55484988
fbshipit-source-id: f0b5bb473096f3691f50152beb3181a454916fdc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43661
# Changelog: [Internal]
1. Remove `BridgelessDebugReactPackage.java`, this was added in D43407534. Technically, its the same as `DebugCorePackage.java`.
2. `ReactInstance` to add `DebugCorePackage`, so `DebuggingOverlay` view manager will be included in the bridgeless build.
3. Fix `RNTesterApplication.kt` to NOT create `MyLegacyViewManager` for every possible viewManagerName, apart from `"RNTMyNativeView"`, return null instead.
Reviewed By: cortinico
Differential Revision: D55375350
fbshipit-source-id: 1d3cb6b5ad3c0248df1def9f37c8c49b308f4473
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43690
# Changelog: [Internal]
Fixes https://github.com/facebook/react-native/issues/43678.
The issue is that once `getInspectorDataForViewAtPoint` is imported, it should throw if RDT global hook was not injected. ReactDevTools overlay imports `getInspectorDataForViewAtPoint`, this is why it did throw in testing environment.
ReactDevToolsOverlay JSX-element is already gated with RDT global hook check, adding a deferred import, same as it was already implemented for Inspector.
Still unclear to me how this didn't throw all this time while using the Catalyst / RNTester.
Reviewed By: cortinico
Differential Revision: D55474774
fbshipit-source-id: 759e5e8227cc7534193e5b95616b6099c15f5cb5
Summary:
When RN moved Button component from a class component to a function component (https://github.com/facebook/react-native/commit/07e8ae42bed71f54bbe0e786ccad88b2f14648a4) a forwardRef call was not added to the Button control. This caused a set of tests downstream in React Native for Windows to fail because they rely on being able to pass a ref through to the Button control.
## Changelog:
[GENERAL] [FIXED] - Adds forwardRef call to new functional component implementation of Button control.
Pull Request resolved: https://github.com/facebook/react-native/pull/43666
Test Plan: Button render remains the same.
Reviewed By: fabriziocucci
Differential Revision: D55398765
Pulled By: zeyap
fbshipit-source-id: ba32c764c16cb529ab1c92cb7888f2bae0f16f5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43664
Changelog: [internal]
Now that we have the event loop, we can modify the implementation of `MutationObserver` (which is still not enabled by default) to dispatch the notifications as microtasks, making the API more spec-compliant.
Reviewed By: javache
Differential Revision: D55380178
fbshipit-source-id: f876ffba49f9744f6603053f1485e7c2f43cb230
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43672
Changelog: [internal]
Small cleanup to move the last C++ native module defined in a JS directory to the new directory in `react-native/ReactCommon/react/nativemodule`.
Reviewed By: javache
Differential Revision: D55384106
fbshipit-source-id: 3bf477c2aceab6838f7f8131174b6eb74e890a23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43663
Changelog: [internal]
We have a new directory for built-in C++ native modules, but the native modules for `MutationObserver` and `IntersectionObserver` were created before we had it.
This moves the native module for `MutationObserver` to `react-native/ReactCommon/react/nativemodule/mutationobserver` to follow the convention.
Reviewed By: javache
Differential Revision: D55380179
fbshipit-source-id: 0c64acbec973f2e5b57a0e38a0992bba49a01a45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43653
Changelog: [internal]
This will allow us to clean up some code in `UIManager` (using methods in the native module instead) and prepare to use the DOM APIs in OSS behind a feature flag.
This doesn't enable the DOM APIs in OSS, only the native module.
Reviewed By: javache
Differential Revision: D55365252
fbshipit-source-id: 70ec0eb022df586ad554c5b8ce6915b8ceddef5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43659
Changelog: [internal]
This adds an implementation for the legacy layout measurement methods in React Native (`measure`, `measureInWindow` and `measureLayout`) in the DOM native module, so we can clean up the API from the `nativeFabricUIManager` binding.
Reviewed By: javache
Differential Revision: D55368141
fbshipit-source-id: 196d4d29be3b78ffc22fdc136be6e0cf5ab9dd26
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43679
The current implementation of clear-with-predicate first copies unconsumed
elements and then all others. This works correctly when the buffer is full
(wraps around), but fails if size() < maxSize: add() may no longer insert
an element in the correct position (after the last unconsumed entry; see
new unit test).
Replace it with a loop that iterates over all entries in order, and adjusts
cursorStart and cursorEnd to point to the last numToConsume elements of the
vector.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55273402
fbshipit-source-id: 647dc35faeb35c7fa99b8113cf85ce7f02f073e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43676
changelog: [internal]
calling super invalidates eventEmitter. EventEmitter should be invalidated before reseting contentOffset on `_scrollView. Otherwise, UIScrollView::setContentOffset is called and it calls delegate method: `scrollViewDidScroll`.
Reviewed By: javache
Differential Revision: D55375060
fbshipit-source-id: f697805eb1ca05d15cf498ff9e5e06e90eb7ac56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43538
The Hermes RuntimeConfig for bridgeless accidentally force-disabled ES6Proxy, resulting in https://github.com/facebook/react-native/issues/43523
Let's remove the incorrect override.
To test using RNTester, add the following change:
```
diff --git a/packages/rn-tester/js/RNTesterAppShared.js b/packages/rn-tester/js/RNTesterAppShared.js
index 87cb6b69dfe..f2512d09c5a 100644
--- a/packages/rn-tester/js/RNTesterAppShared.js
+++ b/packages/rn-tester/js/RNTesterAppShared.js
@@ -50,6 +50,8 @@ const RNTesterApp = ({
);
const colorScheme = useColorScheme();
+ new Proxy({}, {});
+
const {
activeModuleKey,
activeModuleTitle,
```
Before this change, RNTester will get an error at start-up. After, the app loads correctly.
Changelog: [General][Fixed] Correctly keep ES6Proxy for bridgeless mode
Reviewed By: cortinico
Differential Revision: D55045780
fbshipit-source-id: 666b99712d35622f87d42f22a4611851df67d905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43251
Integrates the modern CDP backend with `CatalystInstanceImpl` (the React Native instance implementation) on Android.
This complete the modern CDP integration for Bridge.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D51458010
fbshipit-source-id: 6f73868da9d0d4cc5d086a4569c78444cb1b83ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43657
This include is not correct and is breaking the OSS build
Changelog:
[Internal] [Changed] - Fix header import inside ReactInstanceManagerInspectorTarget.h
Reviewed By: rshest
Differential Revision: D55368321
fbshipit-source-id: 0530257ad5c548476beb882174d73842775b3726
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43646
PerformanceEntryReporter maintains a buffer of RawPerformanceEntry objects,
as well as a set of _pointers_ to elements within that buffer, used to find
entries by name.
However, those pointers aren't stable: BoundedConsumableBuffer internally uses
a vector, and there are a few cases where existing references get invalidated:
- When the vector's capacity changes (as new entries get inserted) [1]
- After calling clear-with-predicate, which copies elements into a new vector
This causes nameLookup to contain dangling pointers, and subsequent operations
on it can result in use-after-free.
Fix this by having BoundedConsumableBuffer reserve space for maxSize entries
up front (which ensures that existing pointers remain valid after adding new
elements) and by rebuilding nameLookup after clearing entries by name.
Note that reserve() causes the buffer's memory use to be higher than before in
case where the number of elements is small relative to the max size. Given the
(only) existing usage in PerformanceEntryReporter, as well as the property that
consumed elements remain in the buffer, that cost should be minor.
Changelog: [Internal]
[1] https://en.cppreference.com/w/cpp/container/vector/push_back
Reviewed By: rshest
Differential Revision: D55273403
fbshipit-source-id: c8f33203ae32685e29afa7f8e33edf1284d66e0f
Summary:
Small typo I encountered while trying to build custom C++ type converters :)
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[INTERNAL] [FIXED] Fixed a small typo in the "unsupported type" error message
Pull Request resolved: https://github.com/facebook/react-native/pull/43650
Reviewed By: zeyap
Differential Revision: D55364068
Pulled By: cortinico
fbshipit-source-id: 5a1bc9443c82f2473860f379c9ae063cd6e3ceb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43655
## Changelog:
[Internal] -
The corresponding prop `ScrollBar.persistentScrollIndicator` was only passed to the Android platform code an `ScrollBar.horizontal` wasn't passed to native at all.
On other platforms we need those props to be available on the C++ side, so this exposes them to the corresponding C++ ScrollViewProps.
Reviewed By: sammy-SC
Differential Revision: D55367445
fbshipit-source-id: e8abca3a2b56a8e7c03593a6c4297f90749ac8fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43652
This improves the signature of our existing DOM APIs in 2 ways:
1. It replaces the use of `tuples` in `DOM.{h,cpp}` with safer structs.
2. It removes some unnecessary optionals from the API, returning the default values from the C++ API directly when appropriate.
It still preserves the use of tuples in the native module because objects are not properly supported in the codegen.
Changelog: [internal]
Reviewed By: NickGerleman
Differential Revision: D55316654
fbshipit-source-id: 16ce5ef62ca427cdcd6b9757d77db040e0ccc8b1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43626
The things that create ReactApplicationContext should instead create BridgeReactContext.
Long-term, ReactApplicationContext will be abstract. This diff pulls noise out from that eventual diff.
Changelog: [Internal]
Reviewed By: arushikesarwani94
Differential Revision: D55218591
fbshipit-source-id: d359c794f3da4a1ecb2fa8edbed5eeeb620b137b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43627
Eventaully, ReactApplicationContext.initailizeWithInstance() will be moved to BridgeReactContext.
Doing the migration up-front to remove noise from the eventual diff.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55218593
fbshipit-source-id: c542c44cf8b36b9dc2a01db2bf6173639fb8698a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43624
Eventually, we will move all bridge methods to BridgeReactContext.
Long-term, ReactApplicationContext and ReactContext will become abstract. And these two contexts will only contain methods common to both modes.
Changelog: [Android][Added] Introduce BridgeReactContext
Reviewed By: cortinico
Differential Revision: D55218592
fbshipit-source-id: 731d4940d492a1ed3f855c9a181d2a6f9eeb9623
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43250
Integrates the modern CDP backend with `ReactInstanceManager` on Android.
`ReactInstanceManager` is equivalent to the CDP page / `HostTarget` concept, therefore we register the `addPage`/`removePage` calls with this object's lifecycle.
Implementation notes:
- `ReactInstanceManagerInspectorTarget` is created to avoid converting `ReactInstanceManager` to JNI (impacting tests).
- Its constructor receives a `TargetDelegate` object, so that we avoid passing the entire `ReactInstanceManager` class through (avoids cyclic dependency from `com.facebook.react.bridge` to `com.facebook.react`).
Changelog:
[Internal] - Register `ReactInstanceManager` with modern CDP backend
Reviewed By: motiz88
Differential Revision: D51456960
fbshipit-source-id: 942255bb2487fdc581eb4fa0903c8e68106f8b35
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43615
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241233
fbshipit-source-id: f7541f28277307be9b3a5f4f780c7eca1a467c57
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43614
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241232
fbshipit-source-id: 933521ed1483c149f693988ca17f4c53565dbfe0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43612
This class is used for a one-time setup of bindings into the jsi::Runtime. The lambda will retain ownership of any java components required, and we can rely on the teardown of the JS runtime to clean up any dependencies.
Changelog: [Internal]
Reviewed By: dmytrorykun
Differential Revision: D55241234
fbshipit-source-id: ee80ca0f91ebe95f8c44874b27912b260f70b572
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43618
Both common and Android implementations of AsyncEventBeat use weak_ptrs
to determine if the object is still valid before invoking the callback.
Move the write to `isBeatCallbackScheduled_` down so it's protected by
that same check.
Changelog: [Internal]
Reviewed By: javache, NickGerleman
Differential Revision: D55226529
fbshipit-source-id: 9e2a34369346d11dcea69d120dfa5935320f9ba1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43639
Currently, the `react-native/dev-middleware` inspector proxy intercepts `Debugger.scriptParsed` notifications from the target and replaces `sourceMapURL` with a data uri, via an async fetch from Metro. During this async fetch, other notifications from the debugger may pass through the proxy, which results in the frontend receiving them before `Debugger.scriptParsed`.
This reordering causes problems in breakpoint resolution and pausing, because `Debugger.breakpointResolved` and `Debugger.paused` events may reference `scriptId`s unknown to the frontend while the corresponding `Debugger.scriptParsed` is delayed.
In particular, breakpoint UI state and backend state can fall out of sync, and breakpoints hit may open to the incorrect source location.
This diff modifies the proxy to use a simple per-target promise queue to ensure messages are handled in the order they were received from the target.
Changelog:
[General][Fixed] Fix breakpoints opening to incorrect location or disappearing from debugger frontend UI.
Reviewed By: motiz88
Differential Revision: D55200617
fbshipit-source-id: 27c95f822266875ed668d0bf8a525da49554cafd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43642
Changelog: [internal]
This change broke some apps at Meta. Reverting until we figure out a safe way to land this.
Reviewed By: rshest
Differential Revision: D55324557
fbshipit-source-id: 684d3dc3780fc41e2e91f367d97fa5cd392e6638
Summary:
Now that RN is providing TS type information, many of those .d.ts files depend on types from react. In modern packagemanagers (Ex: pnpm) types/react will not be available to RN since it does not declare it as a dependency.
I also noticed that the types for react-native-popup-menu-android appear to be pointing to the wrong location.
Add types/react as a peerDependency on the packages that have .d.ts files that import from React.
Add types/react to peerDependencyMeta with optional:true to prevent users not using TS from requiring types/react.
## Changelog:
[GENERAL] [ADDED] Added types/react as an optional peerDependency
Pull Request resolved: https://github.com/facebook/react-native/pull/43509
Reviewed By: cortinico
Differential Revision: D55225940
Pulled By: NickGerleman
fbshipit-source-id: 4cbab071928cb925baec45f55461559acc9a54e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43578
Changelog: [internal]
We have a feature to do some validation of the mount operations when committing new trees in Fabric. That's very slow but it was ok before because we were only doing this in debug mode and in the JS thread. We're moving some of this work to the UI thread instead and we're seeing an impact on scroll performance.
This disables this feature by default but leaves it in code to enable it when necessary for debugging.
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D55138795
fbshipit-source-id: 45ca47ae2562cecb070691bf33d95c9108a9eca3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43580
Changelog: [internal]
This introduces a new feature flag to commit state updates synchronously from the UI thread (generally) instead of dispatching them to the JS thread to be processed there. We can do this now because we introduced a UI consistency mechanism in D55024832 to JS would see a consistent revision during the execution of a specific task.
Reviewed By: sammy-SC
Differential Revision: D55083029
fbshipit-source-id: 8aa84ddaee383f098252fa679cfb07012ba29bf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43579
Changelog: [internal]
This updates all the legacy layout APIs in React Native to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
Reviewed By: sammy-SC
Differential Revision: D55077309
fbshipit-source-id: f6ff2a4f6cd1a2040f0cfeffb1e68f4ec0240f91
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43577
Changelog: [Internal]
This updates all the DOM APIs in React Native (defined in the `NativeDOM` native module) to make use of the UI consistency mechanism introduced in Fabric (if available, otherwise the behavior is the same we have now — we consume the latest version of the tree available).
As part of that work, this creates a new `DOMMethods` class that implements all methods using purely C++ APIs (not JSI), moves a lot of logic that was specific for this functionality from `UIManager` to `DOMMethods` and modifies `NativeDOM` to use this new class.
This should make it easier to add unit tests for `DOMMethods` in the future.
Reviewed By: NickGerleman
Differential Revision: D55077311
fbshipit-source-id: f96bf5f3a97236fd24dbd2315256de4ce979e151
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43581
Changelog: [internal]
This implements a mechanism to ensure that JavaScript tasks have a consistent view of the state of the UI during their execution.
## Context
Fabric allows committing new revisions of the ShadowTree from any thread, but we don't make use of this capability and instead always commit them from the JS thread (e.g.: when we schedule Fabric state updates to update the offset of a list on scroll). This was done to make sure that JS work didn't see changes in the state of the tree at random points during its execution. E.g.:
```
useEffect(() => {
const rect = ref.current.getBoundingClientRect();
// do something
const newRect = ref.current.getBoundingClientRect();
// `rect` and `newRect` should always be the same
}, []);
```
This isn't used by Reanimated at the moment, which means JS can inadvertently see the result of animations in non-specific times during execution.
You can find additional context about this in the [RFC for DOM Traversal & Layout APIs in RN](https://github.com/react-native-community/discussions-and-proposals/blob/main/proposals/0607-dom-traversal-and-layout-apis.md#consistency-and-updates).
This works correctly at the moment, but we introduce a limitation in the execution model to prevent updating the tree synchronously from the main thread. One of the main problems this introduces is that computing intersections (for `IntersectionObserver`) relies on the information in the shadow tree, but this is updated asynchronously on scroll.
There are 2 potential solutions for that problem:
1) Send the timestamp of the scroll even with the state update to backdate the timestamps of the intersections. This could work but introduces more complexity and possibly accuracy problems due to batching those state updates with other changes (e.g.: what happens if we update the state and commit another tree in the same task? should we use the backdated timestamp or wait for mount?).
2) (**Preferred**/ this diff) Allow committing new revisions from any thread, but lock the JS thread into seeing a specific revision, which would only update/progress in specific moments when it's safe. Some of those moments would be:
1) When we start a new JS task.
2) When we commit a new tree from React (JS).
## Changes
This implements the solution outlined in 2), creating a few abstractions to handle what's the current tree that should be visible to JS and to lock/unlock it in specific moments.
More specifically:
* Creates `ShadowTreeRevisionProvider` as an abstract class for APIs consuming the visible revision of the ShadowTree (mainly DOM APIs and layout methods like `measure`, etc.).
* Creates `ShadowTreeRevisionConsistencyManager` as an abstract class to handle what trees are visible (with a `lockRevision` and `unlockRevision` to be called from `RuntimeScheduler` at the beginning and end of each JS task).
* Creates 2 different implementations of these abstractions:
* One that preserves the current behavior (`LatestShadowTreeRevisionProvider`, which just returns the last committed revision at the time of the call).
* One that locks revisions lazily (the first time they're accessed) (`LazyShadowTreeRevisionConsistencyManager`).
Reviewed By: sammy-SC
Differential Revision: D55024832
fbshipit-source-id: b59985bc83714ae7ec915baba72bf92b3d6fa140
Summary:
I found in 0.74.0-rc.x, `ccache_enabled` is introduced. However, it is not being delivered via npm.
fixes https://github.com/facebook/react-native/issues/43633
Changelog: [iOS] [Fixed] - Adding ccache_clang wrapper scripts to package.json for distribution
Pull Request resolved: https://github.com/facebook/react-native/pull/43634
Reviewed By: cortinico
Differential Revision: D55308743
Pulled By: blakef
fbshipit-source-id: e89a4bb3a1fbf8562d880b4c9d25dc9083717ba6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43611
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
In this class, we didn't seem to need this reference anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D55240490
fbshipit-source-id: 9ba6f5b4b958cb273ad1923332b7b29a75630aea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43613
Storing a global_ref to `jThis` in a JNI hybrid object leads to a reference cycle which cannot be cleaned up by Java GC. The Java object will keep the C++ object alive and vice versa.
We can replace the reference in this class by using the this pointer passed in when `installJSIBindings` is invoked.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D55241235
fbshipit-source-id: 64883752a87f363a52a9f6661d6ddaa24a56fe62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43604
Changelog: [Internal]
Syncs the internal and OSS versions of `INTERNAL_CALLSITES_REGEX` in the default RN Metro config.
Reviewed By: robhogan
Differential Revision: D55237394
fbshipit-source-id: 8986a69f8beeafccbab3548d8a2137c0bf19e0b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43605
Changelog: [Internal]
Leverages https://developer.chrome.com/docs/devtools/x-google-ignore-list to mark more internal files as "third party", thus collapsing them by default in stack traces in modern versions of Chrome DevTools. The list of modules to collapse is the same one used by LogBox.
This likely only affects Meta usage, since Metro's default for [`isThirdPartyModule`](https://metrobundler.dev/docs/configuration/#isthirdpartymodule) already excludes all `node_modules`, but I'm making this change across Meta and OSS for consistency and to signal intent.
Reviewed By: huntie
Differential Revision: D55236653
fbshipit-source-id: d777ea31fb3d65608a487247924885c887ebbd94
Summary:
local-cli seems to have not been used, so we request to delete it
## Changelog:
[INTERNAL] [REMOVED] - Delete useless local-cli dir
Pull Request resolved: https://github.com/facebook/react-native/pull/43602
Reviewed By: cortinico
Differential Revision: D55281532
Pulled By: blakef
fbshipit-source-id: 8109222dbf643f1b1c3de491b4f42c07d09d8e13
Summary:
Changelog: [Internal]
fix for part of https://github.com/facebook/react-native/issues/43204
RCTBridge+Private is transitively bringing in boost in 0.74, which is causing build errors for some libs that were originally depending on it. this is because boost is a special pod that needs separate handling to link correctly.
let's simplify this problem by decoupling this header and moving the inspector specific logic into it's own category.
Reviewed By: motiz88, dmytrorykun
Differential Revision: D55228474
fbshipit-source-id: 28dacaf464b98fe1c164418934ab8101b47d7efb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43606
changelog: [internal]
D54805494 broke CircleCI because it didn't list all of the required dependencies in CMakeList.txt
Reviewed By: cortinico
Differential Revision: D55240313
fbshipit-source-id: 7a27b1379831582556ddd72007f17cbd2d507b19
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43609
When users are building from source for React Native they don't have an ndkVersion variable specified. So we want to fallback to the global NDK version we set for the whole build here.
Changelog:
[Android] [Fixed] - Fix build from source for hermes-engine
Reviewed By: dmytrorykun
Differential Revision: D55240603
fbshipit-source-id: 3c725a164b40e176548af8ada9fcb13d391ef017
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43607
PR #43526 was accidentally merged with several changes excluded. I'm following up on those here.
Changelog:
[Internal] [Changed] - Follow-up with Review Feedback on RCTAppDelegate from #43526
Reviewed By: dmytrorykun
Differential Revision: D55240435
fbshipit-source-id: c296a1e14b7032b211551334ca7b5a6824e8d45c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43592
changelog: [internal]
Exposing experimental API EventEmitter::experimental_flushSync to trigger synchronous event from native. The API will be changed in the future, this is exposed only for experimentation.
Reviewed By: javache
Differential Revision: D54805494
fbshipit-source-id: fb395588cf1dc944a920ec4a2257390552850263
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43594
I've been migrating `react-native-view-shot` to Fabric by using the `InteropUiBlockListener`
and I've realized that the interop layer doesn't work well.
1. FabricUIManager needs to implement `UIBlockViewResolver` in order for the interop layer to work correctly.
2. We need to hook `addUIBlock` to the `didDispatchMountItems` callback otherwise the UIBlocks won't be executed at all.
Changelog:
[Android] [Fixed] - Fix InteropUIBlockListener to support react-native-view-shot on Bridgeless
Reviewed By: javache
Differential Revision: D55187939
fbshipit-source-id: d048b4b5eed77fa856fdfac17c0df5f23fd44844
Summary:
This PR adds missing forwarding blocks to RCTRootViewFactory, currently when a user tries to override `sourceURLForBridge` in AppDelegate it isn't overridden.
## Changelog:
[IOS] [FIXED] - add missing forward blocks to RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/43526
Test Plan: Override: `extraModulesForBridge`, `extraLazyModuleClassesForBridge`, `bridge didNotFindModule`, `sourceURLForBridge:` methods in AppDelegate and check if they are called on old architecture
Reviewed By: philIip
Differential Revision: D55186872
Pulled By: cortinico
fbshipit-source-id: 5988c7bab1439ccc4885b7337336c1e120ba9ea6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43583
Fail during `pod install` if user's version of XCode is too old to avoid cryptic errors (e.g. https://github.com/reactwg/react-native-releases/issues/163).
I reused existing mechanism for version detection, though it may not be reliable for future versions of XCode.
Changelog:
[iOS][Changed] - Warn users during "pod install" if XCode is too old
Reviewed By: dmytrorykun
Differential Revision: D55149636
fbshipit-source-id: 78387ff19a6eb10f3ca0d4aa78e6b934ae3b0711
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
- `rrc_textinput` at the moment points to a wrong subdirectory and needlessly adds a prefix path
- `rrc_text` is missing headers for `attributedstring` which it depends on
## Changelog:
[ANDROID] [FIXED] - Fixed prefab header paths for `rrc_text` and `rrc_textinput`
Pull Request resolved: https://github.com/facebook/react-native/pull/43591
Reviewed By: fkgozali
Differential Revision: D55199580
Pulled By: cortinico
fbshipit-source-id: 85126c00943f82e908a52e05587661597761852e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43574
Changelog: [Internal]
Once we start rolling out the Fusebox backend, users might still try to use the debugger frontends they're used to, for which we can't guarantee reliability. Let's detect this and log a message letting them know about the supported Fusebox launch flows.
Reviewed By: huntie
Differential Revision: D55122115
fbshipit-source-id: a17c0c6b9140059f489e0852fe673306fb6ef8f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43575
Changelog: [Internal]
Adds the `HostAgent::sendConsoleMessage` and `InstanceAgent::sendConsoleMessage` helper methods, allowing the agent implementations to send simple, text-only console messages (using `Runtime.consoleAPICalled`) from the inspector thread, without involving the Runtime (and the JS thread).
We also update the tests to ignore such messages by default, since otherwise we would encounter a lot of unexpected mock calls.
## Context
We currently use `Log.entryAdded` messages for logs generated by the CDP backend itself. This cleanly separates backend-generated messages from app-generated `Runtime.consoleAPICalled` messages (including in tests), and avoids the need to provide an `executionContextId` for protocol compliance.
However, it turns out that frontends don't consistently support the `Log` domain - in particular, `chrome://inspect` doesn't show `Log` messages for targets of type `node` (which is how RN lists itself in the `/json` endpoint). For the majority of our `Log.entryAdded` use cases, this doesn't matter. But it does mean that if we want a log message to be visible regardless of the frontend, we need to send `Runtime.consoleAPICalled` messages instead.
The one concrete use case for this at the moment is detecting non-Fusebox clients and logging an explanatory message to point users to Fusebox. We can likely refactor most *existing* uses of `Log.entryAdded` in our code to use `sendConsoleMessage`, but I've opted not to do that here. Those are primarily useful within our team and can be deleted once Fusebox is out of testing.
Reviewed By: huntie
Differential Revision: D55130368
fbshipit-source-id: 4bc6a91efe63db6753250a3d383fd497c9f5f7b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43532
changelog: [internal]
- use designated initializers.
- make ScrollViewMetrics a struct.
- move ScrollViewMetrics inside of ScrollViewEventEmitter.
This is to be more consistent with other event emitters.
Reviewed By: rubennorte
Differential Revision: D54896331
fbshipit-source-id: 01aecd1835b23bdaccff1355d33eb7b4c5ba8d92
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43589
Changelog: [Internal]
Adds a way of enabling the Fusebox backend in React Native regardless of the corresponding feature flags. This is only supported in the Buck build and not intended for use in OSS.
Reviewed By: huntie
Differential Revision: D55144502
fbshipit-source-id: 116cd30464acfbd3fafc503300f94cb238adeda8
Summary:
Changelog: [internal]
This moves all the new methods that were added to implement the DOM traversal and layout APIs (as per this RFC: https://github.com/react-native-community/discussions-and-proposals/pull/607) to a separate C++ native module to avoid bloating the UIManager interface, initialize lazily, provide automatic caching of methods, simplify the API for implementors, etc.
Pull Request resolved: https://github.com/facebook/react-native/pull/43512
Reviewed By: sammy-SC
Differential Revision: D54903376
fbshipit-source-id: 69daa84c886d1c65dbb0b223dbb7c9077502c6ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43568
Fixes to restore passing CI checks on main after D55027120.
- Widen validation checks in version utils to accept `0.x.x` (as opposed to `0.[not-'0'].x`).
- Use `tag: test` instead of `tag: latest` for dry run job params.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55123739
fbshipit-source-id: 9f76dced4e7aa3ce87d6680cd7687ae443305331
Summary:
Changelog: [Internal] Remove console logs from Metro when native Fusebox debugger console is available
React Native currently sends all `console.log` messages to Metro, which prints them to the terminal. This feature has been in place since 2019 (D15559151) but is pretty limited when compared to what's available in modern browsers. Most of the limitations can't really be fixed within the constraints of Metro's relatively simple terminal infrastructure.
With the new React Native debugger (codenamed "Fusebox") we aim to fundamentally elevate the debugging experience by shipping a well-tested version of Chrome DevTools with React Native. Chrome DevTools has a rich, interactive console, as well as a host of other debugging features we want developers to notice and use.
To that end, we plan to **strongly nudge users towards the Fusebox console from day 1**. Specifically, if we detect that Fusebox is available and is using an engine which implements CDP `console` support ( = Hermes only for now), we'll no longer send logs to Metro, and will instead display an explanatory message directing users to Fusebox.
Reviewed By: huntie
Differential Revision: D54829811
fbshipit-source-id: 2b1cdb666094f901ff4e7f42b123271be4ce7d10
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43565
Changelog: [Internal]
Uses https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/24 to identify the Fusebox frontend and show a corresponding message in the logs.
Also tweaks the wording and formatting of other messages logged by the Fusebox backend - including removing the "you are using the modern CDP backend" one.
Reviewed By: huntie
Differential Revision: D55075645
fbshipit-source-id: c82670570c79b61efd399f26684139ce97f017ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43537
This file always had a bunch of errors and made it so that actual errors do not show up (too many emitted). It was just because we are not including RawProps.h. I am not sure how it ever got compiled but I guess some header included something that included something etc. Maybe its a vs code issue but this seems like an obvious fix
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D55041883
fbshipit-source-id: 3445770dd25dbe294024649f96f9e3af7777b2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43554
changelog: [internal]
The prop endDraggingSensitivityVelocityMultiplier makes the API more complicated and provides only limited benefit. Let's remove it for the sake of simplicity.
Reviewed By: christophpurrer
Differential Revision: D53853298
fbshipit-source-id: d2663f2f6eef1dde3136debe8965ee871f4e043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43534
This is no longer used after switching to the new release workflow, which uses the newer and less error-prone `set-version` script.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027122
fbshipit-source-id: faa8cfd2af9b54fab611b108df162793c5768695
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43533
Switch to the new unified release workflow by default, now that this has been validated on the `0.74-stable` branch.
- Remove `--use-new-workflow` flag and remove legacy logic.
- Remove legacy `prepare_package_for_release` CI job, and use `run_new_release_workflow` -> `run_release_workflow` as new workflow condition match.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55027120
fbshipit-source-id: 7c05cdff95ac369ce6cd1201ccfc5718798c4da6
Summary:
Updated linters, include typings in `package.json` and removed bun from the clean commands.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54493859
fbshipit-source-id: eb28d208de722c90916b14f56d5a8e847bb3d859
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43530
Fixes and changes following D54956345, encountered during the release process for 0.74 RC4 today.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D55017872
fbshipit-source-id: 616b387088db00c6f076f4571b4ab1541467361c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43520
Refactor ReactDelegate to have a private `getDevSupportManager()` that can also be re-used by `reload()`
This method conditionally provides the correct DevSupportManager in cases of Bridge & Bridgeless
Changelog:
[Internal] internal
Reviewed By: cortinico
Differential Revision: D54967130
fbshipit-source-id: 37d585de33a50b98d01803d3080c5693a8c494b9
Summary:
The [Windows fix](https://github.com/cezaraugusto/chromium-edge-launcher/pull/1) was merged and published. We no longer need to use the fork.
## Changelog:
[INTERNAL] [FIXED] - Fix experimental debugger launch flow with Edge on Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/43524
Test Plan: n/a
Reviewed By: robhogan
Differential Revision: D55013623
Pulled By: motiz88
fbshipit-source-id: bff2aa2801dd0dcdd6975dca0a2ec2aa9864ff6f
Summary:
Minor fix to package.json which newer version of npm warn about when publishing, after running `npm pkg fix -ws` on the workspace.
{F1470070110}
## Changelog: [Internal] npm pkg fix -ws
Pull Request resolved: https://github.com/facebook/react-native/pull/43519
Test Plan: eyescloseddog
Reviewed By: cortinico
Differential Revision: D55012872
Pulled By: blakef
fbshipit-source-id: ff3c63a3eefaf56d369219a3d4b32d44d6d842c9
Summary:
This PR updates `typescript-eslint/eslint-plugin` and `typescript-eslint/parser` to `v7` and `eslint-plugin-jest` to `v27`, removing any dependencies on `typescript-eslint` `v6`, allowing projects using `react-native/eslint-config` to safely update to `typescript-eslint` `v7` without having to worry about duplicate major versions installed
## Changelog:
- [General] [Changed]: Updated `eslint-plugin-jest` to `v27`
- [General] [Changed]: Updated `typescript-eslint` monorepo to `v7`
Pull Request resolved: https://github.com/facebook/react-native/pull/43406
Test Plan: `yarn run lint` executed locally successfully
Reviewed By: robhogan
Differential Revision: D54749676
Pulled By: tdn120
fbshipit-source-id: f6fae92fc95333e28b36a3d2bd8470c8869d38bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43385
`rncore` and `FBReactNativeComponentSpec` contain the same symbols, which leads to conflicts when we try to merge them into a single shared library. Cleanup the duplication and standardize on `FBReactNativeComponentSpec` everywhere. I've left the Android OSS targets as is, to avoid breaking deps.
Changelog: [Internal]
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54630694
fbshipit-source-id: 75cb961ded9fd75508755c0530e29409fef801cf
Summary:
### Context
- Since RN 0.73, in the jest.setup file, methods of the Image module (Image.getSize, Image.resolveAssetSource...) are mocked on the **JS side** (introduced in https://github.com/facebook/react-native/pull/36996)
- It causes issues like https://github.com/facebook/react-native/issues/41907 : `Image.resolveAssetSource` returns nothing in test env with the new JS mock, when some test relies on it.
- On my project, it broke the snapshots : the URL of images disappeared. I use `react-native-fast-image` which uses `Image.resolveAssetSource` to compute URLs.
- I first opened a PR to fix exclusively Image.resolveAssetSource: https://github.com/facebook/react-native/pull/41957. I will close it to focus on this new one.
- As suggested by ryancat and idrissakhi, it should be better to return to the previous mock, where no method is mocked on the JS side, and we can trust the actual JS to work in test.
This is what this PR intends to do.
### Content
Along fixing the Image module mock in jest.setup, this PR :
- adds unit test on each one of the methods, ensuring they have a consistent behavior even when the module is mocked.
- adds 3 missing native mocks for `NativeImageLoader`: `prefetchImageWithMetadata`, `getSizeWithHeaders` & `queryCache`. After this PR, no method from NativeImageLoader remains unmocked.
## Changelog:
[GENERAL][FIXED] - fix jest setup for Image methods (resolveAssetSource, getSize, prefetch, queryCache)
Pull Request resolved: https://github.com/facebook/react-native/pull/43497
Test Plan:
See exhaustive unit tests in PR.
You can re-use the mock with all the methods mocked and see how the new unit tests fail.
I also patched those changes on my project: my snapshot did have their URL back (see demonstrative screenshots in my original PR: https://github.com/facebook/react-native/pull/41957 - NB; fixed mock was different but result was the same -> those screenshots cover only two cases, but anyway they illustrate well the case!)
Reviewed By: ryancat
Differential Revision: D54959063
Pulled By: tdn120
fbshipit-source-id: 837266bd6991eb8292d9f6af1774e897ac7a8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43504
Changelog: [internal]
We identified the issue in the experiments already, so we can remove this flag.
Reviewed By: sammy-SC
Differential Revision: D54945099
fbshipit-source-id: 4d547569eb3bbfd011f5d6894d87bfa542cac07b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43503
Changelog: [internal]
## Context
In the experiments to enable mount hooks on Android we saw some crashes that we couldn't reproduce or pinpoint accurately.
We ran another experiment excluding part of the code in one of the variants, and we found that the problem was in this block (only crashes when `skipMountHookNotifications` is false):
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp#L726-L734
Looking more closely at the mounting coordinator code, I realized that some of the methods are not thread-safe, which is likely causing these issues.
~~We're probably only seeing these issues on Android because we have a push model there (we call `pullTransaction` from whatever thread we're committing to, JS thread or Fabric background thread) whereas in the rest of platforms we have a pull model and we always access call `pullTransaction` from the main thread, as we do to report mounts.~~
This is probably fine because both cases are protected by a mutex when accessing through `ShadowTreeRegistry::visit`. But there's a case that doesn't go through it that could be causing the issues: prerendering:
https://github.com/facebook/react-native/blob/121b26184acbb77ff4f2360647cb322ff560b145/packages/react-native/ReactCommon/react/renderer/scheduler/SurfaceHandler.cpp#L289
## Changes
1) Make `getBaseRevision` return a copy of the revision rather than a reference.
2) Make all methods that access `baseRevision_` and `lastRevision_` thread-safe.
Reviewed By: javache
Differential Revision: D54945100
fbshipit-source-id: d8b211137d0eac02a5814cc6c376c22733290eab
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43507
Changelog: [General][Changed] - sync React renderers to 18.3.0-canary-9372c6311-20240315
Syncs React renderers to https://github.com/facebook/react/commit/9372c63116fc1e855c51d93d83f5150661371ec3 which is canary for 18.3.0-canary-9372c6311-20240315.
This includes the necessary changes to enable the use of microtasks for scheduling in Fabric.
Reviewed By: yungsters
Differential Revision: D54947212
fbshipit-source-id: 8fd5def5107d77e6a248f653a9d0260b392fab6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43518
This is a minimum approach to achieve a **single-command publish flow** for React Native, unifying the previous `yarn bump-all-updated-packages` and `yarn trigger-react-native-release` workflow entry points.
This diff aims to change as little as possible to achieve the above — introducing a new job that merges operations to create the versioning commit. The triggered publish jobs are unchanged. In future, we may follow this change with further simplifications down the workflow tree.
**Key changes**
- Adds a new CircleCI workflow, `prepare_release_new`, which versions **all packages** and writes a single release commit.
- This replaces `yarn bump-all-updated-packages`, now implemented with the newer `set-version` script.
- Wires this up as an experiment within `trigger-react-native-release.js`, conditionally running the new workflow when `--use-new-workflow` is passed.
**Not changed**
- The single release commit written will continue to trigger both of the existing CI workflows on push (`publish_release` and `publish_bumped_packages`), which are unchanged.
- The commit summary now includes the `#publish-packages-to-npm` marker, in order to trigger `publish_bumped_packages`.
- Usage: Release Crew members will continue to use the existing local script entry point (as [documented in the releases repo](https://github.com/reactwg/react-native-releases/blob/main/docs/guide-release-process.md#step-7-publish-react-native)), with the opt in flag.
```
yarn trigger-react-native-release --use-new-workflow [...args]
```
After we're happy with the E2E behaviour of this workflow in the next 0.74 RC, I will follow up by dropping the `--use-new-workflow` flag and removing the old scripts (T182533699).
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956345
fbshipit-source-id: 35fd7af8f3e60a39507b5d978ccd97472bf03ddb
Summary:
This is causing Twilight Android app to hang and crash on start
Original commit changeset: 3f24271405f6
Original Phabricator Diff: D54905564
Reviewed By: sammy-SC
Differential Revision: D54960053
fbshipit-source-id: 5c1063f11ae1314e71288905eb6d8da32ddbfadd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43516
As titled. This seems dangerous — removing with the motivation that we'd prefer this script to fail during execution than to succeed in publishing `9999`.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54956661
fbshipit-source-id: 23f8d49abd300385dde74871b6d2492ef63f058e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43513
The previous `update_podfile_lock.sh` script would fail as executed from the repo root (could not locate RNTester dir). Delete this and replace with direct calls in `prepare-package-for-release.js`, which will fail script on error.
{F1469216632}
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D54949214
fbshipit-source-id: 4f032069e803e84f835c279d01332d16787dfafc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43511
Changelog: [Internal]
This is an attempt to fix [#39783](https://github.com/facebook/react-native/issues/39783).
It seems that when `configureBuildForHermes` runs (as part of `yarn android` in `rn-tester`) cmake may not be available and is not installed automatically:
* for 3p, even after installing the latest Android Studio, cmake 3.22.1 is not available by default but needs to be installed manually
* for Meta employees, same story when looking at the `ANDROID_HOME` set by the `setup_fb4a.sh` in the `.zshrc` file:
```
# added by setup_fb4a.sh
export ANDROID_SDK=/opt/android_sdk
export ANDROID_NDK_REPOSITORY=/opt/android_ndk
export ANDROID_HOME=${ANDROID_SDK}
export PATH=${PATH}:${ANDROID_SDK}/emulator:${ANDROID_SDK}/tools:${ANDROID_SDK}/tools/bin:${ANDROID_SDK}/platform-tools
```
This diff introduces an explicit task to install cmake.
### ALTERNATIVE 1
See D54897379.
### ALTERNATIVE 2
Suggested by cortinico:
> Create a mini module called :packages:react-native:ReactAndroid:hermes-engine:cmake-downloader which just triggers an empty cmake build via Android SDK
Reviewed By: cortinico
Differential Revision: D54859484
fbshipit-source-id: f9ecdf78ff408947b1e85e7da4f112c89d3a8c89
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43506
Changelog: [internal]
We've been making all the built-in C++ TurboModules in RN extend `enable_shared_from_this` because we copied from the same template that needed it, but none of them do. This removes that unnecessary extension.
Reviewed By: sammy-SC
Differential Revision: D54901332
fbshipit-source-id: 795c7696e70041d640399e3b9f177999e22fd90b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43470
Changelog: [internal]
This moves the native code for the Web Performance API to `ReactCommon`, to align with the other default C++ native modules we've defined there.
Reviewed By: sammy-SC
Differential Revision: D54860194
fbshipit-source-id: 32dccb080fb8ebd1e2acbdd59fa2dfe47e372c17
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43482
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Now that we are confident that `CDPAgent` is stable, switch to it by default and remove the previous integration.
- Drop `inspectorEnableHermesCDPAgent` feature flag.
- Rename and replace `HermesRuntimeAgentDelegateNew` as `HermesRuntimeAgentDelegate`.
- Drop "Hermes integration: CDPAgent" log message.
- Update tests.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54897841
fbshipit-source-id: 8a5212d27f21c54112c0820a2a3611e05d606880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43493
This is a bump of one of our external GH custom action
Closes#38046
Changelog:
[Internal] [Changed] - Bump needs-attention to v2.0.0
Reviewed By: GijsWeterings
Differential Revision: D54905530
fbshipit-source-id: 1ecc25926144641bfc080b4ca7b8551a00a0caa1
Summary:
Changelog: [Internal]
TSIA - useful for the `console` test suite I'm currently writing (D54846940) which would be awkward to fit into `JsiIntegrationTest.cpp`.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54846938
fbshipit-source-id: 9e20bfae7c518b3822da468adf484e51cdc4d0b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43459
Changelog: [General][Changed] - Console polyfill now copies all properties from the existing `console` object
Fusebox now exposes a full WHATWG `console` object integrated directly with CDP debugging (D54826073). Some WHATWG `console` methods are missing from React Native's polyfill/shim, so let's pass those through unmodified so they can still be called.
(Long term, we shouldn't need most of `console.js`, but let's get there gradually as there are many RN users still depending on `nativeLoggingHook` etc.)
NOTE: We also update the "bundled" copy of `console.js` that lives in the jsinspector-modern C++ test suite.
Reviewed By: huntie
Differential Revision: D54827902
fbshipit-source-id: c6c9128903496810192614f4f8d80b68b02e25c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43495
## Changelog:
[Internal] -
Fixes build regression of RNTester on OSS, coming from D54764898.
NOTE: This is only Android bit for now, looking into the iOS one.
Reviewed By: cortinico
Differential Revision: D54908736
fbshipit-source-id: 70081d1378a56dd0df3f76322377f5a0e6615f80
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43461
Adds a regression test for the duplicate `scriptParsed` bug in Hermes (T182003727). In the process, we enable Hermes lazy compilation in all our CDPAgent JSI integration tests.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54852326
fbshipit-source-id: 52e23458d3e9e21902c3659fc944ef85c68731ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43496
This diff adds another sub-sub-spec to React-Fabric pod to fix import paths in `textinput`.
Changelog: [Internal]
Reviewed By: philIip, rshest
Differential Revision: D54918454
fbshipit-source-id: 3949f8b8b201157f4c9eb256f3eb5bd5d66bc228
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43438
changelog: [internal]
EventQueue can now be merged with BatchedEventQueue since there isn't anything else subclassing it.
Reviewed By: javache
Differential Revision: D54687859
fbshipit-source-id: f646583db0e46789b667f8d79d24d0cf9d7fc00c
Summary:
Changelog: [Internal]
We are currently eagerly constructing a `HermesRuntimeTargetDelegate` regardless of whether the Fusebox feature flags are enabled. This can interfere with the legacy CDP backend. Instead, let's lazily construct the target delegate in a code path that only runs when the modern backend is in use.
bypass-github-export-checks
Reviewed By: rozele
Differential Revision: D54907887
fbshipit-source-id: 7dc13506739866ea6690ed21d03d91ad24ef68c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43487
Inconsistent between bridge and bridgeless, but if you forget to implement this interface, ReactDelegate will silently not do anything in bridgeless.
Changelog: [Android] Enforce Activities using ReactDelegate implement DefaultHardwareBackBtnHandler.
Reviewed By: arushikesarwani94
Differential Revision: D54900747
fbshipit-source-id: 5dd31d4f81e4ec37e1c3ee906be836a8a9c6a944
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43491
This diff brings back the `UNSET` constant to `TextAttributeProps`.
The removal of this constant was an unnecessary breaking change, that has broken several third-party libraries.
Changelog: [Android][Fixed] - Bring back the UNSET constant to TextAttributeProps.
Reviewed By: fabriziocucci
Differential Revision: D54899524
fbshipit-source-id: 368bde77d43f310fd458537d0191d09174fa5167
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43456
Changelog: [Internal]
Implements the [WHATWG `console` spec](https://console.spec.whatwg.org/) directly in `RuntimeTarget`, based on the Hermes-powered `addConsoleMessage` method first used in D54494298.
Benefits:
* This allows the console API to work independently of the polyfill shipped in RN, including very early during JS execution.
* It also opens the door to better stack traces (once we start reporting those) and richer functionality in the `console` object itself.
Reviewed By: robhogan
Differential Revision: D54826073
fbshipit-source-id: d5b0bd004bf35c2fce91742ae84ea86225ec1c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43486
We use `CopyOnWriteArrayList` in other places across the React Native codebase, as it assumes that reading happens more frequently than updating. This saves us from needing to synchronize and copy when we access the list of listeners.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54806272
fbshipit-source-id: d1b54d532edb2af3391a7e4fdc758f705621227d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43478
This is rolled out internally already. Also exposing `memoryPressureRouter` to match the ReactInstanceManager interface.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54802021
fbshipit-source-id: b74dcde71296d3925acfc2171d2a77d90960e15e
Summary:
Changelog: [Internal]
Adds a regression test for a Hermes CDPAgent bug using `JsiIntegrationTest`. See details in comments.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54890188
fbshipit-source-id: 325a32b83b145d2d35f99feaef9988028f15f196
Summary:
I was recently working on an [issue](https://github.com/software-mansion/react-native-reanimated/issues/5715) in Reanimated where z-index of some views was broken after a Layout Animation was used. The issue was that in some cases we were calling the `removeView` function on a already removed view. On plain Android this wouldn't be an issue, since the `removeView` function ignores such calls. Unfortunately, the `ReactViewGroup.java` implementation maintains a counter of views with user defined z-index. This counter is decremented whenever a call to `removeView` is made, even if the view is not a child of this `ViewGroup`. This PR adds an additional check in the `handleRemoveView` function to unify the `removeView` behavior between Android and react-native.
## Changelog:
[ANDROID] [CHANGED] - Changed the `handleRemoveView` function in `ReactViewGroup.java` to ignore calls for `Views` that are not children of this `ViewGroup`
Pull Request resolved: https://github.com/facebook/react-native/pull/43389
Test Plan: I tested if the `rn-tester` app behaves correctly after those changes.
Reviewed By: NickGerleman
Differential Revision: D54874780
Pulled By: javache
fbshipit-source-id: f1a34947419ef6106ee73b196ae99b7f8c2f7a77
Summary:
Implements the RFC which progressively provides warnings to users of the `npx react-native init` command as we gradually deprecate.
Changelog:
[General][Deprecated] - init cli deprecation logging
Reviewed By: cortinico
Differential Revision: D54423109
fbshipit-source-id: 679b6672bdbfc42a9b82a2aad38fd3253c6ea6a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43357
This diff adds a class to get the needed RenderEffects to support CSS filters on Android. This diff does not add any of the plumbing for it to actually work, that comes in the next diff, but I figured this was complicated and isolated enough to be on its own.
Note that I did not add blur or drop shadow as those are a bit more involved and I plan on adding them later.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D54603892
fbshipit-source-id: 5780d7c846fdb1116e29e0a940ee02da609b01f5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43453
The forward declaration for RCTMountingManager doesn't appear to be used anywhere. It can be deleted.
## Changelog
[Internal]
Reviewed By: NickGerleman
Differential Revision: D54692764
fbshipit-source-id: ba8206408fdd515387a0a6aff6a3e43c51221e57
Summary:
When users create a new app, there is an option: Follow us on Twitter with the description. Twitter is X now.

## Changelog: [Internal]
Replace the Twitter link, title, and description with X.
Pull Request resolved: https://github.com/facebook/react-native/pull/43423
Test Plan: Set the environment for React Native app and then `npx react-native@latest init AwesomeProject`, `npm start`, and `npm run ios`
Reviewed By: cortinico
Differential Revision: D54850199
Pulled By: huntie
fbshipit-source-id: 424cb9212962d78a5b2d93d973f56498ba948136
Summary:
Changelog: [Internal]
Use our build script for packages and to generate the TypeScript types.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54428870
fbshipit-source-id: 2a1666d30ac472300979b2be078a906d390e919a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43460
Currently pressing the menu button (or CMD+M) is broken on Bridgeless mode.
Also pressing RR is not reloading the App.
That's because some Bridgeless API haven't been reimplemented correctly on Android. I'm fixing them here.
Fixes#43451
Changelog:
[Android] [Fixed] - Properly handle RR and CMD+M in Bridgeless Mode
Reviewed By: huntie
Differential Revision: D54852959
fbshipit-source-id: 8fbbdab6818da9177e6db40e45d35258c7f5e236
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43458
The React sync in D54783723 was failing because some tests were relying on `console.error` being called as `console.error('Some message')` but it was refactored as `console.error('%s..', 'Some message')`, making them fail.
This fixes the tests by formatting the arguments passed to the console functions and checking against that instead.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D54849485
fbshipit-source-id: 0648263614725ea3f9c95b9f9bb13005adae46eb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43431
## Changelog:
[Internal] -
This takes all the common props for TextInput between Android and iOS and factors them out into a single, platform independent props data structure, `BaseTextInputProps`.
This way it's both easier to manage the corresponding props, but also making this easier to be used on other platforms.
Reviewed By: sammy-SC
Differential Revision: D54764898
fbshipit-source-id: 224b01c5a67ba5d5216cd5c482bf650a1c2453d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43441
`RuntimeScheduler::getIsSynchronous` is currently used to check if the current task is being executed on the main thread, to avoid using the background executor. This was part of a test to dispatch events synchronously in an app using background executor.
We're not running that test anymore and this method doesn't make a lot of sense in the first place (it's not checking if the current task is running on the main thread, only if the caller of the task scheduled it synchronously from whatever thread they called from), so we can remove the method.
If this is necessary in the future we should create a method that actually does something useful (like `isCurrentTaskOnMainThread()`).
Changelog: [internal]
I consider this change not to be a breaking change because runtime scheduler wasn't an official public API, and what we want to make public doesn't include this method.
Reviewed By: sammy-SC
Differential Revision: D54804805
fbshipit-source-id: 54b3a6586e08bccc201df848b942fb1fcae29f30
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43446
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Following D54712525, add a test case that validates `"Debugger.enable"` is persisted between reloads. This has been actioned by creating a further test group, `ModernHermesVariants`, and scoping the existing `ResolveBreakpointAfterReload` to this, with the removed second `"Debugger.enable"` message.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54808212
fbshipit-source-id: 0775beb85a0907cca4dccbc77ec461d9515ab078
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43448
## Changelog:
[Internal] -
This adds a stub for `TextLayoutManager.measureCachedSpannableById`, as well as a missing explicit dependency to `jni/react/jni` from the `TextInput` implementation on the Android platform.
This is required in order for certain build configurations to compile.
Reviewed By: andrewdacenko
Differential Revision: D54807518
fbshipit-source-id: 206f0edb03a4ed328a962e57d1e791614eb7f851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43450
Changelog: [Internal]
This is just to make sure that all instances of `LongLivedObjectCollection` map can be safely accessed by multiple threads.
Reviewed By: RSNara
Differential Revision: D54801015
fbshipit-source-id: e0b15bfbeac9ce3a1051f83a59c5513a90ba2a4b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43392
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Wires up `previouslyExportedState` with `CDPAgent`, and re-enables the `ResolveBreakpointAfterReload` integration test.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54369985
fbshipit-source-id: 5dcb4fe59b8b36b2db9f0385e8487097822e5704
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43437
## Changelog:
[iOS][Removed] - remove EventPriority class and always use the default EventPriority::AsynchronousBatched. This is potentially a breaking change if something in OSS sets a different priority. If a build fails because of this, simply remove the use of EventPriority.
EventPriority::AsynchronousBatched is the default and none of the other priorities are used anymore. This is the first step of removing this concept from the codebase.
Reviewed By: NickGerleman
Differential Revision: D54684311
fbshipit-source-id: 18240e5ee84f489f43b15fd9aab43f3b1b1b4963
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:
X-link: https://github.com/facebook/yoga/pull/1593
Pull Request resolved: https://github.com/facebook/react-native/pull/43417
There was a bug where we did not position absolute nodes correctly if the static node had a different main/cross axis from the containing node. This fixes that. The change is somewhat complicated unfortunately but I tried to add sufficient comments to explain what is happening
Reviewed By: NickGerleman
Differential Revision: D54703955
fbshipit-source-id: 096c643f61d4f9bb3ee6278d675ebd69b57350d7
Summary:
## Changelog:
[General][Fixed] - Fix broken native animation in Paper
In Native Animated Paper, `scheduleUpdate` must not be called. In Fabric, the synchronisation between Fiber and Shadow trees is a must but in Paper it sets undesired state.
Reviewed By: javache
Differential Revision: D54799237
fbshipit-source-id: f6b07dc377111ed2f8253ea0c7c7e312168166e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43444
Re-enable a test now that D54649943 added correct handling of stale execution context IDs.
NOTE: There's a minor difference in returned error code. The test now allows either, though note that the old implementation is more consistent with Chrome itself which returns -32000 (server error). Semantically -32600 (invalid request) seems more appropriate.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54805777
fbshipit-source-id: eb2baadf6b35319f5331462425eaa38b4edfab28
Summary:
This is a proposal for the `react-native/dev-middleware` package, to allow implementers to extend the CDP capabilities of the `InspectorProxy`. It's unfortunately needed until we can move to the native Hermes CDP layer.
At Expo, we extend the CDP capabilities of this `InspectorProxy` by injecting functionality on the device level. This proposed API does the same, but without having to overwrite internal functions of both the `InspectorProxy` and `InspectorDevice`.
A good example of this is the network inspector's capabilities. This currently works through the inspection proxy, and roughly like:
- Handle any incoming `Expo(Network.receivedResponseBody)` from the _**device**_, store it, and stop event from propagating
- Handle the incoming `Network.getResponseBody` from the _**debugger**_, return the data, and stop event from propagating.
This API brings back that capability in a more structured way.
## API:
```ts
import { createDevMiddleware } from 'react-native/dev-middleware';
const { middleware, websocketEndpoints } = createDevMiddleware({
unstable_customInspectorMessageHandler: ({ page, deviceInfo, debuggerInfo }) => {
// Do not enable handler for page other than "SOMETHING", or for vscode debugging
// Can also include `page.capabilities` to determine if handler is required
if (page.title !== 'SOMETHING' || debuggerInfo.userAgent?.includes('vscode')) {
return null;
}
return {
handleDeviceMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
handleDebuggerMessage(message) {
if (message.type === 'CDP_MESSAGE') {
// Do something and stop message from propagating with return `true`
return true;
}
},
};
},
});
```
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [ADDED] - Add inspector proxy device message middleware API
Pull Request resolved: https://github.com/facebook/react-native/pull/43291
Test Plan: See added tests and code above
Reviewed By: huntie
Differential Revision: D54804503
Pulled By: motiz88
fbshipit-source-id: ae918dcd5b7e76d3fb31db4c84717567ae60fa96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43397
Changelog: [internal]
This migrates the Hermes-specific use of microtasks to an engine agnostic implementation based on the new JSI method to queue microtasks.
Reviewed By: sammy-SC
Differential Revision: D54687056
fbshipit-source-id: b077ba47b80f7b31c77b7e449def8a56061b0b69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43395
Changelog: [internal]
This moves native module specs to `specs` directory to align with the general convention.
Reviewed By: cortinico
Differential Revision: D54680056
fbshipit-source-id: 8b6ae6187e2ffa9120159b7d1fa25957677e0f4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43394
Changelog: [internal]
When we built the new feature flag system we added a constraint in the JS API to prevent calling `override` if any of the flags was already accessed from JS.
This is very restrictive because it doesn't allow us to access common flags (like `enableMicrotasks`) set up from native during the initialization of the framework because then applications wouldn't be able to set JS-only overrides.
This relaxes the constraint to disallow accessing JS-only flags before setting JS-only overrides, but accessing common (native) flags before that is ok.
Reviewed By: rshest
Differential Revision: D54687055
fbshipit-source-id: b0716f24baf7d12a5e4a61fba79e6b50ef0ad10a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43393
Changelog: [internal]
The generator doesn't create intermediate directories, which is causing issues now that we're moving the generated native module spec to a new directory.
This fixes that.
Reviewed By: rshest
Differential Revision: D54690126
fbshipit-source-id: 1ba0d821872da7bbe1f6120ef6d0c1f800326778
Summary:
At Expo, we use [Expo Tools](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts) to connect the [built-in vscode-js-debug](https://github.com/microsoft/vscode-js-debug) to Hermes.
Since there are a few differences in vscode vs chrome devtools, we need to enable a couple of modifications through the [`customMessageHandler` API](https://github.com/facebook/react-native/pull/43291). Unfortunately, vscode itself doesn't set the `user-agent` header when connecting to the inspector proxy. Becuase of that, we'd need a fallback to "manually" mark the debugger as being vscode ([we use this query parameter here](https://github.com/expo/vscode-expo/blob/main/src/expoDebuggers.ts#L208)).
This PR supports setting the `user-agent` through `?userAgent=` when the header is not set.
## 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
-->
[GENERAL] [ADDED] - Fallback to query parameter based `user-agent` when header is unset
Pull Request resolved: https://github.com/facebook/react-native/pull/43364
Test Plan:
- Install [Expo Tools](https://marketplace.visualstudio.com/items?itemName=expo.vscode-expo-tools)
- Start Metro with this change.
- Connect a device.
- Run the vscode command `"Expo: Debug Expo app ..."`
- Debugger should connect, and have it's user-agent marked as:
`vscode/1.87.0 vscode-expo-tools/1.3.0`
Reviewed By: huntie
Differential Revision: D54804556
Pulled By: motiz88
fbshipit-source-id: 1ff558ba5350811ad042d08a713438e046759feb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43408
Changelog: [internal]
I think mount operations are taking longer than expected because of a debugging block (that we might remove). This adds some systrace sections to distinguish that from the overall time and confirm this only happens in debug builds.
Reviewed By: sammy-SC
Differential Revision: D54746491
fbshipit-source-id: 317b22b6dcd1ae117ed4a013180df8842bf712f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43436
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Expands test coverage for the Hermes `CDPAgent` implementation by enabling in `ReactInstanceIntegrationTest`.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: motiz88
Differential Revision: D54801168
fbshipit-source-id: 9b71f8e697c7ab24c1383100938b3f648774a106
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43429
changelog: [internal]
these experimental props have served their purpose and can be deleted.
Reviewed By: rubennorte
Differential Revision: D54682805
fbshipit-source-id: aee5072e2aa056c862f369426617d0d51c98997f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43422
After my changes in D54496604, this test now requires the main looper to progress as well, to dispatch the right callback.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D54776392
fbshipit-source-id: ba272a08d4b88d1c3301618eed1a03253e615b84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43314
Changelog: [Internal]
making call invoker a breaking change to runtime executor in 0.74 seems to be causing a lot of discourse. let's simplify things and first add the callinvoker to the backwards compat layer
Reviewed By: cipolleschi
Differential Revision: D54404845
fbshipit-source-id: 983e86829030557033b95625dab9068492739417
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43410
Changelog:
[General] [Breaking] - Make `LongLivedObjectCollection::get` accept a Runtime reference as parameter.
# Context
Approach 1 as described in [RFC post](https://fb.workplace.com/groups/615693552291894/permalink/1693347124526526/).
# This diff
* Replace the `LongLivedObjectCollection` singleton with a map from `Runtime -> LongLivedObjectCollection` so that each RN instance has its own collection.
* Update MSFT fork accordingly
Reviewed By: javache, RSNara
Differential Revision: D54649209
fbshipit-source-id: ecd2ab3917843ca82388b7b9cce06c05679f2d60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43420
Calling `mReactDelegate.createRootView` just ends up calling the overridden method in the anonymous inner class. Instead have the base implementation return null, and call super.
Changelog: [Internal]
Reviewed By: jessebwr, janeli-100005636499545
Differential Revision: D54772205
fbshipit-source-id: fc90e6718f9c287e8b86e5768cf7f74d0db06c49
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43391
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Bootstraps `HermesRuntimeAgentDelegateNew` within `JsiIntegrationTest.cpp`.
Test cases which currently do not pass with `HermesRuntimeAgentDelegateNew` are selectively matched against a new alias to exclude them: `JsiIntegrationHermesLegacyTest`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53810357
fbshipit-source-id: 2d7d7446038530d19d93add71361b4bf581cff18
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43405
X-link: https://github.com/facebook/yoga/pull/1592
Fixes https://github.com/facebook/yoga/issues/1590
Yoga may be built with a high warning level. This is helpful in letting Yoga be used in more places, and finding defects. We currently set these in the internal BUCK build, the CMake reference build, and the Yoga Standalone (not RN) CocoaPods build.
Yoga's reference CMake build and spec are consumed today by users of Yoga, instead of just Yoga developers. Here, it makes more sense to avoid anything that could break compiler-to-compiler compatibility.
We default these to a less intense (`-Wall -Werror`). I kept `/W4`, for pragmatic reasons, and since it is relatively standard for MSVC.
We continue to build with strict flags on Buck build on Clang.
Reviewed By: cortinico
Differential Revision: D54735661
fbshipit-source-id: 130e35ac9dcffa2f7e70e48d18770f1275864e2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43166
# Overview
This diff adds support for symbolicating component stacks that provide the new stack frame formatting. It currently switches between a `componentStackType` value to enable stack frame parsing, but once the feature flag lands we can clean this up so that the type of `ComponentStack` is always just `Array<StackFrame>`
## Screen
### With stack frame component stacks
{F1459181398}
## Legacy version
{F1463451637}
Changelog:
[General][Fixed] - Support component stacks without source info.
Reviewed By: yungsters
Differential Revision: D53984570
fbshipit-source-id: 68afbe70b65c7a8861d049bebe0659dbe1db146f
Summary:
## 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
-->
Changelog: [Internal] Generated changelog
Pull Request resolved: https://github.com/facebook/react-native/pull/43412
Reviewed By: cortinico
Differential Revision: D54753626
Pulled By: huntie
fbshipit-source-id: c0a2348601b3d78b08ccaab570f346716d3793e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43348
Changelog: [Internal]
Followup from D54585658. Moves the branching on `HERMES_DEBUGGER_ENABLED` into `HermesRuntimeTargetDelegate`, and correspondingly makes `FallbackRuntimeAgentDelegate` private (not exposed directly to integrators).
Reviewed By: huntie
Differential Revision: D54587558
fbshipit-source-id: 554b41356c1421a508c1a788d7c27f53445ecb6b
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/43346
Changelog: [Internal]
(Continuing the theme of reducing integration boilerplate from D54537844.)
This diff changes both `JSExecutor` (Bridge) and `JSRuntime` (Bridgeless) to no longer implement `RuntimeTargetDelegate`. Instead, each of them exposes a `getRuntimeTargetDelegate()` method that returns a stable reference to a target delegate that it *owns*.
To facilitate this, we create a new `FallbackRuntimeTargetDelegate` for use in non-Hermes cases. This replaces *almost* all direct uses of `FallbackRuntimeAgentDelegate` outside of `jsinspector`. I'll follow up in a separate diff to deal with the last case and make the fallback agent delegate fully private.
As a result, changing the `RuntimeTargetDelegate` interface (which we'll need to do for console support) becomes much easier: we only have unit test mocks + two concrete `RuntimeTargetDelegate` implementations (one fallback, one Hermes) to update for each API change.
Reviewed By: huntie
Differential Revision: D54585658
fbshipit-source-id: 08b61c74008ddc36c2b134a40755ef8e43ab21ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43390
Refactor after D54639775. This avoids the unfortunate side effect where `InspectorFlags::dangerouslyResetFlags()` would immediately reread `ReactNativeFeatureFlags `. This call is now relocated in our test util.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54684692
fbshipit-source-id: 962c7d78bbf71b1d81af412081d3ef5cfe443fa1
Summary:
The inspector proxy is inlining source maps on `Debugger.scriptParsed` CDP events. The inlining prevents Chrome DevTools from downloading this remotely, as that's not supported in newer versions anymore.
The current implementation locks this inlining mechanism to just `localhost` and/or `127.0.0.1` addresses, making it incompatible with LAN or tunnel device connections.
This PR removes that limitation to allow source map inlining on these LAN and tunnel connections.
## 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
-->
[GENERAL][FIXED] Allow Inspector proxy to inline source maps on LAN connections
Pull Request resolved: https://github.com/facebook/react-native/pull/43307
Test Plan:
- See added test
- Start Metro and connect a device over LAN, open the chrome devtools
Reviewed By: huntie
Differential Revision: D54485247
Pulled By: robhogan
fbshipit-source-id: 6fcb0c6dd762d2f0a013497ba0a1126095b9130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43384
Changelog: [Internal]
via `js1 upgrade react-devtools -v ^5.0.2`
5.0.1 and 5.0.2 mostly include fixes, biggest change is the way how we find source location of the element and the symbolication.
Backend from `react-devtools-core` 5.0.2 is required for symbolication.
allow-large-files
Reviewed By: huntie
Differential Revision: D54679238
fbshipit-source-id: 13656b2d9bad106246c019e1627b87ffbc2735fe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43376
## Changelog:
[Internal] -
Make it possible to call `emitDeviceEvent` from C++ TurboModules without the need to explicitly provide the reference to `jsi::Runtime`, as in some contexts (when we call e.g. not from the JS thread itself) it may be hard to get hold of.
Reviewed By: rubennorte
Differential Revision: D54643903
fbshipit-source-id: 25cea413e66c6e76c958395879db1169899e3bc9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43375
## Changelog:
[Internal] -
As discussed with the team, it makes more sense to pass the reference to the correct `jsi::Runtime` object as an argument to the ` CallInvoker::invoke*` callbacks, that are provided by the user.
There are various use cases when user would like to get a hold of the `jsi::Runtime` in the callback, and it makes sense, since it is guaranteed to run on the JS thread.
So far people have been coming up with all kinds of workarounds for that, none of them safe enough.
Reviewed By: rubennorte
Differential Revision: D54643171
fbshipit-source-id: 2f6015426a9e29cb9fcf5a9a3e2f6f33ff692538
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43386
Changes:
- fixes `RCTAttributedTextUtils` to set `RCTAttributedStringIsHighlightedAttributeName` attribute according to `isHighlighted` textAttribute value.
- adds block to `drawAttributedString` and passed highlighted bezier curve to it.
- updates `drawRect` to visually highlight selected text.
## Changelog:
[iOS][Fixed] - Fixed text highlighting in the New Architecture
Reviewed By: sammy-SC
Differential Revision: D54594472
fbshipit-source-id: ed454e3a1660fa76d96cb131e33fba1c05f47776
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43378
## Overview
I noticed while running this test, that there's an existing `console.error` to remove a file from the `FILES_WITH_KNOWN_ERRORS` list, but the tests pass despite the error. This happens because the `console.error` throws to fail the test, but this `console.error` is inside a try/catch, so the error is swallowed.
This diff moves the check to a finally, which fails the test.
I also fixed the `FILES_WITH_KNOWN_ERRORS` list.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D54587062
fbshipit-source-id: c46e98326ef6654452871337364d7e66ff204e2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43353
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Integrates `HermesRuntimeAgentDelegateNew` (using the new Hermes `CDPAgent` setup) into `HermesRuntimeTargetDelegate` behind a new feature flag, `inspectorEnableHermesCDPAgent`. This completes the initial integration for all platforms.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54586162
fbshipit-source-id: 5f26c28af4414d961b1c8c9cb4cd7135bd00b410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43352
## Context
We are migrating to the new Hermes `CDPAgent` and `CDPDebugAPI` APIs in the modern CDP server (previously `HermesCDPHandler`).
## This diff
Adds the `HermesRuntimeAgentDelegateNew` class to provide a swap-in replacement for the existing `HermesRuntimeAgentDelegate` when we enable this via an incoming feature flag.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53810356
fbshipit-source-id: c63684252230a747ecf0bd8cbb6f4e22052ed9bf
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/43374
changelog: [internal]
when animation that uses native driver finishes, it must synchronise the end state with shadow tree.
`onUpdateRef` for native animated is only called when the animation finishes.
Reviewed By: javache, yungsters
Differential Revision: D54582987
fbshipit-source-id: 4320ed172b8bb4b22f82c6e24b47f88f1603e4fb
Summary:
The `react_render_textlayoutmanager` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `react_render_textlayoutmanager` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43381
Reviewed By: javache
Differential Revision: D54676207
Pulled By: cortinico
fbshipit-source-id: 90e3b90ff842250bf1e3abcc0c54f057b68a82fd
Summary:
`registerCallableModule()` was added from 7f549ec7be but no typescript types there. this pr tries to add the corresponding types.
## Changelog:
[GENERAL] [FIXED] - Add missing `registerCallableModule` TypeScript definitions
Pull Request resolved: https://github.com/facebook/react-native/pull/43366
Test Plan: patch locally and try to `import { registerCallableModule } from 'react-native';` in a 0.74.0-rc.2 project
Reviewed By: fabriziocucci
Differential Revision: D54676151
Pulled By: cortinico
fbshipit-source-id: cd01f2ebe2d2516b458fae5b2e83cba3d3794455
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43377
Fixes `VirtualizedList-test.js`, which assumes fake timers (e.g. using `jest.runAllTimers()` and `jest.runOnlyPendingTimers()`) but did not actually use fake timers.
Changelog:
[Internal]
Reviewed By: yungsters
Differential Revision: D54668281
fbshipit-source-id: b14757744bb7a21a4e5573053549c36178826021
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43371
This file has a lot of regexes, let's organize and comment them all.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D54638520
fbshipit-source-id: eed61133758ccefd2a640f121c4da214bcad4880
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43370
Component stacks with files ending in .ts, .tsx, or .jsx were skipped in LogBox reporting. This diff fixes the regex.
Changelog:
[General][Fixed] - Support .tsx, .ts, and .jsx in component stacks
Reviewed By: yungsters
Differential Revision: D54638526
fbshipit-source-id: a5271daaa7b687e8e075be3f94ab9b9c03f79b66
Summary:
Currently, the ability to convert JS values to `UIModalPresentationStyle` is not present directly on `RCTConvert`.
In the RN code base itself, there's not a lot of need to do this type of conversion, but in community modules, presenting ViewControllers can be a fairly common scenario and it'd be nice to be able to use this conversion directly from `RCTConvert`, rather than from `RCTModalHostViewManager`, as it'd improve its "discoverability" and consistency.
If someone relied on this, then it's technically speaking a breaking change but I'd say it's for the better, and searching `#import <React/RCTModalHostViewManager.h>` on github doesn't reveal a lot of results.
## Changelog:
[IOS] [ADDED] - RCTConvert to support UIModalPresentationStyle
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43297
Test Plan:
Tested using RN Tester
https://github.com/facebook/react-native/assets/1566403/6e62df86-dde3-47b0-b2e9-bb6b483cadf6
Reviewed By: fkgozali
Differential Revision: D54635896
Pulled By: dmytrorykun
fbshipit-source-id: c6747857830762cd0333c31c287954f3f10d4954
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43368
This diff replaces direct invocation of the `cp` command with the platform agnostic `fs.cpSync`.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54634108
fbshipit-source-id: 41fe7b44b6534026ef1b930da85725bf3eb1e7bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43356
To make it accessible across different dylib/bundle.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D54601288
fbshipit-source-id: e65b724b228a680784e81b8c51ecd3f4df3fd668
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43349
Changelog: [internal]
We still haven't found the root cause of some of the crashes we're seeing in the experiments to enable mount hooks on Android.
This adds a new feature flag to skip part of the mount hooks pipeline to see if we can scope the investigation to that specific part (where we query the root tree in the base revision from the mounting coordinator).
Reviewed By: sammy-SC
Differential Revision: D54587739
fbshipit-source-id: 792aa8b06808e96638d1bba072bf4060ec492bd2
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/43337
Changelog: [internal]
Mount instructions and listeners are only called from the UI thread, so there's no need to have synchronization mechanisms for concurrency.
We're also scheduling mount hooks notifications once, but subsequent calls are ignored instead of accumulated to be notified together. This also changes that to collect all the surface IDs in the array that is read on notification.
Reviewed By: sammy-SC
Differential Revision: D54547194
fbshipit-source-id: a861e3b0113914aae5325c1486bcf8acd50eef79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43340
Adds convenience methods `jsonResult`, `jsonError` and `jsonNotification` for more ergonomic construction of CDP JSON responses. Note that CDP is *loosely* based on [JSON-RPC 2.0](https://www.jsonrpc.org/specification), but differs for example in the omission of `"jsonrpc": "2.0"`.
Before:
```
frontendChannel_(folly::toJson(folly::dynamic::object("id", req.id)(
"error",
folly::dynamic::object("code", -32602)(
"message",
"executionContextName is mutually exclusive with executionContextId"))));
```
After:
```
frontendChannel_(cdp::jsonError(
req.id,
cdp::ErrorCode::InvalidParams,
"executionContextName is mutually exclusive with executionContextId"));
```
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D54202854
fbshipit-source-id: 76a407ae39ff9c2ec79bcaddb6cd4d494afb7693
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43281
## Overview
This diff fixes a bug in the hermes component stack location parser, and fixes the hermes component stack tests which were not using hermes stack parsing, which is why the bug wasn't caught.
The bug fix is that React component stacks may not all have stack frame locations. For example, this stack:
```
at MyComponent (/path/to/filename.js:1:2)
at MyOtherComponent <-- no location
at MyAppComponent (/path/to/app.js:100:20)
```
This can happen when we're unable to make a component throw (e.g. it doesn't use a hook or access props). We have plans to fix these frames, but currently they can exist.
The bug was when `parseHermesStack` finds a frame without an `entry`, it would reset the `entries`. But if entries is already non-null, or if the current frame is a frame without a source, we should continue.
### Caveats
The handling here fixes the behavior to go back to skipping these frames. I'm not sure what the best way to handle these cases are, since these frames do not have source location and should skip symbolication. We should follow up with handling for these frames.
## Why it wasn't caught
In D18627930 we changed the hermes component stack parsing to check `global.HermesInternal`, but the tests for the hermes component stacks were still using the `stacktrace-parser`. I updated the tests to set/reset the global, which caught the bug.
Changelog:
[General][Fixed] - Support hermes component stacks with missing source info.
Reviewed By: yungsters
Differential Revision: D54423252
fbshipit-source-id: 80ded8b99eab919e60f847369dcb1f3afa72b6be
Summary:
This PR further optimizes RCTKeyWindow() for iOS 15+ removing the need for additional loop
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - optimize RCTKeyWindow() for iOS 15+
Pull Request resolved: https://github.com/facebook/react-native/pull/43066
Test Plan: Launch RNTester, check if proper keyWindow is returned for iOS 15+
Reviewed By: javache
Differential Revision: D54541838
Pulled By: cipolleschi
fbshipit-source-id: be79ff48f825d10c8fd71efc18629377aadc29fd
Summary:
This PR fixes importing RCTAppDelegate, cleans up the imports, and properly sets the background color for bridgeless mode when using `RCTRootViewFactory`.
The issue with importing to Swift was that `RCTTurboModuleManager` has C++ in headers which caused Swift to error out.
bypass-github-export-checks
## Changelog:
[IOS] [FIXED] - Allow importing RCTAppDelegate in Swift
[INTERNAL] [REMOVED] - Remove unnecessary imports in AppDelegate
[INTERNAL] [FIXED] - Properly set background color for bridgeless
Pull Request resolved: https://github.com/facebook/react-native/pull/43339
Test Plan:
- CI Green
- Check if background color is correct
Reviewed By: dmytrorykun
Differential Revision: D54584489
Pulled By: cipolleschi
fbshipit-source-id: cb4b947ca9d0f375b1852dbf5a7d889e920562f7
Summary:
The `rrc_text` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `rrc_text` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43275
Reviewed By: cipolleschi
Differential Revision: D54536468
Pulled By: cortinico
fbshipit-source-id: 8c4ef983467bfc46930f10bf7bd95761c2d11788
Summary:
We should not be publishing the `__tests__` folder to the npm package.
Fixes https://github.com/facebook/react-native/issues/43242
## Changelog:
[INTERNAL] [CHANGED] - Do not publish src/**/__tests__ for react-native
Pull Request resolved: https://github.com/facebook/react-native/pull/43261
Test Plan: Nothing to test
Reviewed By: cipolleschi
Differential Revision: D54540896
Pulled By: cortinico
fbshipit-source-id: 10b557a911b9b17d64c4697724825248a597feae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43334
cortinico flagged that bridge + fabric regressed in 0.74, likely due to D53406841.
Changelog: [Android][Fixed] Fix registration of ViewManagers in new renderer when not using lazyViewManagers.
Reviewed By: fkgozali
Differential Revision: D54551645
fbshipit-source-id: 0783030cd0d2900a3a254ae04c9ea4e51035272a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43328
These have been deprecated since 2019 (D18742620), probably time we remove them.
Changelog: [General][Removed] Removed deprecated methods from Pressability.
Reviewed By: NickGerleman
Differential Revision: D54535029
fbshipit-source-id: 45f85fb002824c94363c839fee2f831c01ad4dbd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43332
Changelog: [Internal]
The Hermes debugger integrations in Bridge/Bridgeless have so far used `MessageQueueThread` directly to schedule work on the JS thread, instead of the Instance-managed executor.
This was always a smell, but is now actively unsafe since the modern CDP backend requires `JSExecutor` / `JSRuntime` to remain alive while work is ongoing on the JS thread. This is not guaranteed when using `MessageQueueThread` directly like we do now, but *is* guaranteed by the Instance-managed `RuntimeExecutor` (see reasoning in D54493456).
We already have access to that executor in `RuntimeTarget`, so here we ensure that it's the one used by the AgentDelegate too and eliminate the direct use of `MessageQueueThread`.
NOTE: It would have been, perhaps, nice to just house the executor inside `JSExecutor` / `JSRuntime` to begin with, instead of adding a parameter to `createAgentDelegate()`. This would require some broader refactoring which I'm choosing to avoid for now.
Reviewed By: huntie
Differential Revision: D54539429
fbshipit-source-id: 6a5ad1c56642d809f6193b230301fa268318bbce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43326
Changelog: [Internal]
Extracts the common parts of `HermesJSRuntime` (Bridgeless) and `HermesExecutor` (Bridge) that pertain to integration with the modern CDP backend into a new `HermesRuntimeTargetDelegate` class. This also makes the `HermesRuntimeAgentDelegate` class fully private.
As a followup, we *might* want to change `JSRuntime` and `JSExecutor` so they don't *implement* `RuntimeTargetDelegate` but are required to expose a `RuntimeTargetDelegate& getRuntimeTargetDelegate()` method instead. That would remove some of the boilerplate required for our current "aggregation" approach.
Reviewed By: huntie
Differential Revision: D54537844
fbshipit-source-id: f8c51fda0dbf28add1daeb95c991a34670f6854f
Summary:
Changelog: [Internal]
Use a gtest assertion to avoid running into an exception (which has worse diagnostics) when dereferencing an `optional` value that's expected to be non-empty.
bypass-github-export-checks
Reviewed By: huntie
Differential Revision: D54578843
fbshipit-source-id: e0269542f80045f02876bda06cb584b6c68e50cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43329
Improve maintainability of this file, in particular reducing the probability of a merge conflict for new entries.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D54539469
fbshipit-source-id: dc2fca42b4490d87c532b21043b0855d8d1a894d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43195
Right now, the activity indicator is automatically hidden when the view is ready to be shown in bridgeless mode.
There is no way to prevent that the activity indicator is automatically removed.
In OSS, we have libraries (e.g.: `react-native-bootsplash`) that will allow the app to control when and how dismiss the splashscreen, but due to the current automatic behavior on Bridgeless, they stopped working.
***Note:** In the previous implementation, they were working because instead of using the `loadingView` property, they were adding the splashscreen view on top of the existing one. However, with the lazy behavior of the bridgeless mode, this is not working anymore because the RCTMountingManager [expect not to have any subview](https://www.internalfb.com/code/fbsource/[6962fa457dbc74ab3a760cf6090d9643c6748781]/xplat/js/react-native-github/packages/react-native/React/Fabric/Mounting/RCTMountingManager.mm?lines=176) when the first surface is mounted.*
## Changelog
[iOS][Added] - Allow the activityIndicator to be controlled from JS in bridgeless mode
Reviewed By: philIip
Differential Revision: D54191856
fbshipit-source-id: 14738032f04adf7eaf7d200d889acd752aed0ed3
Summary:
Commit https://github.com/facebook/react-native/commit/73664f576aaa472d5c8fb2a02e0ddd017bbb2ea4 broke two jobs in CircleCI that we run using Xcode 14.3.1 because the commit introduced some types that are available only to iOS 17.
The code was wrapped around if(available()) statement, but this does not compile out the code. It is a runtime check and the code needs to build anyway.
This takes effect at compile time as well. However, unlike with #available, the method must type check and compile. The code will always be emitted into your binary: however, it will only be used when the binary is executed on platforms that meet the availability requirements.
source: [forums.swift.org/t/if-vs-available-vs-if-available/40266/2](https://forums.swift.org/t/if-vs-available-vs-if-available/40266/2)
This change should fix it, introducing some compile time pragmas that removes the code if we build with older versions of Xcode
## Changelog:
[IOS] [ADDED] - Compiler conditionals for hover style (cursor: pointer)
Pull Request resolved: https://github.com/facebook/react-native/pull/43331
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D54540520
Pulled By: cipolleschi
fbshipit-source-id: 943ac479062e11969efa7645ec0ead26c6866374
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43327
<!-- Thanks for submitting a pull request! We appreciate you spending the time to work on these changes. Please provide enough information so that others can review your pull request. The three fields below are mandatory. -->
## Summary
Swift Pods require the use of [modular headers](https://blog.cocoapods.org/CocoaPods-1.5.0/) to be statically linked. To interop with Objective-C modules, you need to make the Objective-C module "define a Module", that is modular header export.
This is already the case for a few podspecs so they can be consumed in Swift libraries, but `ReactCommon` and `RCT-Folly` don't do this yet and therefore this breaks in a few libraries of mine, for example see this issue: https://github.com/mrousavy/react-native-vision-camera/issues/195.
If I were to include `ReactCommon` or `RCT-Folly` in my Swift library's podspec, the following error arises:
```
[!] The following Swift pods cannot yet be integrated as static libraries:
The Swift pod `VisionCamera` depends upon `RCT-Folly`, which does not define modules.
To opt into those targets generating module maps (which is necessary to import them from Swift
when building as static libraries), you may set `use_modular_headers!` globally in your Podfile, or
specify `:modular_headers => true` for particular dependencies.
```
So this PR fixes this issue by allowing Swift libraries to consume the `ReactCommon` and `RCT-Folly` podspecs since they now export modular headers.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Fixed] - Expose Modular Headers for `ReactCommon` podspec
[General] [Fixed] - Expose Modular Headers for `RCT-Folly` podspec
Pull Request resolved: https://github.com/facebook/react-native/pull/31858
Test Plan: * Add s.dependency "ReactCommon" or RCT-Folly to a Swift pod and see what happens. (See https://github.com/mrousavy/react-native-vision-camera/pull/273)
Reviewed By: dmytrorykun
Differential Revision: D54539127
Pulled By: cipolleschi
fbshipit-source-id: 2291cc0c8d6675521b220b02ef0c3c6a3e73be38
Summary:
Bump the version to match RN.
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D54538812
fbshipit-source-id: a2e8225ea02fb1e7a69b3b20436c821a857ca1e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43323
This fixes a seemingly pre-existent misconfiguration within our `test_ios_template` E2E test setup in CircleCI.
**Background**
We call `npx react-native-community/cli init` with the `--skip-install` flag, as part of the bootstrapping logic in `scripts/e2e/init-template-e2e.js`. This is necessary because we later want to explicitly call `npm install` with a custom `--registry` for our locally mirrored packages (via Verdaccio).
For some reason, we were observing unexpected differences when this was run under CircleCI:
1. Runs `yarn init`
2. Runs a `yarn add` (unknown pkg)
{F1464781818}
https://app.circleci.com/pipelines/github/facebook/react-native/42725/workflows/f648468b-e916-4501-887d-ad293aa6fccf/jobs/1398950
This is causing a Yarn-based install ahead of where we want — ignoring the `--skip-install` flag.
*I'm still unsure on the exact LOC cause in CLI* (but most likely, it's around the Yarn v3 move).
**Impact of this fix**
- The above meant that, when we were bootstrapping `test_ios_template` previously, packages weren't being read from Verdaccio, but **instead from npm** — using the `"0.74.0"` versions from the *previous branch cut* ❌.
- After D54006327, this behaviour became breaking 💀 — since for the 0.74 -> 0.75 cut, we no longer physically published `"0.75.0-main"` (new format) packages to npm.
**This change**
I'm passing `--pm npm` to `npx react-native-community/cli init` to skip around any Yarn behaviour. This appears to have removed the erroneous `yarn` invocations ✅.
Changelog: [Internal]
bypass-github-export-checks
Reviewed By: cortinico, cipolleschi
Differential Revision: D54536848
fbshipit-source-id: 473b11924955f5787c82a6c81d4527d77b810aa5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43309
Changelog: [internal]
X-link: https://github.com/facebook/hermes/pull/1336
Add JSI test verifying the behavior of `queueMicrotask` and `drainMicrotasks` in the runtimes that support them.
Reviewed By: neildhar
Differential Revision: D54484771
fbshipit-source-id: e8c0c8e05215d59a0a8c86161452642c41bcdbd7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43311
X-link: https://github.com/facebook/hermes/pull/1337
Changelog: [internal]
We've done this in a separate diff because the changes in Hermes don't propagate immediately to the React Native repository. We need to land the changes in JSI and Hermes first (in a backwards-compatible way) and then land this in a separate commit to make the method mandatory.
Reviewed By: neildhar
Differential Revision: D54413830
fbshipit-source-id: 3b89fe0e6697b0019544b73daa89d932db97b63a
Summary:
This adds the `nativeNetworkInspection` target capability flag, to enable/disable the proxy-side network inspection handling.
## 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
-->
[GENERAL][ADDED] Add inspector proxy `nativeNetworkInspection` target capability flag
Pull Request resolved: https://github.com/facebook/react-native/pull/43310
Test Plan:
Once this lands, and is published through `react-native/dev-middleware`, we (Expo) can disable the proxy-side network inspection handling.
See https://github.com/expo/expo/pull/27425/commits/1a1b601a29fbc5766628238db7259121689f6cd6 on PR expo/expo#27425
Reviewed By: christophpurrer, motiz88
Differential Revision: D54486516
Pulled By: huntie
fbshipit-source-id: cc151349c816fb3866d3ec07af1a29a5f4ff9b00
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:
This PR implements `RCTRootViewFactory` a utility class (suggested by cipolleschi) that returns proper RCTRootView based on the current environment state (new arch/old arch/bridgeless). This class aims to preserve background compatibility by implementing a configuration class forwarding necessary class to RCTAppDelegate.
### Brownfield use case
This PR leverages the `RCTRootViewFactory` in `RCTAppDelegate` for the default initialization of React Native (greenfield).
Here is an example of creating a Brownfield integration (without RCTAppDelegate) using this class (can be later added to docs):
1. Store reference to `rootViewFactory` and to `UIWindow`
`AppDelegate.h`:
```objc
interface AppDelegate : UIResponder <UIApplicationDelegate>
property(nonatomic, strong) UIWindow* window;
property(nonatomic, strong) RCTRootViewFactory* rootViewFactory;
end
```
2. Create an initial configuration using `RCTRootViewFactoryConfiguration` and initialize `RCTRootViewFactory` using it. Then you can use the factory to create a new `RCTRootView` without worrying about old arch/new arch/bridgeless.
`AppDelegate.mm`
```objc
implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary<UIApplicationLaunchOptionsKey,id> *)launchOptions {
// Create configuration
RCTRootViewFactoryConfiguration *configuration = [[RCTRootViewFactoryConfiguration alloc] initWithBundleURL:self.bundleURL
newArchEnabled:self.fabricEnabled
turboModuleEnabled:self.turboModuleEnabled
bridgelessEnabled:self.bridgelessEnabled];
// Initialize RCTRootViewFactory
self.rootViewFactory = [[RCTRootViewFactory alloc] initWithConfiguration:configuration];
// Create main root view
UIView *rootView = [self.rootViewFactory viewWithModuleName:@"RNTesterApp" initialProperties:@{} launchOptions:launchOptions];
// Set main window as you prefer for your Brownfield integration.
self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];
UIViewController *rootViewController = [UIViewController new];
rootViewController.view = rootView;
self.window.rootViewController = rootViewController;
[self.window makeKeyAndVisible];
// Later in the codebase you can initialize more rootView's using rootViewFactory.
return YES;
}
end
```
bypass-github-export-checks
## Changelog:
[INTERNAL] [ADDED] - Implement RCTRootViewFactory
Pull Request resolved: https://github.com/facebook/react-native/pull/42263
Test Plan: Check if root view is properly created on app initialization
Reviewed By: dmytrorykun
Differential Revision: D53179625
Pulled By: cipolleschi
fbshipit-source-id: 9bc850965ba30d84ad3e67d91dd888f0547c2136
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43305
changelog: [internal]
Originally when I built setNativeProps, I assumed a node is either controlled by handled directly or it is controlled by React. But we can't make sure that's the case, users can do both and control one prop with setNativeProps and the others with React. Additionally, Suspense uses display: none to hide a subtree.
Therefore, React controlled props must not be copied into `ShadowNodeFamily::nativeProps_DEPRECATED`
Reviewed By: javache
Differential Revision: D54453820
fbshipit-source-id: 5b4038f0dd366621d26a92f668d33f27ce60f4b4
Summary:
Changelog: [internal]
Now that `jsi::Runtime::queueMicrotask` is available, we can use it instead of calling an internal Hermes API in `RuntimeSchedulerTest`.
Reviewed By: christophpurrer
Differential Revision: D54416245
fbshipit-source-id: c9cbd3783d9dc1c3df499a7fec7acb6c229ec571
Summary:
Changelog: [internal]
## Context
We want to enable the new React Native event loop by default for all users on the new RN architecture (on the bridgeless initialization path more concretely), which requires support for microtasks in all the JS engines that the support (Hermes already has it, JSC doesn't).
## Changes
This adds initial support for microtasks in JSC, so we can schedule and execute microtasks in this runtime.
One limitation about this approach is that, AFAIK, the public API for JSC doesn't allow us to customize its internal microtask queue or specify the method to be used by its built-in `Promise` or native `async function`, so we're forced to continue using a polyfill in that case (which uses `setImmediate` that will be mapped to `queueMicrotask`).
Reviewed By: NickGerleman
Differential Revision: D54302534
fbshipit-source-id: 47f71620344a81bc6624917f77452106ffbf55a3
Summary:
Changelog: [internal]
## Context
Microtasks are an important aspect of JavaScript and they will become increasingly important in the hosts where we're currently using JSI.
For example, React Native is going to adopt an event loop processing model similar to the one on the Web, which means it would need the ability to schedule and execute microtasks in every iteration of the loop. See https://github.com/react-native-community/discussions-and-proposals/pull/744 for details.
JSI already has a method to execute all pending microtasks (`drainMicrotasks`) but without a method to schedule microtasks this is incomplete.
We're currently testing microtasks with Hermes using an internal method to schedule microtasks (`HermesInternal.enqueueJob`) but we need a method in JSI so this also works in other runtimes like JSC and V8.
## Changes
This adds the `queueMicrotask` to the Runtime API in JSI so we have symmetric API for microtasks and we can implement the necessary functionality.
The expectation for JSI implementations is to queue microtasks from this method and from built-ins like Promises and async functions in the same queue, and not drain that queue until explicitly done via `drainMicrotasks` in JSI.
This also modifies Hermes and JSC to provide stubs for those methods, and the actual implementation will be done in following diffs.
Reviewed By: neildhar
Differential Revision: D54302536
fbshipit-source-id: 25f52f91d7ef1a51687c431d2c7562c373dc72a5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43287
Move react-native-community/cli clean into core per RFC-0759. Provides:
- android
- metro
- npm
- bun
- watchman
- yarn
- cocoapods
These tasks are used to clear up caching artefacts in React Native projects. This is going to be called by the `react-native-community/cli` once we publish these in an npm package.
Changelog:
[General][Added] RFC-0759 Move cli clean into core
Reviewed By: cipolleschi
Differential Revision: D53997878
fbshipit-source-id: 56907be714184abecc8e3ef677ffc83e9ee7b54d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43293
Was debugging this, and found that this exception was being thrown due to `DefaultBindingsInstaller`, which was an invalid hybrid object. The ReactInstance initializer fully supports this being null, so let's use that as default.
Changelog: [Android][Fixed] NullPointerException is no longer ignored in MessageQueueThreadHandler
Reviewed By: sammy-SC
Differential Revision: D54434417
fbshipit-source-id: 52417b390061eface0f0578e32796d3a85303e03
Summary:
The `rrc_textinput` was not exposed via prefab. I'm adding it to make possible for react-native-live-markdown to integrate on top of React Native via prefab. Based on https://github.com/facebook/react-native/issues/36166.
## 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
-->
[ANDROID] [CHANGED] - Expose `rrc_textinput` via prefab.
Pull Request resolved: https://github.com/facebook/react-native/pull/43274
Reviewed By: cipolleschi
Differential Revision: D54482657
Pulled By: cortinico
fbshipit-source-id: ca7f4127f1808f841d88925238666e837de75bd0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43268
We previously restricted all copies and moves of SyncCallback, but that led to unsafe calling paths being added instead to AsyncCallback. Instead, allowing moving of SyncCallback, and document the need for the caller to invoke it safely, so can we remove the unsafe path from AsyncCallback.
Changelog: [General][Changed] Allow moving SyncCallback for advanced use-cases
Reviewed By: christophpurrer
Differential Revision: D54381734
fbshipit-source-id: 5fd797cd4541e507aa68f1e4e76a1be5cae20fbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43294
These are gated by `ReactFeatureFlags.enableBridgelessArchitecture` and are missing support. They should be evaluated for backwards compatibility
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D54422143
fbshipit-source-id: b35b60f17d68d412a354b20e02fb6bbf591c40b0
Summary:
Addresses a gap when using the `set-version` script to update all packages on `main` (i.e. post branch cut):
- Package versions were not being set consistently. It is safe to version all workspace packages, including `"private"`.
- Our publishing workflow is independent from this, and only considers public packages for submission to npm.
- We also need to update the root `package.json`, which includes `devDependencies` referencing workspace dependencies.
Unblocks https://github.com/facebook/react-native/pull/43132.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D54419456
fbshipit-source-id: 93eee669c5cf7c2f16b68a2bf41e9a8ace5521bf
Summary:
Make the snapshot output of this test terser (since `set-version` is a superset of the fully tested `set-rn-version` script). Notably, this removes any instances of `generated` from the snapshot file, which would hide the diff in PRs.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D54420338
fbshipit-source-id: e4a94b1fda34efaedf1b309496954be35acd5f98
Summary:
X-link: https://github.com/facebook/litho/pull/976
X-link: https://github.com/facebook/yoga/pull/1586
Pull Request resolved: https://github.com/facebook/react-native/pull/43299
Add the React Clang Tidy config to Yoga, run the auto fixes, and make some manual mechanical tweaks.
Notably, the automatic changes to the infra for generating a Yoga tree from JSON capture make it 70% faster.
Before:
{F1463947076}
After:
{F1463946802}
This also cleans up all the no-op shallow const parameters in headers.
{F1463943386}
Not all checks are available in all environments, but that is okay, as Clang Tidy will gracefully skip them.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D54461054
fbshipit-source-id: dbd2d9ce51afd3174d1f2c6d439fa7d08baff46f
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027179
fbshipit-source-id: 4840becb8374ddbf8091be1e5e593289d18c78e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43296
Fix CI by adding explicit visibility modifier to the newly added `BridgelessCatalystInstance` class. In Kotlin, in explicit API mode, which is usually the default mode for Kotlin, we must explicitly specify one of the modifiers for every declaration to make it clear and explicit.
Changelog:
[Internal] internal
Reviewed By: makovkastar
Differential Revision: D54442485
fbshipit-source-id: 4409ff810a09cc4fadcd2ccf21f7fbac3015f413
Summary:
Inspired by some new C++ code in `RKJSModules` where Clang Tidy could have caught some C++ quirks and shown them in Phabricator, this enables Fabric's Clang Tidy checks in more places, and enables more checks.
1. Hoist the renderer `.clang-tidy` to `xplat/js`, and duplicate to `xplat/ReactNative`
2. Remove all the scattered `.clang-tidy` files in RN which are less aggressive
3. Sort the list of checks
4. Add the following new checks:
1. `bugprone-incorrect-enable-if`
1. `bugprone-infinite-loop`
1. `bugprone-optional-value-conversion`
1. `bugprone-redundant-branch-condition`
1. `bugprone-shared-ptr-array-mismatch`
1. `bugprone-signed-char-misuse`
1. `bugprone-too-small-loop-variable`
1. `bugprone-unique-ptr-array-mismatch`
1. `bugprone-unsafe-functions`
1. `bugprone-unused-raii`
1. `cppcoreguidelines-avoid-const-or-ref-data-members`
1. `cppcoreguidelines-avoid-non-const-global-variables`
1. `cppcoreguidelines-init-variables`
1. `cppcoreguidelines-interfaces-global-init`
1. `cppcoreguidelines-missing-std-forward`
1. `cppcoreguidelines-prefer-member-initializer`
1. `facebook-hte-BadEnum`
1. `facebook-hte-MissingStatic`
1. `misc-header-include-cycle`
1. `misc-misplaced-const`
1. `modernize-use-constraints`
1. `modernize-use-designated-initializers`
1. `modernize-use-starts-ends-with`
I did not auto apply fixes, since even the existing set can sometimes (rarely) generate invalid code.
Changelog: [Internal]
Reviewed By: ksheedlo
Differential Revision: D54411398
fbshipit-source-id: 4958d880969ae07a03fa4f62ba68ee44790487ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43165
Fixes component stacks without source info, and duplication in the error message string.
## Before
No component stacks, and error message duplication:
{F1459400803}
## After
Back to normal, albeit without the component source location:
{F1459401148}
Changelog:
[General][Fixed] - Support component stacks without source info.
Reviewed By: yungsters
Differential Revision: D53981672
fbshipit-source-id: c83455673ce327ed1a4c6cfeb3247e97da9b6a2e
Summary:
Small tweak to #43069 - trim the message to avoid ending with a newline.
Changelog:
[General][Changed] - Trim invalid blob response error message
Reviewed By: christophpurrer
Differential Revision: D54422284
fbshipit-source-id: 53a4e963f8aba36c55e16ad7539b2f2d98c781f8
Summary:
When used with expo, JS code content type is `application/javascript; charset=UTF-8` instead of just `application/javascript`, We have a really large bundle and the application shows stuck at "Bundling 100%" and does not show "Downloading 1..100%".
Here we improve the check for the content type to correctly show the progress.
## Changelog:
[IOS] [FIXED] - Fixed headers content type check for iOS bundle download
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/43262
Reviewed By: huntie
Differential Revision: D54412657
Pulled By: robhogan
fbshipit-source-id: f12e260f1bda36495eb5e6ecd0f66c86f26d4747
Summary:
The RemoveDeleteTree operation assumes it can safely call getChildAt with indices that are out of bounds to find all the children. `getChildAtWithSubviewClippingEnabled` was unnecessarily stricter than `getChildAt` and would crash in such cases.
Changelog: [Android][Fixed] - Fix crash in `getChildAtWithSubviewClippingEnabled`
Reviewed By: NickGerleman
Differential Revision: D54380975
fbshipit-source-id: 17e93c685cd07b02dc20efa2fae89090d6e38457
Summary:
The `scrollEventThrottle` prop is missing in the ViewConfig for ScrollView for the Android platform. Because of that it was ignored by native in the New Architecture.
This diff fixes that.
Changelog: [Android][Fixed] - Add support for scrollEventThrottle for ScrollView on the New Architecture.
Reviewed By: fkgozali
Differential Revision: D54303157
fbshipit-source-id: 824f32c2f9fb3958271b094bbfc770992a4335e1
Summary:
Changelog: [General][Fixed] Re-enable listing Hermes debugger targets in chrome://inspect, broken in 0.74 RC
Fixes https://github.com/facebook/react-native/issues/43259.
Reverts D52958725 and fixes the original `Content-Length` Unicode bug using a different approach.
Reviewed By: fabriziocucci
Differential Revision: D54409847
fbshipit-source-id: ed5bb464ab67f37535947646b124814d8bbf797c
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:
Changelog: [General][Breaking] Native modules using the codegen now throw an error when called with `null` for optional but not nullable arguments.
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value?: number): void;
```
And you call it like this:
```
NativeModule.someMethod(null);
```
The app doesn't throw an error, but it should because this method shouldn't accept `null` according to its type definition.
## Changes
This modifies the codegen to only check for `undefined` in those cases, otherwise trying to cast the value to the expected type and failing if it's `null`.
NOTE: this is technically a breaking change, but if people are using Flow or TypeScript in their projects they're very unlikely to hit this case, because they would've complained if you tried to pass `null` in these cases.
Reviewed By: cipolleschi
Differential Revision: D54206289
fbshipit-source-id: 58f2f2f3009d203b96189d3c66d1ae98a9e4fb36
Summary:
Changelog: [internal]
This modifies the method to run microtasks in `RuntimeScheduler_Modern` to align a bit better with the spec. In this case, we'll check if we're already running microtasks when we call that method, and skip if that's the case.
We're not currently calling this method recursively so this shouldn't really be a change with the current logic.
Reviewed By: javache
Differential Revision: D54302537
fbshipit-source-id: ef5e12e68e0c7f8c9258929609c050ef78e4cde5
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 fixes a crashes during logout on Android and iOS caused by trying to unregister the inspector from instances that were not previously registered. This is because I removed a check in D51459050 that was necessary when the inspector was disabled via the flag (and we call the `unregisterFromInspector` method unconditionally).
This also gates the registration/unregistration on Android properly.
Reviewed By: huntie
Differential Revision: D54357554
fbshipit-source-id: 945288acdabdface324884bee1e832870ec8806f
Summary:
This change moves the prepack script of react-native in a separate script, so we can make sure we execute all the preprocessing we need before packing and publishing React Native to OSS.
## Changelog:
[General][Changed] - Moved the tasks of prepack in a separate node script
Reviewed By: huntie
Differential Revision: D54308411
fbshipit-source-id: 989c2b8c6cf88a1e9d87cf34e43351b5c0e7ea73
Summary:
Added a check to avoid the regeneration of RNCore components in case they have been generated already.
In order to maintain backward compatibility and to make sure not to break internal use cases, I think we should still keep the possibility to generate these components at `pod install` time.
Internal users of RNTester, for example, will not run `yarn prepack` before building react-native using OSS technology.
Notice that, in this specific case, the Codegen generates the file in a path that is not `node_modules`.
## Changelog:
[General][Added] - Skip generation of RNCore if the files have been already generated
Reviewed By: dmytrorykun
Differential Revision: D54308832
fbshipit-source-id: 0b5822a367eb0b191c42bc92f8bff20d541c5b29
Summary:
This change extracts the function to create RNCore components in a separate reusable unit.
RNCore is now generate in the `node_modules` folder when the app runs pod install, which is a problem because there are use cases where it's not possible to modify the `node_modules` folder or the generated files might be lost.
The goal is to:
- extract this function
- execute this function before packing react-native during the release. (see D54308411)
In this way, we are going to generate the RNCore files in the react-native path that will be packaged and then released.
Users of react-native will have the generated code directly in the node_modules with no need to generate it.
## Changelog:
[General][Added] - Add function to only generate RNCore components
Reviewed By: huntie
Differential Revision: D54308713
fbshipit-source-id: 0fa9ab4ba7b66c577663f0c736742c4d5583f617
Summary:
This change factor out in a variable the `libraryName` to avoid verbosity.
## Changelog:
[Internal] - factor out libraryName
Reviewed By: dmytrorykun
Differential Revision: D54308601
fbshipit-source-id: 1a64a6b960cc86a1cff059e3ba6a45c33bf3150e
Summary:
This change refactor the RNCORE_CONFIGS in a separate variable to simplify reuse.
## Changelog:
[Internal] - Refactor code
Reviewed By: dmytrorykun
Differential Revision: D54308346
fbshipit-source-id: b9d7c8e0a9b4042f2ab1adeb7aae875264d22499
Summary:
In OSS we have reports like [this one](https://github.com/facebook/react-native/issues/43241) where env variables from different settings might clash together, making react native apps fail to build hermes.
For example, a team might have defined a BUILD_FROM_SOURCE env variable to build their specific project from source and that will clash with how react native apps installs Hermes.
This change disambiguate the BUILD_FROM_SOURCE flag we have internally, moving to a less likely to clash RCT_BUILD_HERMES_FROM_SOURCE.
## Changelog:
[iOS][Breaking] - Rename BUILD_FROM_SOURCE to RCT_BUILD_HERMES_FROM_SOURCE
Reviewed By: huntie
Differential Revision: D54356337
fbshipit-source-id: 1115e3c22cbcf1d64b7edae30da614d52423123b
Summary:
The current behavior for `maintainVisibleContentPosition` on ScrollView is to pick the first fully visible item as the scroll anchor. This has a number of disadvantages:
* It causes problems for lists with loading indicators and large items. The loading glimmer can be picked as the anchor and pull the scroll down too quickly. This is the case for Marketplace.
* It's inconsistent with the [CSS Scroll Anchoring](https://www.w3.org/TR/css-scroll-anchoring-1/) behavior, which is to pick the first partially visible view.
This change will switch to picking the first partially visible view as the anchor, to align with the CSS implementation.
Discussed the change with yungsters, NickGerleman, and cipolleschi and agreed about the change in behavior.
This also enables `maintainVisibleContentPosition` for Android. After adding it to `validAttributes` for Android it appears to be working well. Previously it was not functional at all on Android, as the property change from React was not passed to ReactScrollViewManager.java.
## Changelog:
[General] [Changed] - maintainVisibleContentPosition property on ScrollView now selects the first partially visible view as the anchor, rather than the first fully visible view.
Reviewed By: NickGerleman
Differential Revision: D54223244
fbshipit-source-id: 05ddfc0bbf16d61f9599b9d8066c0bd21b086301
Summary:
Changelog: [Internal]
Fixes a bug detected by LeakSanitizer: `HostAgent`'s destructor writes to session state, but when the containing `HostTargetSession` is being torn down, the `SessionState` object currently gets destroyed first, resulting in a dangling reference. Reordering the members of `HostTargetSession` results in the correct destruction order.
bypass-github-export-checks
Reviewed By: robhogan
Differential Revision: D54305545
fbshipit-source-id: e91a6f3de5eed327b811524548d01565e26234fa
Summary:
Changelog: [Internal]
This implements the integration of `ReactInstance` with the modern CDP backend.
This is the last missing piece to complete the integration of bridgeless with the modern CDP backend, and now we can test it end to end.
Reviewed By: huntie
Differential Revision: D51459050
fbshipit-source-id: 54e8972ee199cbcc8e5e73d7215a34f008feeaa3
Summary:
Changelog: [Internal]
This implements the integration of `ReactHost` with the modern CDP backend. It handles the registration of pages in CDP when we create new instances of `ReactHost` (which is the equivalent concept in React Native).
The next PR will handle the registration of `ReactInstance` to complete the integration on bridgeless.
Reviewed By: huntie
Differential Revision: D51459049
fbshipit-source-id: 9576c8d8e38ca925035d90f2871bcd7aa534f725
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:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027184
fbshipit-source-id: 722a7e398849f5d935894f321aa0177167eebaef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027180
fbshipit-source-id: bf8875c06c8990172e6b449e12902691131b9cef
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027186
fbshipit-source-id: 2cee2b598c3ef15641222018703a7d6a467ba30c
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D54027177
fbshipit-source-id: 13b4352f0b61eec69bfdcb6a3e369faa4dfcc750
Summary:
This PR fixes an issue that `_logWarnIfCreateRootViewWithBridgeIsOverridden` was called in wrong place.
Assuming user overrides this method and call to `[super]`:
```objc
- (UIView *)createRootViewWithBridge:(RCTBridge *)bridge moduleName:(NSString *)moduleName initProps:(NSDictionary *)initProps {
UIView *view = [super createRootViewWithBridge:bridge moduleName:moduleName initProps:initProps];
view.backgroundColor = [UIColor redColor];
return view;
}
```
This method still wasn't called in bridgeless (and not showing the error).
Checking if user overrides this method in `appDidFinishWithLaunching` works every time

## Changelog:
[IOS] [FIXED] - Properly warn about `createRootViewWithBridge` being deprecated
Pull Request resolved: https://github.com/facebook/react-native/pull/43146
Test Plan: Check if warning is shown when message is overridden
Reviewed By: huntie
Differential Revision: D54303506
Pulled By: cipolleschi
fbshipit-source-id: cf30555c791493f28b3015a189cf93b60cace8f8
Summary:
This change align the `getSurfacePresenter` and `getModuleRegistry` to the iOS convention for which these should be computed properties with no `get` prefix in their name.
We want to land this change and to pick it in 0.74 so we can remove the `get` versions in 0.75.
## Changelog:
[iOS][Deprecated] - Deprecate `getSurfacePresenter` and `getModuleRegistry` for `surfacePresenter` and moduleRegistry` props.
Reviewed By: javache
Differential Revision: D54253805
fbshipit-source-id: e9ff7db744a73a3bd0f8ae1d87875e54ddd9a1a4
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:
## Changelog:
[Internal] -
Was writing some unit tests, accidentally included `ImageProps.h` twice (once directly and once transitively) and realized that we have a handful of files without `#pragma once`.
This fixes it for header files inside `ReactCommon`.
Reviewed By: zeyap
Differential Revision: D54258058
fbshipit-source-id: 70f4e9935304803187d1affd72ed44157b1d8fb3
Summary:
Changelog: [General][Fixed] Fixed crash when passing fewer arguments than expected in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: number): void;
```
And you call it like this:
```
NativeModule.someMethod();
```
The app crashes.
This happens because the codegen tries to cast the value to the expected type without checking if the argument is within the bounds of the arguments array.
## Changes
This fixes that issue with a change in the codegen to guard against this in the generated code (see changes in the snapshot tests).
Reviewed By: RSNara
Differential Revision: D54206287
fbshipit-source-id: 575af462725515928f8634fccc7a9cb51ca0ce4f
Summary:
Changelog: [General][Fixed] Fixed crash when passing non-numeric values where RootTag is expected to methods in native modules using codegen
## Context
Right now, if you have a native module using the codegen with a method like this:
```
someMethod(value: RootTag): void;
```
And you call it like this:
```
NativeModule.someMethod('');
```
The app crashes.
This happens because we cast the JS value to a C++ value using the method that asserts (`toNumber`) instead of the one that throws a JS error (`asNumber`).
## Changes
This fixes the crash by using `asNumber` instead of `toNumber`.
Reviewed By: RSNara
Differential Revision: D54206288
fbshipit-source-id: 9398112667e0f26edaf4f8f3b32e79fa8aafde62
Summary:
This change fixes a couple of issues within the RCTUIManager:
* it calls the right method in the `super` branches (although they should neve be executed)
* it invert the call order between the `_registry` and the `uiManager` to avoid extra calls into the `viewForReactTag`.
## Changelog:
[Internal] - Use the right method in super and invert the order of where we search for views.
## Facebook:
See S397861 and T180527210 for more information.
Reviewed By: javache
Differential Revision: D54246220
fbshipit-source-id: 1c7503ad3e80cf50ecc016a984ca180a19b73cc0
Summary:
This diff removes extra argument from the `extractLibrariesFromJSON` call inside `findLibrariesFromReactNativeConfig`.
This should fix the iOS failurte discribed in https://github.com/facebook/react-native/issues/43204
Changelog: [iOS][Fixed] - Codegen correctly handles react-native.config.js.
Reviewed By: cipolleschi
Differential Revision: D54248400
fbshipit-source-id: 2ae5d0d29f49725877559a5b0edd7d59f8bdefaa
Summary:
This adds initial support for wide gamut (DisplayP3) colors to React Native iOS per the [RFC](https://github.com/react-native-community/discussions-and-proposals/pull/738). It provides the ability to set the default color space to sRGB or DisplayP3 and provides the native code necessary to support `color()` function syntax per the [W3C CSS Color Module Level 4](https://www.w3.org/TR/css-color-4/#color-function) spec. It does _not_ yet support animations and requires additional JS code before fully supporting the `color()` function syntax.
bypass-github-export-checks
## Changelog:
[IOS] [ADDED] - Add basic DisplayP3 color support
Pull Request resolved: https://github.com/facebook/react-native/pull/42830
Test Plan:

Follow test steps from https://github.com/facebook/react-native/issues/42831 to test support for `color()` function syntax.
To globally change the default color space to DisplayP3 make the following changes to RNTester AppDelegate.mm:
```diff
+ #import <React/RCTConvert.h>
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
// ...
+ RCTSetDefaultColorSpace(RCTColorSpaceDisplayP3);
return [super application:application didFinishLaunchingWithOptions:launchOptions];
}
```
Reviewed By: javache
Differential Revision: D53380407
Pulled By: cipolleschi
fbshipit-source-id: 938523958f9021e8d98bdb1d4e254047e3ecdad7
Summary:
## Changelog:
[Internal] -
`view.transformOrigin` prop should be initialized to "center", since this is default [per documentaion](https://reactnative.dev/docs/next/transforms#transform-origin), and it should be treated this way even if the prop is not explicitly set from JS.
Reviewed By: christophpurrer
Differential Revision: D54229772
fbshipit-source-id: 5212792c8dc5db6f4c17d1b2980ac2564c986cd8
Summary:
`Image.getSize/getSizeWithHeaders` are still working in old fashioned "callback" way
```tsx
Image.getSize(uri, function success(width,height) { }, function failure(){ } ); // undefined
Image.getSizeWithHeaders(uri, headers, function success(width,height) { }, function failure(){ } ); // undefined
```
But in 2024 more developers prefer use async/await syntax for asynchronous operations
So, in this PR I added support for Promise API with **backward compatibility**, modern way:
```tsx
Image.getSize(uri).then(({width,height}) => { }); // Promise
Image.getSizeWithHeaders(uri, headers).then(({width,height}) => { }); // Promise
```
bypass-github-export-checks
## Changelog:
[GENERAL] [ADDED] - `Image.getSize/getSizeWithHeaders` method returns a promise if you don't pass a `success` callback
Pull Request resolved: https://github.com/facebook/react-native/pull/42895
Test Plan:
1. ts: New test cases added in typescript tests
2. runtime: you can create a new project and put code from this PR into the next files
a. `node_modules/react-native/Libraries/Image/Image.android.js`
b. `node_modules/react-native/Libraries/Image/Image.ios.js`
Reviewed By: javache
Differential Revision: D53919431
Pulled By: cipolleschi
fbshipit-source-id: 508b201e17e0ffda2e67aa5292bf9906b88d09c5
Summary:
This small PR fixes issue causing `AlertExample` to crash on `login-password` prompt example, as it was trying to render object in `<Text>`
## Changelog:
[INTERNAL] [FIXED] - Prevent alert example from crashing
Pull Request resolved: https://github.com/facebook/react-native/pull/43084
Test Plan: `login-password` prompt example in `AlertExample` doesn't crash when pressing `OK`
Reviewed By: cipolleschi
Differential Revision: D53964494
Pulled By: lunaleaps
fbshipit-source-id: 16a0364d3d65a33956c21a68b121e6c26b41d123
Summary:
This change renames `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`.
The reason is that, without the suffix, Codegen was reading the NativeComponent spec also for iOS, generating some invalid specs and making RNTester fail.
## Changelog:
[Android][Changed] - Rename `PopupMenuAndroidNativeComponent.js` to `PopupMenuAndroidNativeComponent.android.js`
Reviewed By: cortinico, dmytrorykun
Differential Revision: D54199736
fbshipit-source-id: 7fd67c4d38a69fe3a84c800c8ee5dcbd8c4f9a6c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43101
Extends `ReactInstanceIntegrationTest` to allow varying feature flags in tests, using gtest's parameterised tests.
Exercise this in `ConsoleLogTest` to test against the modern CDP registry, for which we also needed to modify some initialisation logic to account for the fact that under the modern registry, the page is added by the host, rather than by Hermes `DecoratedRuntime`.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53919148
fbshipit-source-id: 4eb87abf548f30b5483b819a2dadd444d1d5c80d
Summary:
Changelog: [Internal]
Uses the capability introduced in https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/4 to avoid repeating the dev server's host:port in the `ws` / `wss` parameter we pass to the Chrome DevTools frontend. This gives us more flexibility to handle port forwarding and redirects outside of `dev-middleware`. This is mostly useful in Meta's internal VS Code remoting setup, but this particular change should work equally well in open source.
Reviewed By: huntie
Differential Revision: D54107316
fbshipit-source-id: 68d4dbf4849ca431274bfb0dc8a4e05981bdd5b5
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:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D54027183
fbshipit-source-id: b87e3931642abaa22b84fd48f0504f36e9c3621f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43162
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027181
fbshipit-source-id: af9f022d36a2e60788d6790525736d1b6cfdf6fa
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43161
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D54027187
fbshipit-source-id: a25024ba7f7d4893a2b7d083e2ba10c5f2e3a035
Summary:
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
bypass-github-export-checks
Reviewed By: javache
Differential Revision: D54027182
fbshipit-source-id: 946dbf484119890658c68767916fcbf7c66996bc
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:
Those files should not stay in the root `/app` folder but inside the `/app/gradle/wrapper` folder.
I've noticed this in the Upgrade Helper UI hence I'm removing them.
Changelog:
[Internal] [Changed] - Remove accidental files included inside the template
Reviewed By: mdvacca
Differential Revision: D54122995
fbshipit-source-id: 8873a91ffbea20f609c7aabd428a815c77a38db5
Summary:
RN-Tester is currently instacrashing on fast-refresh (pressing r on Metro) as it ends up on `onJSBundleLoadedFromServer`
which throws an exception on Bridgeless mode. I'm fixing it by following the same logic as `onReloadWithJSDebugger`.
Changelog:
[Android] [Fixed] - Do not crash on onJSBundleLoadedFromServer when fast-refreshing on bridgeless mode
Reviewed By: huntie
Differential Revision: D54121838
fbshipit-source-id: 82d98ec0c5b2295f5751525368c956574dd7f3a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43133
I noticed inconsistent handling of terminating newlines in D54006327@V1, and had also been noticing `yarn build` reformatting unrelated sections of `package.json` files.
For now, this logic isn't moved to a shared util, since there will likely be a higher level abstraction for the release scripts in the next batch of improvements.
Changelog: [Internal]
Reviewed By: lunaleaps, cipolleschi
Differential Revision: D54007565
fbshipit-source-id: 74d58362a85be4fae2f9e058b6c6622a026ff0a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43157
IViewGroupManager is NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: rshest
Differential Revision: D54034058
fbshipit-source-id: ad317c73d45fdd801aeee65d5308400e2e1c8552
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43156
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D54027185
fbshipit-source-id: f3c337def2d42cf1f6fed2e2eb4938a84a51f8d4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43155
All these classes are NullSafe, let's mark them as NullSafe(Local) to ensure lint detect errors in the future
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D54027178
fbshipit-source-id: 37940ecec4d42f9f5ae7784a865564b0ef80f4a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43159
Changelog: [internal]
This modifies the default `RCTAppDelegate` for iOS apps in OSS to provide an implementation for the C++ native module for feature flags.
In a following diff I'll replace the `React-featureflagsnativemodule.podspec` file with one that includes all built-in C++ native modules.
Reviewed By: RSNara
Differential Revision: D54082349
fbshipit-source-id: 8c4ed7499c6fd35916ba105edcae0e2c85961e1c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43152
Now that 0.74 has been cut, we can drop this warning and let the exception bubble up.
In https://github.com/facebook/react-native/pull/41509 we stopped masking this.
Changelog: [Android][Changed] Throwing IllegalArgumentException from ReactPackage is no longer suppressed
Reviewed By: cortinico, cipolleschi
Differential Revision: D54068429
fbshipit-source-id: c2f780ccfefabf2334c94b632bca93242af86008
Summary:
This diff renames React-Codegen to ReactCodegen. This way we'll no longer have to try both
```
#include <React-Codegen/MyModule.h>
```
and additionally
```
#include <React_Codegen/MyModule.h>
```
for cases with `use_frameworks`.
Changelog: [iOS][Breaking] - Rename React-Codegen to ReactCodegen
Reviewed By: cipolleschi
Differential Revision: D54068492
fbshipit-source-id: dab8ea2034d299266482929061caa14397421445
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43149
Changelog: [internal]
At the moment we're silently falling back to default values when trying to use common feature flags from JS when the native module isn't available. This could lead to unexpected behaviors and it's not immediately obvious, so this logs an error when it happens.
Reviewed By: javache
Differential Revision: D54063391
fbshipit-source-id: 5886754958930b88ef63c24d77a9e8486d92c731
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43135
This change makes the New Architecture the default on both iOS and Android.
This means that new application will be created using the New Architecture by default.
It is still possible to opt out from it.
## Changelog
[General][Changed] - Make the new architecture the default
Reviewed By: cortinico, sammy-SC, dmytrorykun
Differential Revision: D54006751
fbshipit-source-id: bd7de0814925b65ab180105e18c1f6f275ba2672
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43094
Merge the internal `cxxcdp-tester` project into `jsinspector-modern/tests`.
Note: These tests still use RN default feature flags and therefore test against the legacy CDP registry - that's addressed in the next diff.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D53766994
fbshipit-source-id: eec144124b20a4500e28398e98763febaed52748
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43143
AsyncCallback allows storing SyncCallback and invoking it from any thread.
However, there are cases where if you have a mix of sync and async callbacks - you might want to invoke them together in one go, instead of spreading them out across thread invocations.
For those cases - allow invoking any AsyncCallback as a sync one, prefixing it with "unsafe", because it's inherently not a safe operation to perform.
Changelog:
[General][Changed] - Allow invoking the AsyncCallback synchronously to allow for tight performance optimization.
Reviewed By: s-rws
Differential Revision: D54028850
fbshipit-source-id: f6729819f791f1d58d2ca655d4082547f18bdd2d
Summary:
`ndkVersion` is unset when building from source using this guide: https://reactnative.dev/contributing/how-to-build-from-source
## Changelog:
[ANDROID] [FIXED] - Fix `ndkVersion` is unset when building from source
Pull Request resolved: https://github.com/facebook/react-native/pull/43131
Test Plan:
```
git clone https://github.com/microsoft/react-native-test-app.git
cd react-native-test-app
npm run set-react-version nightly
yarn
# Manually apply the patch in node_modules/react-native/ReactAndroid/build.gradle.kts
# Enable building from source
sed -i '' 's/#react.buildFromSource/react.buildFromSource/' example/android/gradle.properties
# Build
cd example/android
./gradlew assembleDebug
```
Reviewed By: christophpurrer
Differential Revision: D54006425
Pulled By: cortinico
fbshipit-source-id: 9ede64bc14af4cf609b7a4c12c5a1082bbc31f09
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43129
## Changelog:
[Internal] -
C++ side expects "source" property to be an up to date, correctly resolved Image source inside `ImageProps`.
Incidentally, it wasn't the case when:
* we build for an Android platform
* the asset is a "packager asset", i.e. bundled by Metro and included in APK
It hasn't been an issue in the case of "pure" Android platform, as it instead uses "src" prop, instead of source on the Java implementation side, ignoring "source" completely, so the fact that "source" wasn't propagated correctly to C++ in some cases didn't affect Android.
However, there are some new use cases where we'd like to have correct "source" value in C++ as well (and ultimately align this between all the platforms, so it's "source" everywhere, but this is a matter of a separate discussion).
Differential Revision: D54000899
fbshipit-source-id: 9bfb9e7c157cf19ddf396c141b03b75f3b2022e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43130
Various fixes/tweaks to the `test-e2e-local` script, impacted by recent changes, found during the release process:
- Fix typo in variable name for `circleciToken` arg.
- Relocate erroneously positioned `process.exit` call (a force exit around Verdaccio, which we will remove in future).
- Add notice on exit around Verdaccio server not being killed successfully (to do in T179377112).
- Switch from Yarn to npm for test project installation — Yarn 3 is not respecting `npmRegistryServer`, see https://github.com/yarnpkg/yarn/issues/2508.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53951606
fbshipit-source-id: f6e29ef6c9ab33ebf60124757576fcb54219f339
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43118
While debugging issues with precompiled_headers in Instagram, it became apparent that these RN files don't correctly import the necessary files to make them build on their own. Fix that!
Changelog: [iOS][Fixed] Fixed missing header imports
Reviewed By: fkgozali
Differential Revision: D53963676
fbshipit-source-id: 74e9758153f6176133475e45d27f7644d1a6dece
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43023
Unused mobile config, and is not consistently used across all the many places we can initialize a Hermes instance.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D53761942
fbshipit-source-id: a3e1adae87e41142c337a27b33750f82774cf92c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43114
Changelog: [iOS][Breaking]
PR#42628 introduced new behavior on how the react native infra tracks local notifications that start the app. in this PR, we are officially deleting the old implementation.
Reviewed By: ingridwang
Differential Revision: D52931617
fbshipit-source-id: 3b77479b0aacf239e45cfcc7d7c4b20e82e0b786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43113
Changelog: [Internal]
Renames the "Page" concept in the modern CDP backend to "Host". Now all the Target types we have are named consistently after React Native concepts (ReactHost, ReactInstance, JSI Runtime) rather than CDP/browser concepts (Page).
Reviewed By: robhogan
Differential Revision: D53945333
fbshipit-source-id: 90e8b914ba8b4927806cbdd072ca36c78fd2093f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43049
This connects the OnLoad.cpp file used by OSS apps with the `rncli_cxxModuleProvider`.
This method is created by the CLI and takes care of querying all the TM CXX Modules discovered and returning them.
This PR is currently waiting on https://github.com/react-native-community/cli/pull/2296
Changelog:
[Internal] [Changed] - Hook the default-app-setup OnLoad.cpp file with the cxxModuleProvider from RNCLI
Reviewed By: cipolleschi
Differential Revision: D53812109
fbshipit-source-id: 47bc0ea699516993070cfa0127de97853acf8890
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43111
When mounting views in the interop layer, we register them in an array `reactSubview` that is added to `UIView`. However, when unmounting them, we were just removing them from the parent view.
This worked fine while the view we were adding to reactSubview was the same that we were adding to hierarchy. However, there are instances where libraries might wrap those views in some custom wrappers. This break the assumption that the same view we are adding to the UI hierarchy is the same view we will remove.
With this change, we make sure to use the same semantic when we add some view and when we remove it.
This also fixes a crash that happens with Mobile home when navigating away from the Ride's Map, using Fabric.
## Changelog
[internal] - Remove views from hierarchy using the view that is added to the `reactSubviews`
Reviewed By: sammy-SC
Differential Revision: D53943728
fbshipit-source-id: 56e669c14db74b6af683384b6ca72ad3f5cfdafe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43099
In all methods of FabricUIManager we check whether it's been destroyed before doing any logic, but we don't in this asynchronous method we're scheduling to report mounts.
This adds the check in that case as well to potentially fix some crashes we're seeing in current experiments for mount hooks on Android.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D53920863
fbshipit-source-id: 3cc18cf5237d4866940739de80cc00604bcd0fb6
2024-02-20 07:37:29 -08:00
3742 changed files with 202660 additions and 154824 deletions
This directory is home to the Circle CI configuration files. Circle is our continuous integration service provider. You can see the overall status of React Native's builds at https://circleci.com/gh/facebook/react-native
You may also see an individual PR's build status by scrolling down to the Checks section in the PR.
## Purposes
We use CircleCI for mainly 3 purposes:
1. Testing changes
2. Release Nightlies
3. Release Stable Versions of React Native
When testing changes, we run all the tests on commits that lands on `main`. For commits in PR, we try to understand which kind of changes the PR is about and we try to selectively run only the relevant tests. so, for example, if a PR only touches iOS files, we are going to run only iOS tests.
A Nighly job runs every day at around 9:00 PM, GMT. They run from `main` and they publish a version of React Native using the current state of the codebase, creating a version number that follows the format: `0.<current-version+1>.0-nightly-<YYYYMMDD>-<short-commit-hash>`.
The nightly job also publish all the monorepo packages, taking care of updating the transitive dependencies of those packages.
Stable versions are released manually by the Release Crew and they run from a stable branch. Stable branches have the shape of `0.<version>-stable`.
## How It Works?
CircleCI execution is now split in two steps:
- Setup
- Testing
The setup step takes care of analyzing the changes in the PR and of deciding which jobs needs to run.
The testing flow is a set of workflows that executes the required tests.
### Setup
The code of the setup workflow lives in the root [`config.yml`](https://github.com/facebook/react-native/blob/main/.circleci/config.yml) file.
It uses the `Continuation orb` from CircleCI to start a CI flow that depends on the changes present in the PR.
If the changes are not coming from a PR (either a simple commit or if the CI is running on main) **we always run all the tests** as a cautionary measure.
The setup job has also to expose all the pipeline parameters that we would need to pass to the actual workflow. Those parameters are **automatically forwarded** to the workflows that are started as a result of the setup.
The setup job uses a JS script to carry on its logic. The [`pipeline_selection.js`](https://github.com/facebook/react-native/blob/main/scripts/circleci/pipeline_selection.js) script can be invoked with two commands:
-`filter-jobs`
-`create-configs`
The **`filter-jobs`** command takes care of creating a JSON representation of the tests we need to run based on the changes in the PR.
The **`create-configs`** command consumes the JSON representation to create a CircleCI configuration that can then executes all the required tests.
#### Creating a Configuration
To create a configuration, the `pipeline-selection` scripts collates together various pieces of `YML` files that lives in the [`Configurations` folder](https://github.com/facebook/react-native/tree/main/.circleci/configurations).
The order in which these files are appended is **important** and it always contains the following.:
1.`top_level.yml`: this file contains some high level directives for CircleCI, like the version, the list of orbs, the cache-keys, and the pipeline parameters that can be used by the workflows.
2.`executors.yml`: this file contains the list of the executors used in our jobs and their configurations.
3.`commands.yml`: this file contains all the commands that can be used by jobs to executes. Commands are reusable functions that are shared by multiple jobs.
4.`jobs.yml`: this file contains the jobs that are used by workflows to carry on some specific tasks. They are composed of sequential commands.
5.`workflows.yml`: this file contains the shared workflows that needs to (or can) be always executed, no matter which kind of changes are pushed to CI. An example of these workflows is `analysis` (which is always executed) or `nightly` (which can be executed if a specific pipeline parameter is passed to the CI).
Then, the `pipeline_selection create-configs` attach some specific test workflows, depending on the changes that are present in the PR. These change-dependent workflows live in the [`test_workflows`](https://github.com/facebook/react-native/tree/main/.circleci/configurations/test_workflows) folder.
These workflows are:
*`testAll.yml` => runs all the possible tests. This workflow is executed on main and on PRs which change set touches both iOS and Android
*`testAndroid.yml` => runs all the build steps and Android tests. This is used on changes that happens on the Android codebase and infra (`ReactAndroid` folder)
*`testIOS.yml` => runs all the build steps and iOS tests. This is used on changes that happens on the iOS codebase and infra (`React` folder)
*`testE2E.yml` => runs the E2E tests. As of today, E2E tests can be triggered if the commit message contains the `#run-e2e-tests` tag.
*`testJS.yml` => For all the changes that do not touch native/platform code, we only run JS tests.
Notice that if there are changes on files that do not represents code (for example `.md` files like this one or the `Changelog`) we don't run any CI.
## Test workflows
The test workflows for native code are composed of 2 parts:
- building React Native
- testing
Building React Native requires us to build several parts of it:
1. We need to build the Hermes JS engine
2. We need to build Android to create prebuilds
3. We need to package everything in an npm package that will mimic a React native release
4. We need to create a local maven repository
### Building Hermes Engine
#### Android
The `build_android` workflows takes care of building the Android version of Hermes and to put it properly in a local maven repository.
See the [Build Android](#build_android) section below.
#### iOS
Hermes is a very complicated item to build for iOS.
It is composed of the Hermes compiler (HermesC) and of the actual engine.
Hermes is shipped as a universal XCFramework. This means that we need to build all the architecture slices and then put them together in the XCFramework archive.
We also need to build 2 configurations: Debug and Release.
In order to be efficient and to save costs, we parallelize the process as much as possible:
1. We prepare the environment for building Hermes.
2. We build HermesC which is required by all the slices.
3. We start 8 jobs to build all the required slices in parallel:
1.`iphone` slice, Debug mode
1.`iphonesimulator` slice, Debug mode
1.`macos` slice, Debug mode
1.`catalyst` slice, Debug mode
1.`iphone` slice, Release mode
1.`iphonesimulator` slice, Release mode
1.`macos` slice, Release mode
1.`catalyst` slice, Release mode
4. We then have 2 jobs to create the Debug and Release tarballs in parallel.
1. The Debug job receives the 4 Debug slices
1. The Release job receives the 4 Release slices
The `Debug` and `Release` tarball are then uploaded as artifacts. Notice that these we use these artifacts to **test the release** of React Native.
While building Hermes, we take also care of building the dSYMs. A dSYM (Debug Symbols) is an archive that contains the Debug Symbols that users can load to de-symbolicate the Hermes Stack traces. These symbols are published when we create a React Native release.
A lot of these build steps are automated by some shell scripts that lives in the [`react-native/packages/react-native/sdks/hermes-engine/utils` folder](https://github.com/facebook/react-native/tree/main/packages/react-native/sdks/hermes-engine/utils).
### Build Android
The android build is all managed by Gradle, so building android should be as easy as calling a [`gradle` command](https://github.com/facebook/react-native/blob/main/.circleci/configurations/jobs.yml#L268-L274).
The relevant part here is that the build android generates a `maven-local` repository that is passed to the [`build_npm_package`](https://github.com/facebook/react-native/blob/main/.circleci/configurations/jobs.yml#L1182) and that we use to test the releases.
### Build NPM package
This job is the responsible to create an NPM package that is suitable to be released or tested in CI.
If we are in a release flow (for example the Nightly workflow), it also proceed with the publication.
The job can be invoked with different parameters:
-`dry-run` => it does not publish anything, but prepare the artifacts to be used for testing
-`nightly` => it creates the artifacts and publish a nightly version of React Native.
-`release` => it creates the artifacts and publish a stable version of React Native.
The build NPM package takes all the artifacts produced in the previous steps (iOS' Hermes, iOS' Hermes dSYMs, Android's `maven-local`) and creates an npm package packing all the code.
If in a release mode, it also proceed publishing the NPM package to NPM, and the artifacts to Maven central, which we use to distribute all the artifacts.
This job also uploads the `maven-local` repository and a zipped version of the npm package to CircleCI's artifacts. We use these artifacts to **test the release** of React Native.
## Testing React Native
React Native tests runs in two different scenarios:
- RNTester
- A New App
### RNTester
RNTester is our internal testing app. It is a fully working React Native app that lives in the [`react-native/packages/rn-tester` folder](https://github.com/facebook/react-native/tree/main/packages/rn-tester) of the repository.
RNTester is an app which contains code that exercise most part of the React Native frameworks.
It also has the feature of building React Native **from source**. For that reason, it does not have to wait for the NPM package to be ready, but RNTester's tests can start as soon as the `build_android` step and the step that builds Hermes for iOS are done.
Notice the Tests on RNTester for iOS consumes the Hermes engine that is built in the previous steps.
For Android, these tests creates an APK that is uploaded as an artifact in CircleCI. We use these artifacts to **test the releases** of React Native..
### A New App
The React Native repo contains a template app in the [`react-native/packages/react-native/template` folder]() that is used to spin up a new application that is preconfigured with React Native.
We have several tests that we run starting from the template, testing various configurations:
- Debug/Release
- JSC/Hermes (two different JS engine we support)
- New/Old Architecture (two different Architectures for React Native)
We want to test all the React Native changes against the template, but we can't publish a React native version on each change that is merged. Therefore, to run tests on the template we use a NPM registry proxy called [Verdaccio](https://verdaccio.org/).
When running a Template test our CI follows roughly these steps:
1. Prepare the executor
2. Start a Verdaccio server
3. Publish on Verdaccio all the monorepo [packages](https://github.com/facebook/react-native/tree/main/packages) on which React Native depends on.
4. Publish on Verdaccio the react-native NPM package that has been created in the NPM step
5. Spin up a new React native apps from the template, downloading react-native from Verdaccio.
In this way, we are sure that we can test all the changes that happen in React Native on a new React Native app.
This directory was home to the Circle CI configuration files.
In July 2024 we moved to GitHub Actions, and week this folder for backward compatibility, as we want to keep on using Circle CI for the release of React Native <= 0.74.
description:Report a bug with React Native DevTools and the New Debugger
labels:["Needs: Triage :mag:","Debugger"]
body:
- type:markdown
attributes:
value:"## Reporting a bug for React Native DevTools"
- type:markdown
attributes:
value:|
Thank you for taking the time to report an issue for React Native DevTools, our new Debugger for React Native.
Before you continue:
* If you're using **Expo** and you're noticing a bug, [report it here](https://github.com/expo/expo/issues).
* If you've found a problem with our **documentation**, [report it here](https://github.com/facebook/react-native-website/issues/).
* If you're having an issue with **Metro** (the bundler), [report it here](https://github.com/facebook/metro/issues/).
* If you're using an external library, report the issue to the **library first**.
* Please [search for similar issues](https://github.com/facebook/react-native/issues) in our issue tracker.
Make sure that your issue is tested against the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
- type:textarea
id:description
attributes:
label:Description
description:A clear and concise description of what the bug is.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:The list of steps that reproduces the issue.
placeholder:|
1. Install the application with `yarn android`
2. Press `j` to open the debugger
3. Do something...
validations:
required:true
- type:input
id:version
attributes:
label:React Native Version
description:The version of react-native that this issue reproduces on. Bear in mind that only issues on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) will be looked into.
placeholder:"0.76.0"
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
...
System:
OS: macOS 14.1.1
CPU: (10) arm64 Apple M1 Max
Memory: 417.81 MB / 64.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
...
render:text
validations:
required:true
- type:textarea
id:extra
attributes:
label:Screenshots and Videos
description:|
Please provide screenshot or a video of your bug if relevant.
Issues with videos and screenshots are more likely to **get prioritized**.
Please use this form to file an issue if you have upgraded or are upgrading to [latest stable release](https://github.com/facebook/react-native/releases/latest) and have experienced a regression (something that used to work in previous version).
If you're **NOT** upgrading the React Native version, please use this [other bug type](https://github.com/facebook/react-native/issues/new?template=bug_report.yml).
Before you continue:
* If you're using **Expo** and having problems updating it, [report it here](https://github.com/expo/expo/issues).
* If you're found a problem with our **documentation**, [report it here](https://github.com/facebook/react-native-website/issues/).
* If you're having an issue with **Metro** (the bundler), [report it here](https://github.com/facebook/metro/issues/).
* If you're using an external library, report the issue to the **library first**.
* Please [search for similar issues](https://github.com/facebook/react-native/issues) in our issue tracker.
Make sure that your issue:
* Have a **valid reproducer** with an [empty project from template](https://github.com/react-native-community/reproducer-react-native).
* Is upgrading to the [**latest stable**](https://github.com/facebook/react-native/releases/) of React Native.
Due to the extreme number of bugs we receive, we will be looking **ONLY** into issues with a reproducer, and on [supported versions](https://github.com/reactwg/react-native-releases#which-versions-are-currently-supported) of React Native.
- type:input
id:old-version
attributes:
label:Old Version
description:The version of react-native that you're upgrading from.
placeholder:"0.72.0"
validations:
required:true
- type:input
id:new-version
attributes:
label:New Version
description:The version of react-native that you're upgrading to. Bear in mind that only issues that are upgrading to the [latest stable](https://github.com/facebook/react-native/releases/) will be looked into.
placeholder:"0.73.0"
validations:
required:true
- type:textarea
id:description
attributes:
label:Description
description:A clear and concise description of what the bug is.
validations:
required:true
- type:textarea
id:reproduction
attributes:
label:Steps to reproduce
description:The list of steps and commands to reproduce the issue.
placeholder:|
1. Install the application with `yarn android`
2. Click on the button on the Home
3. Notice the crash
validations:
required:true
- type:dropdown
id:platforms
attributes:
label:Affected Platforms
description:Please select which platform you're developing to, and which OS you're using for building.
multiple:true
options:
- Runtime - Android
- Runtime - iOS
- Runtime - Web
- Runtime - Desktop
- Build - MacOS
- Build - Windows
- Build - Linux
- Other (please specify)
validations:
required:true
- type:textarea
id:react-native-info
attributes:
label:Output of `npx react-native info`
description:Run `npx react-native info` in your terminal, copy and paste the results here.
placeholder:|
Paste the output of `npx react-native info` here. The output looks like:
...
System:
OS: macOS 14.1.1
CPU: (10) arm64 Apple M1 Max
Memory: 417.81 MB / 64.00 GB
Shell:
version: "5.9"
path: /bin/zsh
Binaries:
Node: ...
version: 18.14.0
...
render:text
validations:
required:true
- type:textarea
id:stacktrace
attributes:
label:Stacktrace or Logs
description:Please provide a stacktrace or a log of your crash or failure
render:text
placeholder:|
Paste your stacktraces and logs here. They might look like:
at com.facebook.soloader.SoLoader.g(Unknown Source:341)
at com.facebook.soloader.SoLoader.t(Unknown Source:124)
at com.facebook.soloader.SoLoader.s(Unknown Source:2)
at com.facebook.soloader.SoLoader.q(Unknown Source:42)
at com.facebook.soloader.SoLoader.p(Unknown Source:1)
...
validations:
required:true
- type:input
id:reproducer
attributes:
label:Reproducer
description:A link to a Expo Snack or a public repository that reproduces this bug, using [this template](https://github.com/react-native-community/reproducer-react-native). Reproducers are **mandatory**.
description:This action builds hermesc for Apple platforms
inputs:
hermes-version:
required:true
description:The version of Hermes
react-native-version:
required:true
description:The version of Hermes
slice:
required:true
description:The slice of hermes you want to build. It could be iphone, iphonesimulator, macos, catalyst, appletvos, appletvsimulator, xros, or xrossimulator
flavor:
required:true
description:The flavor we want to build. It can be Debug or Release
description:Which JavaScript engine to use. Must be one of "Hermes", "JSC".
default:Hermes
use-frameworks:
description:The dependency building and linking strategy to use. Must be one of "StaticLibraries", "DynamicFrameworks"
default:StaticLibraries
architecture:
description:The React Native architecture to Test. RNTester has always Fabric enabled, but we want to run integration test with the old arch setup. Must be one of "OldArch" or "NewArch"
default:OldArch
ruby-version:
description:The version of ruby that must be used
default:2.6.10
flavor:
description:The flavor of the build. Must be one of "Debug", "Release".
`| :information_source: | This issue doesn't match any of the expected types for this repository - closing. |`,
`> [!CAUTION]`+
`> **Invalid issue**: This issue is not valid, either is not a bug in React Native, it doesn't match any of the issue template, or we can't help further with this.`,
);
awaitcloseIssue();
return;
case'Type: Question':
awaitaddComment(
`| :warning: | Issue is a Question |\n`+
`| --- | --- |\n`+
`| :information_source: | We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/). |`,
);
awaitcloseIssue();
return;
case'Type: Docs':
awaitaddComment(
`| :warning: | Documentation Issue |\n`+
`| --- | --- |\n`+
`| :information_source: | Please report documentation issues in the [react-native-website](https://github.com/facebook/react-native-website/issues) repository. |`,
`> [!NOTE]`+
`> **Not a bug report**: This issue looks like a question. We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/).`,
);
awaitcloseIssue();
return;
case'Resolution: For Stack Overflow':
awaitaddComment(
`| :warning: | Issue is a Question |\n`+
`| --- | --- |\n`+
`| :information_source: | We are using GitHub issues exclusively to track bugs in the core React Native library. Please try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native) as it is better suited for this type of question. |`,
`> [!NOTE]`+
`> **Not a bug report**: This issue looks like a question. We are using GitHub issues exclusively to track bugs in React Native. GitHub may not be the ideal place to ask a question, but you can try asking over on [Stack Overflow](http://stackoverflow.com/questions/tagged/react-native), or on [Reactiflux](https://www.reactiflux.com/).`,
);
awaitcloseIssue();
return;
case'Type: Docs':
awaitaddComment(
`> [!NOTE]`+
`> **Docs issue**: This issue looks like an issue related to our docs. Please report documentation issues in the [react-native-website](https://github.com/facebook/react-native-website/issues) repository.`,
);
awaitcloseIssue();
return;
case'Type: Expo':
awaitaddComment(
`| :warning: | Issue is Related to Expo |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue is related to Expo and not React Native core. Please open your issue in [Expo's repository](https://github.com/expo/expo/issues/new). If you are able to create a repro that showcases that this issue is also happening in React Native vanilla, we will be happy to re-open. |`,
`> [!NOTE]`+
`> **Expo related**: It looks like your issue is related to Expo and not React Native core. Please open your issue in [Expo's repository](https://github.com/expo/expo/issues/new). If you are able to create a repro that showcases that this issue is also happening in React Native vanilla, we will be happy to re-open.`,
);
awaitcloseIssue();
return;
case'Needs: Issue Template':
awaitaddComment(
`| :warning: | Missing Required Fields |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a [new issue is created](https://github.com/facebook/react-native/issues/new?template=bug_report.md). Could you go back and make sure to fill out the template? You may edit this issue, or close it and open a new one. |`,
`> [!WARNING]`+
`> **Missing issue template**: It looks like your issue may be missing some necessary information. GitHub provides an example template whenever a [new issue is created](https://github.com/facebook/react-native/issues/new?assignees=&labels=Needs%3A+Triage+%3Amag%3A&projects=&template=bug_report.yml). Could you go back and make sure to fill out the template? You may edit this issue, or close it and open a new one.`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Environment Info':
awaitaddComment(
`| :warning: | Missing Environment Information |\n`+
`| --- | --- |\n`+
`| :information_source: | Your issue may be missing information about your development environment. You can obtain the missing information by running <code>react-native info</code> in a console. |`,
`> [!WARNING]`+
`> **Missing info**: It looks like your issue may be missing information about your development environment. You can obtain the missing information by running <code>react-native info</code> in a console.`,
);
awaitrequestAuthorFeedback();
return;
case'Newer Patch Available':
awaitaddComment(
`| :warning: | Newer Version of React Native is Available! |\n`+
`| --- | --- |\n`+
`| :information_source: | You are on a supported minor version, but it looks like there's a newer patch available - ${labelWithContext.newestPatch}. Please [upgrade](https://reactnative.dev/docs/upgrading) to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases. |`,
`> [!TIP]`+
`> **Newer version available**: You are on a supported minor version, but it looks like there's a newer patch available - ${labelWithContext.newestPatch}. Please [upgrade](https://reactnative.dev/docs/upgrading) to the highest patch for your minor or latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If it does not repro, please let us know so we can close out this issue. This helps us ensure we are looking at issues that still exist in the most recent releases.`,
);
return;
case'Needs: Version Info':
awaitaddComment(
`| :warning: | Add or Reformat Version Info |\n`+
`| --- | --- |\n`+
`| :information_source: | We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.70.2 |`,
`> [!WARNING]`+
`> **Could not parse version**: We could not find or parse the version number of React Native in your issue report. Please use the template, and report your version including major, minor, and patch numbers - e.g. 0.76.2.`,
);
awaitrequestAuthorFeedback();
return;
case'Needs: Repro':
awaitaddComment(
`| :warning: | Missing Reproducible Example |\n`+
`| --- | --- |\n`+
`| :information_source: | We could not detect a reproducible example in your issue report. Please provide either: <br /><ul><li>If your bug is UI related: a [Snack](https://snack.expo.dev)</li><li> If your bug is build/update related: use our [Reproducer Template](https://github.com/react-native-community/reproducer-react-native/generate)</li></ul> |`,
`> [!WARNING]`+
`> **Missing reproducer**: We could not detect a reproducible example in your issue report. Please provide either: <br/><ul><li>If your bug is UI related: a [Snack](https://snack.expo.dev)</li><li> If your bug is build/upgrade related: a project using our [Reproducer Template](https://github.com/react-native-community/reproducer-react-native/generate)</li><li>Otherwise send us a Pull Request with the [RNTesterPlayground.js](https://github.com/facebook/react-native/blob/main/packages/rn-tester/js/examples/Playground/RNTesterPlayground.js) edited to reproduce your bug.</li></ul>`,
);
awaitrequestAuthorFeedback();
return;
case'Type: Unsupported Version':
awaitaddComment(
`| :warning: | Unsupported Version of React Native |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue or the example you provided uses an [unsupported version of React Native](https://github.com/reactwg/react-native-releases/blob/main/README.md#releases-support-policy).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support. |`,
`> [!WARNING]`+
`> **Unsupported version**: It looks like your issue or the example you provided uses an [unsupported version of React Native](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support.`,
);
awaitrequestAuthorFeedback();
return;
case'Type: Too Old Version':
awaitaddComment(
`| :warning: | Too Old Version of React Native |\n`+
`| --- | --- |\n`+
`| :information_source: | It looks like your issue or the example you provided uses a [**Too Old Version of React Native**](https://github.com/reactwg/react-native-releases/blob/main/README.md#releases-support-policy).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support. |`,
`> [!CAUTION]`+
`> **Too old version**: It looks like your issue or the example you provided uses a [**Too Old Version of React Native**](https://github.com/reactwg/react-native-releases/blob/main/docs/support.md).<br/><br/>Due to the number of issues we receive, we're currently only accepting new issues against one of the supported versions. Please [upgrade](https://reactnative.dev/docs/upgrading) to latest and verify if the issue persists (alternatively, create a new project and repro the issue in it). If you cannot upgrade, please open your issue on [StackOverflow](https://stackoverflow.com/questions/tagged/react-native) to get further community support.`,
`| :information_source: | We could not detect a reproducible example in your issue report. Please provide either: <br /><ul><li>If your bug is UI related: a [Snack](https://snack.expo.dev)</li><li> If your bug is build/update related: use our [Reproducer Template](https://github.com/react-native-community/reproducer-react-native/generate). A reproducer needs to be in a GitHub repository under your username.</li></ul> |`;
body:`This pull request was successfully merged by ${authorName} in **${sha}**.\n\n<sup>[When will my fix make it into a release?](https://github.com/facebook/react-native/wiki/Release-FAQ#when-will-my-fix-make-it-into-a-release) | [Upcoming Releases](https://github.com/reactwg/react-native-releases/discussions/categories/releases)</sup>`
body:`This pull request was successfully merged by ${authorName} in **${sha}**\n\n<sup>[When will my fix make it into a release?](https://github.com/reactwg/react-native-releases/blob/main/docs/faq.md#when-will-my-fix-make-it-into-a-release) | [How to file a pick request?](https://github.com/reactwg/react-native-releases/blob/main/docs/faq.md#how-to-open-a-pick-request)</sup>`
});
// If the PR has already been processed (labeled as Merged), skip it
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:'This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-pr-message:'This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.'
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
stale-issue-message:"This issue is waiting for author's feedback since 24 days. Please provide the requested feedback or this will be closed in 7 days."
- name:Build the Helloworld application for ${{ matrix.flavor }} with Architecture set to ${{ matrix.architecture }}, and using the ${{ matrix.jsengine }} JS engine.
shell:bash
run:|
cd packages/helloworld/android
args=()
if [[ ${{ matrix.architecture }} == "OldArch" ]]; then
needs:[prepare_hermes_workspace, build_hermes_macos]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
needs:[prepare_hermes_workspace, build_hermes_macos]# prepare_hermes_workspace must be there because we need its reference to retrieve a couple of outputs
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.