Summary:
Respect `cancelsTouchesInView` property when deciding whether to cancel touches in `RCTSurfaceTouchHandler`
## Motivation
Currently, `RCTSurfaceTouchHandler` unconditionally cancels touches whenever `canBePreventedByGestureRecognizer:` returns `YES`, regardless of the other gesture recognizer's `cancelsTouchesInView` property:
```objc
if (canBePrevented) {
[self _cancelTouches]; // Always cancels!
}
```
This creates an issue when developers add custom gesture recognizers to ancestor views of React Native view controllers with `cancelsTouchesInView = NO`. Even though the developer explicitly indicates they don't want to cancel touches in the view hierarchy, RCT still cancels them.
**Example scenario:**
```objc
// Custom gesture recognizer added to parent view
UIPanGestureRecognizer *customGesture = [[UIPanGestureRecognizer alloc] init...];
customGesture.cancelsTouchesInView = NO; // Explicitly not canceling touches
[parentView addGestureRecognizer:customGesture];
// But RCTSurfaceTouchHandler still cancels touches unconditionally
```
This breaks the intended behavior where `cancelsTouchesInView = NO` should allow both the gesture and underlying touch handlers to work together.
In our case, React Native is used in a brownfield setup inside an existing iOS application.
When a new React Native–powered view controller is presented, we attach additional gesture recognizers on ancestor view controllers to track LCP (Largest Contentful Paint) and other performance metrics. These gesture recognizers are configured with `cancelsTouchesInView = NO` because they are intended to observe gestures without interfering with the existing touch handling in the React Native view hierarchy.
However, due to the current behavior in `RCTSurfaceTouchHandler`, any time these tracking gesture recognizers can prevent the React Native touch handler, all touches inside the React Native hierarchy are still cancelled, even though `cancelsTouchesInView` is explicitly set to `NO`. In practice this makes `Pressable` and other touchables stop responding as soon as the tracking gesture begins recognizing.
We have been maintaining a local patch equivalent to this change in our production app to restore the expected UIKit behavior. This PR upstreams that fix so that brownfield integrations and other setups that rely on `cancelsTouchesInView = NO` can work correctly without custom patches.
## Changes
Modified the condition to check `otherGestureRecognizer.cancelsTouchesInView` before canceling touches:
```objc
- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer
shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
BOOL canBePrevented = [self canBePreventedByGestureRecognizer:otherGestureRecognizer];
if (canBePrevented && otherGestureRecognizer.cancelsTouchesInView) {
[self _cancelTouches];
}
return NO;
}
```
## Why This Change Is Correct
1. **Respects UIKit conventions**: The `cancelsTouchesInView` property is the standard UIKit way to control whether a gesture recognizer cancels touches. This change honors that contract.
2. **Preserves original intent**: The original fix (a9bc385) was designed to cancel touches during interactive view controller dismissal. Since system gesture recognizers use `cancelsTouchesInView = YES` by default, this behavior is preserved.
3. **Enables flexible gesture composition**: Developers can now explicitly control whether their custom gestures should cancel RN touches by setting `cancelsTouchesInView` appropriately.
4. **Logical consistency**: "Only cancel touches when the other gesture recognizer intends to cancel touches" is more semantically correct than "always cancel when preventable."
[iOS] [Fixed] - Respect cancelsTouchesInView when canceling touches in RCTSurfaceTouchHandler
Pull Request resolved: https://github.com/facebook/react-native/pull/54755
Test Plan:
**Existing behavior (should remain unchanged):**
- Interactive view controller dismissal still cancels Pressable highlights
- Standard UIKit gesture recognizers (pan, swipe, etc.) work as before
**New behavior (fixes the issue):**
1. Add a custom gesture recognizer to an ancestor view with `cancelsTouchesInView = NO`
2. Verify that React Native touchables/Pressables continue to respond to touches
3. Verify that the custom gesture and RN touch handlers can work simultaneously
**Testing:**
```objc
// Test case: Custom gesture with cancelsTouchesInView = NO
UIPanGestureRecognizer *customGesture = [[UIPanGestureRecognizer alloc] initWithTarget:self action:selector(handlePan:)];
customGesture.cancelsTouchesInView = NO;
[self.view addGestureRecognizer:customGesture];
// Expected: Both customGesture and RN Pressable should respond
```
## Changelog:
[iOS] [Fixed] - Respect `cancelsTouchesInView` when canceling touches in `RCTSurfaceTouchHandler`
Reviewed By: fabriziocucci
Differential Revision: D88174531
Pulled By: javache
fbshipit-source-id: ed058791a4eef7401fd7198d4c8a2515a6b6b752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54774
NOTE: This diff is a backport of https://github.com/facebook/react-native/pull/54770, where on the `0.83-stable` release branch, Network support for React Native DevTools was in a broken state under the open source build systems.
### Cause
Network debugging support depends a number of `REACT_NATIVE_DEBUGGER_ENABLED` preprocessor flags, which we use to compile away any overhead in production builds.
As we unfortunately use a total of **4 native build systems** today (with Buck 2 internally and primarily), the registration of these flags was missing across a number of native ObjC/C++ packages, which are now fixed with this PR.
- D87864636 aimed to address this as we weren't seeing the Network panel at all. However, it was insufficient, as it has only partially enabled network features between platforms.
### This diff
Add missing preprocessor flags in:
- Android:
- `src/main/jni/react/devsupport/CMakeLists.txt`
- `src/main/jni/CMakeLists.txt`
- iOS (Pods):
- `React-jsinspectorNetwork`
- iOS (`Package.swift`):
- `Libraries/Network`
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D88284345
fbshipit-source-id: 8ff0b424834b40ed186432f630287abe5fe8b997
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54769
# Changelog: [Internal]
In Chrome, this event has `disabled-by-default-devtools.timeline` category. This also implies that this event won't be displayed on a timeline by default, which is what we want.
Reviewed By: sbuggay
Differential Revision: D88274243
fbshipit-source-id: c8f3dc1546fdff7219a293a4a559bbb70dc2d4f1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54765
# Changelog: [Internal]
Looking at the Chrome DevTools Frontend code, the `BeginFrame` trace event represents the actual start of the frame sequence, not the expected one.
Using inteded timestamp doesn't seem right here:
- [INTENDED_VSYNC_TIMESTAMP](https://developer.android.com/reference/android/view/FrameMetrics#INTENDED_VSYNC_TIMESTAMP)
- [VSYNC_TIMESTAMP](https://developer.android.com/reference/android/view/FrameMetrics#VSYNC_TIMESTAMP)
INTENDED_VSYNC_TIMESTAMP description says:
> The intended start point for the frame. If this value is different from VSYNC_TIMESTAMP, there was work occurring on the UI thread that prevented it from responding to the vsync signal in a timely fashion.
Reviewed By: sbuggay
Differential Revision: D88088882
fbshipit-source-id: 0980c4952b7b71dd8ea2333334f0ed89f6ecedb1
Summary:
When two different React Native libraries export a package class with the same name but in different namespaces, the generated PackageList.java causes a compilation error due to ambiguous class references.
The current autolinking generates:
``` kotlin
import com.pikachu.NativeStorage;
import com.snowfox.NativeStorage; // ❌ Compile error: NativeStorage is already defined
public ArrayList<ReactPackage> getPackages() {
return new ArrayList<>(Arrays.<ReactPackage>asList(
new MainReactPackage(mConfig),
new NativeStorage(), // ❌ Ambiguous reference
new NativeStorage() // ❌ Ambiguous reference
));
}
```
Solution:-
Use fully qualified class names (FQCN) instead of imports:
``` kotlin
// No imports needed
public ArrayList<ReactPackage> getPackages() {
return new ArrayList<>(Arrays.<ReactPackage>asList(
new MainReactPackage(mConfig),
// pikachu-storage
new com.pikachu.NativeStorage(),
// snowfox-storage
new com.snowfox.NativeStorage()
));
}
```
## 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]- Use FQCN to avoid collisions
Pull Request resolved: https://github.com/facebook/react-native/pull/54736
Test Plan:
Updated test.
Also tested on my app and RN tester
<img width="687" height="223" alt="image" src="https://github.com/user-attachments/assets/fe54d0c3-4ab4-4d74-a98f-97243851e8c4" />
CI will tell if build fails
Reviewed By: mdvacca
Differential Revision: D88157961
Pulled By: cortinico
fbshipit-source-id: 5fe072dcaed177af1036ca88d55870081a3f4205
Summary:
This replaces `glob@^7.0.0` with `tinyglobby@^0.2.15`. `glob@7` has been deprecated for a while and some versions after had security notices released for them. The plan is to backport this PR to `0.81.x` and onwards.
> [!NOTE]
> This is a stopgap solution until `fs.glob` becomes generally available with the EOL of Node v20
Succeeds:
- https://github.com/facebook/react-native/issues/54669
- https://github.com/facebook/react-native/issues/48875
## Changelog:
[GENERAL] [SECURITY] - Replace `glob@^7.0.0` with `tinyglobby@^0.2.15`
Pull Request resolved: https://github.com/facebook/react-native/pull/54737
Test Plan:
- Ran all modified commands manually and `pod install in `rn-tester`
- NOTE: `ios-prebuild`-related scripts haven't been run manually yet
Reviewed By: robhogan
Differential Revision: D88069145
Pulled By: huntie
fbshipit-source-id: 0c455342a4c6d1d6605fd09fe47b418e5d751491
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54740
## Changelog:
[Internal] [Changed] - Remove feature flag cxxNativeAnimatedRemoveJsSync
It's always rolled out with cxx animated and we haven't found new issues with it
Reviewed By: lenaic
Differential Revision: D88082232
fbshipit-source-id: 3b9f29c20a7f41cd1d826257a9e2c42c11fcee0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/52624
Add a new optional interface `ISerialization` to JSI. This interface
contains four APIs to clone objects from one runtime to another runtime.
Four methods are introduced in this interface:
* `serialize`: Takes in a JS value (represented by `jsi::Value`) and
serialize the value into an opaque `Serialized` object.
* `deserialize`: Takes in the `Serialized` object created by `serialize`
and deserialize it into the runtime, returning the created JS value.
* `serializeWithTransfer`: Takes in a JS value (represented by
`jsi::Value`) and a `transferList` (a `jsi::Array` of `jsi::Value`s).
This will serialize the `value` into an opaque `Serialize` object and
transfer the ownership of everything in `transferList` into the
`Serialized` object. If any non-transferable values is passed into the
transferList, this will throw. This `Serialized` object must only be
deserialized once.
* `deserializeWithTransfer`: Takes in the `Serialized` object created by
`serializeWithTransfer`. It will deserialize the object into the runtime
and any value owned by the `Serialized` object will now be owned by the
current runtime. It will return an `jsi::Array` where the first value is
the deserialized value passed into `serializeWithTransfer`, followed by
all transferred values.
The lifetime of the `Serialized` object created from the APIs is
independent of the original object and runtime.
Note that objects can only be copied into another runtime instance of
the same type. For example, a serialized object produced by the Hermes
runtime can only be deserialized by another Hermes runtime.
Changelog: [Internal]
Reviewed By: dannysu, fbmal7
Differential Revision: D76547681
fbshipit-source-id: 0c774f3f469c26d3894cac179f4ce5e32cf5ad7f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54756
Move blanket `packages/**/dist/` rule added in D77591742 into scoped `.gitignore` for `debugger-shell`.
This was preventing new files added to `packages/debugger-frontend/dist/` from being staged.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D88172611
fbshipit-source-id: 428fffd46f5f76ddf422a41b57e7b47446c40e43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54754
Enables the standalone app shell for React Native DevTools by default.
We preserve + document this flag as an opt-out (allowing Frameworks to override this behaviour if needed).
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D88161573
fbshipit-source-id: 64ee191dcead4e639bb3067bc9e715b1c8cdf80d
Summary:
Those stacktraces are no longer necessary because venice has been rolled out to 100% since a long time. They create noise on logcat as they appear as a crash in red, but they're not.
Created from CodeHub with https://fburl.com/edit-in-codehub
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D88075839
fbshipit-source-id: 83f2c5fe6b3e500c5a0dc12a81ded394b5fca31a
Summary:
Adds support for transform, border radius, and background color props to be handled by shared animation backend.
[General][Added] - Added support for transform, border radius, and background color props to Animation Backend.
## 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]
Pull Request resolved: https://github.com/facebook/react-native/pull/54698
Test Plan: Checked on reanimated example app.
Reviewed By: zeyap
Differential Revision: D87922886
Pulled By: coado
fbshipit-source-id: 1fe554cba514b74c3687f09be0def0496e4c374a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54743
Instead of creating another buffer, optionally include screenshots if they are enabled in `FrameTimingSequence`.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D87936871
fbshipit-source-id: c35ef7776f6f51281213664f98e13db0a2bbab42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54747
Cleans up the `enableVirtualViewClippingWithoutScrollViewClipping` feature flag and enables the new behavior.
Changelog:
[Android][Changed] - `VirtualView` not clips subviews even if its parent `ScrollView` does not have `removeClippedSubviews` enabled.
Reviewed By: lunaleaps
Differential Revision: D88096820
fbshipit-source-id: d61061f3612b048ed22be33f48e24511c7e010d2
Summary:
# Fix NullPointerException in PromiseImpl.reject
This PR fixes a `NullPointerException` that occurs when `Promise.reject` is called with a `null` code from Java native modules.
The issue arises because `Promise.kt` and `PromiseImpl.kt` defined the `code` parameter as non-nullable `String` in several overloads. However, `PromiseImpl`'s internal logic (specifically the catch-all `reject` method) is designed to handle `null` codes by defaulting to `EUNSPECIFIED`.
When a Java module (such as `react-native-ble-plx`) calls `promise.reject(null, message)`, Kotlin's generated null-checks throw a `NullPointerException` before the method body is executed.
## Changelog
[Android] [Fixed] - Allow nullable `code` in `Promise.reject` to prevent NPEs from Java modules
Pull Request resolved: https://github.com/facebook/react-native/pull/54731
Test Plan:
1. Create a native module in Java that calls `promise.reject(null, "Error message")`.
2. Before this fix, the app crashes with `java.lang.NullPointerException: Parameter specified as non-null is null: method com.facebook.react.bridge.PromiseImpl.reject, parameter code`.
3. After this fix, the promise is rejected with code `EUNSPECIFIED` and the app does not crash.
## Related Issue
Fixes https://github.com/facebook/react-native/issues/54722
Reviewed By: fabriziocucci, cortinico
Differential Revision: D88066375
Pulled By: javache
fbshipit-source-id: aec56b2d44dc8260e9b0496c2ec5fc49e70ca9cf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54730
I'm deleting those 2 classes related to layout animation. They were needed only for legacy arch.
They're not needed anymore so they can go now.
Marked as breaking because those 2 classes were public, but I wasn't able to find meaningful usages in OSS
Changelog:
[Android] [Breaking] - Remove unnecessary classes inside `com.facebook.react.uimanager.layoutanimation` used in legacy architecture
Reviewed By: javache
Differential Revision: D88011209
fbshipit-source-id: a45ec8342a2cdd150264ff9de9da7060b93bf55c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54723
Changelog: [iOS][Fixed] - Fixed crashing due to FastRefresh not being initialized for non debug builds with RCT_DEV_MENU=1
Reviewed By: robhogan
Differential Revision: D87982434
fbshipit-source-id: 0832ba02e0b82a1932b8532dc2874b48d33de66d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54704
This class is coming from Legacy Architecture and is no longer used so can be cleaned up.
Changelog:
[Internal] [Changed] -
Reviewed By: mdvacca
Differential Revision: D87925037
fbshipit-source-id: 30faffef0da2b7055a6d381b41dc72bead2dd8de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54651
Break up ReactHost and TurboModuleManager, so in the future we can inject this more easily.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D87774276
fbshipit-source-id: 02a896d66e3ab3c7fa01c383779aaa3a73aa39b8
Summary:
`jsi.h` uses types like `uint32_t` but never includes `<cstdint>`.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D87953504
fbshipit-source-id: 7d10e458ff14b01da293f2714d6a562958f9e8ff
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54706
Changelog:
[iOS][Fixed] - remove redundant gesture to tap button when the layer beneath is already tappable
The dismiss button had a redundant tap handler when the entire banner was already tappable.
**Redundant button interaction**: The dismiss button's `primaryAction` was removed and `userInteractionEnabled` is set to `NO`, making it purely visual. Taps on the button now pass through to the banner's tap gesture recognizer.
Reviewed By: vzaidman
Differential Revision: D87927449
fbshipit-source-id: af7dabff6f2ea23124d44bd21e82c789176f3acf
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54702
Changelog:
[iOS][Fixed] - Make rest of app responsive whilst dev loading banner present
The dev loading banner window was previously full-screen height, making the entire screen unresponsive to touches even though only a small banner was visible.
The window frame is now calculated after Auto Layout completes, ensuring it matches the actual content height (label + padding + safe area). This allows the rest of the screen below the banner to remain interactive.
The banner now only blocks interactions within its actual bounds
Reviewed By: vzaidman
Differential Revision: D87922708
fbshipit-source-id: d46d05915b5d91e269f1a53bca2a8bbdffb3267a
Summary:
Resolves https://github.com/facebook/react-native/issues/53240
Resolves an Android-only issue where a top-level `<Text role="link">Link Text</Text>` would generate two accessibility (screen reader) focus steps:
1. "Link Text. Link. Links available, use tap with 3 fingers to view."
2. "Link Text. Link. Double-tap to activate."
This behavior was inconsistent with iOS behavior, which generated a single screen reader step, resulting in a poor user experience due to unnecessary repetition of information.
This PR resolves the issue in a way that allows mixing plain text and links while still yielding additional focus steps for nested links if there is any other text present or if there are multiple links.
## Android after
https://github.com/user-attachments/assets/646b64af-a7eb-4b28-8735-546b9909a510
## Android before
https://github.com/user-attachments/assets/43bd9ee9-890f-43ca-9363-ade8b45dea27
## iOS (for comparison)
https://github.com/user-attachments/assets/807d1771-e3e7-4dca-9409-7697d1a0cb9c
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
[ANDROID] [FIXED] a11y: prevent redundant double screen reader focus steps on `<Text role="link">`
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/54515
Test Plan: Open RN Tester on "Text with link role" example and test with screen reader.
Reviewed By: cipolleschi
Differential Revision: D87464727
Pulled By: joevilches
fbshipit-source-id: a69df5b63128886ea5c45b22e068d455ee808c0f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54656
## Changelog:
[Android] [Fixed] - emit scroll event once on overscrolled
when FeatureFlag `shouldTriggerResponderTransferOnScrollAndroid` is on, RN Renderer relies on scroll event dispatched from JS to terminate responder - this is a behavior consistent with ios
however at overscroll, ios will still keep emitting topScroll but android will stop. This result in a regression on android, which is that a Tap will always go through when end is reached for a scrollview. Solution here is to emit one scroll event at overscroll
* here we're not emitting endlessly to avoid performance regression
* another nuance is android's 'onOverScrolled' will keep being called whenever there's overscroll gesture, but scrollX/Y value stays the same; while on ios, during a overscroll the scrollview actually scrolls the content so scrollX/Y have meaningful values. Because of this I think it makes no sense to keep dispatching scroll event to js on android at overscroll.
Reviewed By: sammy-SC
Differential Revision: D87657147
fbshipit-source-id: 3f8521c25af41c9917e0c7d3463b180b86730f9e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54705
This class is no longer necessary as it was used by Legacy Architectrue.
It can now be removed.
I'm marking this as breaking because this class is public, however I could not find any meaningful
usage in Open Source so I suspect no impact for users.
Changelog:
[Android] [Breaking] - Remove unnecessary `LazyReactPackage` used in legacy architecture
Reviewed By: javache
Differential Revision: D87927749
fbshipit-source-id: 82cbd6e12f13edaf6f7989fbcc066399fe548420
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54708
Changelog:
[Android][Fixed] - Fix isClickable state for TextViews after recycling
This change ensures TextViews don't have `isClickable=true` by default when views are recycled. Setting `isClickable=true` on TextViews semantically implies they should occlude what's behind them, which is only correct when the text has a click listener attached.
Reviewed By: cortinico
Differential Revision: D87927350
fbshipit-source-id: e6ef25996213c5ca0a2b7f5435a193a480b48cb4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54709
Changelog:
[Android][Fixed] - Fix isClickable state for TextViews based on onClickListener
This change improves the readability and correctness of the `configureClickableState` method in `BaseViewManager.java`.
**Previous behavior**: TextViews were treated the same as all other non-ReactPointerEventsView views.
**New behavior**: The logic is now clearer:
- For `TextView`: `shouldBeClickable` is set based on whether the view has onClickListeners (prevents TextViews without click handlers from being marked as clickable)
- For `ReactPointerEventsView`: Uses the existing `canBeTouchTarget()` check
- For all other views: Defaults to `true`
This ensures that TextViews are only marked as clickable when they actually have a click listener attached, which is more semantically correct for accessibility and user interaction.
Reviewed By: cortinico
Differential Revision: D87919507
fbshipit-source-id: 8595b1a10dc07ca305a099627a1c438a3912b865
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54685
This interface is no longer necessary.
It was used in legacy arch to communicate between `UIManagerModule` and `NativeModuleRegistry`
This interface was public so I'm marking this as breaking, but I was not able to find any usage in OSS for this interface.
Changelog:
[Android] [Removed] - Remove unnecessary `OnBatchCompleteListener` used in Legacy Architecture
Reviewed By: javache
Differential Revision: D87866148
fbshipit-source-id: 49212da16509c8012faaf69152ca6be6990f92e4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54697
This is just a follow-up from the previous NPE fix. I'm adding a couple of
tests for the affected method.
Changelog:
[Internal] [Changed] -
Reviewed By: javache
Differential Revision: D87920989
fbshipit-source-id: fba47365bbb8c94240d3daf11cf4226bfaf701d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54684
This diff removes the `RCTTurboModuleSyncVoidMethodsEnabled` feature flag and all related code that allowed TurboModule void methods to execute synchronously.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D87865883
fbshipit-source-id: fa64e8105e8329a0b20bb1718dbc01b17464cd06
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/54696
Changelog: [iOS][Fixed] - Fixed dismiss button not appearing consistently in dev loading view
D87465522 introduced lazy initialization to reuse views across multiple `showMessage` calls for better performance. However, this exposed two bugs:
1. **Missing button bug**: Button creation was inside the `if (self->_container == nullptr)` block, which now only executes once. If the first call had `dismissButton=NO`, subsequent calls with `dismissButton=YES` would skip button creation since the container already existed.
2. **Button text wrapping bug**: The button didn't have compression resistance priority set, so Auto Layout could compress it to fit the layout, causing the text to wrap.
This fixes both issues by:
- Moving button creation/removal logic outside the container initialization so it runs on every call and dynamically adds or removes the button based on the current `dismissButton` parameter
- Setting compression resistance and content hugging priorities on the button to prevent it from being compressed, forcing the message label to wrap instead
- Resetting all UI elements in `hide()` to ensure clean state between loading sessions
The performance optimization from D87465522 is preserved - views are still reused during rapid Metro progress updates.
Reviewed By: javache
Differential Revision: D87870932
fbshipit-source-id: 052d4a0685ee288e3b4bf974b203e4f29c652436
Sam Zhou