Summary:
changelog: [internal]
`useLayoutEffect` has two guarantees which React Native breaks:
- Layout metrics are ready.
- Updates triggered inside `useLayoutEffect` are applied before paint. State between first commit and update is not shown on the screen.
React Native breaks the first guarantee because it uses Background Executor. Background executor moves Yoga layout to another thread. If user core reads layout metrics in `useLayoutEffect` hook, it is a race. The information might be there, or it might not. They can even read partially update information. This diff does not affect this. We already have a way to turn off Background Executor. We haven't done this because it introduces regressions on one screen but we have a solution for that.
React Native breaks the second guarantee. After Fabric's commit phase, Fabric moves to mounting the changes right away. In this diff, we queue the mounting phase and give React a chance to change what is committed to the screen. To do that, we schedule a task with user blocking priority in `RuntimeScheduler`. React, if there is an update in `useLayoutEffect`, schedules a task in the scheduler with higher priority and stops the mounting phase.
We are not delaying mounting, this just gives React a chance to interrupt it.
Fabric commit phase may be triggered by different mechanisms. C++ state update, surface tear down, template update (not used atm), setNativeProps, to name a few. Fabric only needs to block paint if commit originates from React. Otherwise the scheduling is wrong and we will get into undefined behaviour land.
Rollout:
This change is gated behind `react_fabric:block_paint_for_use_layout_effect` and will be rolled out incrementally.
Reviewed By: javache
Differential Revision: D43083051
fbshipit-source-id: bb494cf56a11763e38dce7ba0093c4dafdd8bf43
Summary:
changelog: [internal]
Passing MountingCoordinator argument by value instead of reference. Using reference does not make sense since we eventually take ownership of shared_ptr anyway. This better communicates the intent.
Reviewed By: christophpurrer
Differential Revision: D43082955
fbshipit-source-id: 29e20abb9824c10a5f0d5e0ba1049ff6d67cee98
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/35989
Test Plan:
This is a void function so testing is rather limited.
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
Reviewed By: NickGerleman
Differential Revision: D42801094
Pulled By: jacdebug
fbshipit-source-id: ede810fe9ee98f313fd3fbbb16b60c84ef8c7204
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. On iOS, when a UIScrollView (or its ancestor) is hidden, its scroll position is set to 0 (its window also becomes nil). When it is shown again, its scroll position is not restored.
When a scroll is attempted when the scroll view is hidden, we keep track of the last known offset before it was hidden. Then, in updateLayoutMetrics (which is triggered when the view is shown), we apply the pending offset if there is one. This is [consistent with Android's behavior in ReactScrollView.java](https://www.internalfb.com/code/fbsource/[2930f8c146af62ad63673c8d34e9876b77634c05]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=289).
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: cipolleschi
Differential Revision: D42815359
fbshipit-source-id: 4b209c1e54edf3f5c0bea902b48450a1a2e9661a
Summary:
I discovered that 0.69 and 0.70 could run React Native as Dynamic framework with JSC and starting from 0.71 that's not possible anymore.
This diff restore that possibility.
## Changelog
[iOS][Fixed] - Add Back dynamic framework support for the old architecture
Reviewed By: cortinico
Differential Revision: D42829137
fbshipit-source-id: 848672f714d8bab133e42f5e3b80202b350d5261
Summary:
Similar to the issue here https://github.com/facebook/react-native/pull/34503 but this is also happening if we just use `ScrollView` and `TextInput` with `automaticallyAdjustKeyboardInsets` enabled.
When we enable `Prefer Cross-Fade Transitions` in `iOS` we get a keyboard height of `0` which causes the inset/offset miscalculation and the content jumps up when the keyboard gets hidden.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Fix ScrollView `automaticallyAdjustKeyboardInsets` not resetting when Prefer Cross-Fade Transitions is enabled and keyboard hides
Pull Request resolved: https://github.com/facebook/react-native/pull/35933
Test Plan:
Tested with brand new react native project with/without the fix
before fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039873-33bfb016-f99f-4644-9174-20bf32cf07d6.mov
after fix `automaticallyAdjustKeyboardInsets` with enabled/disabled opening/closing keyboard
https://user-images.githubusercontent.com/6507800/214039887-4054a749-ab15-4399-b6a9-73dc9283aa6b.mov
Reviewed By: christophpurrer
Differential Revision: D42686390
Pulled By: jacdebug
fbshipit-source-id: 98488e0c9639c19a4acae1a1de1a5fde411e2462
Summary:
Fixed typo with the word "running" in 2 places when failing to open Flipper.
Fixes https://github.com/facebook/react-native/issues/35899 .
Changelog:
[Internal] [Changed] - Fix typo with the word "running" when failing to open Flipper
Pull Request resolved: https://github.com/facebook/react-native/pull/35910
Reviewed By: christophpurrer
Differential Revision: D42641042
Pulled By: sshic
fbshipit-source-id: acebb26ab921e98235c4f8e8535fa89be2ffa8cd
Summary:
Changelog: [IOS][ADDED] - Add explicit support for M2 iPad Apple Pencil hovering in the Pointer Events implementation
I personally am not a huge fan of how this has to be implemented but it's literally the way Apple suggests to differentiate between mouse and pen hover events.
Reviewed By: lunaleaps
Differential Revision: D40962916
fbshipit-source-id: a6fb5bcfe19bcf500021922baac3fa7c4375a874
Summary:
On Fabric, `onContentSizeChange` of `TextInput` component was never fired on `iOS`, since the logic dispatching it was implemented in `RCTBaseTextInputShadowView` on Paper: https://github.com/facebook/react-native/blob/0f8dc067ac079f7b14696cfcafa37e3ec19a0409/Libraries/Text/TextInput/RCTBaseTextInputShadowView.m#L105. This class is not used on Fabric, therefore the event was never dispatched. On Paper, it was dispatched in `dirtyLayout` method, so I added dispatching of this event based on the change of content size in `layoutSubviews` method, since this method seems the closest one on Fabric. I am not sure if it is the best place for it though.
## 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] - dispatch `onContentSizeChange` event on Fabric.
Pull Request resolved: https://github.com/facebook/react-native/pull/35816
Test Plan:
Try to use `onContentSizeChange` callback in `TextInput` component:
```tsx
import React from 'react';
import {TextInput, SafeAreaView} from 'react-native';
const App = () => {
return (
<SafeAreaView style={{flex: 1, backgroundColor: 'red'}}>
<TextInput
multiline={true}
placeholder="type here"
onContentSizeChange={e => console.log(e)}
/>
</SafeAreaView>
);
};
export default App;
```
Reviewed By: christophpurrer
Differential Revision: D42499974
Pulled By: sammy-SC
fbshipit-source-id: 3e010ff096cf91cb3e7b87ed2753e9d0e7be9650
Summary:
This PR implements logical border-radius as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `borderEndEndRadius`, equivalent to `borderBottomEndRadius`.
- `borderEndStartRadius`, equivalent to `borderBottomStartRadius`.
- `borderStartEndRadius`, equivalent to `borderTopEndRadius`.
- `borderStartStartRadius`, equivalent to `borderTopStartRadius`.
## Changelog
[GENERAL] [ADDED] - Add logical border-radius implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/35572
Test Plan:
1. Open the RNTester app and navigate to the `RTLExample` page
2. Test the new style properties through the `Logical Border Radii Start/End` section
https://user-images.githubusercontent.com/11707729/206623732-6d542347-93f9-40da-be97-f7dcd5f66ca9.mov
Reviewed By: necolas
Differential Revision: D42002043
Pulled By: NickGerleman
fbshipit-source-id: a0aa9783c280398b437aeb7a00c6eb3f767657a5
Summary:
On iOS 13.0+, app may use SceneDelegate for multiple windows support or CarPlay support. RCTAlertController can't find the correct root vc in such scene based apps.
## 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 RCTAlertController not showing when using SceneDelegate on iOS 13.0+.
Pull Request resolved: https://github.com/facebook/react-native/pull/35716
Reviewed By: cipolleschi
Differential Revision: D42253653
Pulled By: makovkastar
fbshipit-source-id: ae4e833abca2af7af8028f3af9bd8d3f60ebd392
Summary:
Repair when RCTRedBoxGetEnabled is false , the red box will still be on display，It resolve that I send test-pack to QA with Xcode Archive on DEBUG env.
## Changelog
[General] [Changed] - Append RCTRedBoxGetEnabled() in RCTExceptionsManager.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/35576
Test Plan: Xcode Archive on DEBUG env, the red box will be not on display.
Reviewed By: cipolleschi
Differential Revision: D41809649
Pulled By: skinsshark
fbshipit-source-id: 7d6be3479decf369c415f6a08dec9611b1441b1d
Summary:
Enhancing native iOS modules and preventing crashes inside the RCTAlertController
## Changelog
[iOS][Fixed] - Handle properly a `nil` `keyWindows` in the AlertController
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
Pull Request resolved: https://github.com/facebook/react-native/pull/35689
Reviewed By: cipolleschi
Differential Revision: D42179169
Pulled By: ryancat
fbshipit-source-id: 05a6788f610db1d222e3c10b3c774c75edaf55f5
Summary:
[Changelog][Internal]
Both iOS and Android platforms are at this point using the same native implementation of `performanceNow`, based on `std::chrono` (it used to be different some time ago).
This diff unifies the implementations, so it comes from one place in C++ code for all platforms.
The context is that I am developing event timing instrumentation and need a consistent way to get current timestamp from either JS or native (C++) side. The latter is now possible via calling `JSExecutor::performanceNow()`, which is guaranteed to be the same as called from JS.
Reviewed By: christophpurrer
Differential Revision: D42267898
fbshipit-source-id: dcb592f37d6567340ea59faddbf3b6d2b8507d50
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
Changelog:
[iOS][Changed] - Create a new compile time flag to enable remote sample profiling.
Reviewed By: cortinico
Differential Revision: D41554133
fbshipit-source-id: 00a7f9f6c9f09d72afee070c1cc6187aa3d0ddb1
Summary:
changelog: Introduce setNativeProps to Fabric
Add support for `setNativeProps` in Fabric for backwards compatibility. It is still recommended to move away from `setNativeProps` because the API will not work with future features.
We can make step [Migrating off setNativeProps](https://reactnative.dev/docs/new-architecture-library-intro#migrating-off-setnativeprops) in migration guide optional.
Reviewed By: yungsters, mdvacca
Differential Revision: D41521523
fbshipit-source-id: 4d9bbd6304b8c5ee24a36b33039ed33ae1fc21f8
Summary:
Changelog: [Internal]
Codemod-bot already hardcoded this to false a while back, so cleaning up the code related to it.
Reviewed By: RSNara
Differential Revision: D41615378
fbshipit-source-id: 7b62b20b8e25f0a06d207b2457d6caf9ad5c695e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35482
This change moves the JSCRuntime.h/cpp into a `jsc` folder.
This change is required for several reasons:
1. on iOS, the new `jsi`, `jsidynamic` and `jsc` setup is breaking the `use_frameworks!` with `:linkage => :static` option with the old architecture. So it is a regression.
2. JSCRuntime is required by some libraries and needs to be exposed as a prefab and the current setup makes it hard to achieve.
allow-large-files
## Changelog:
[General][Changed] - Move JSCRuntime into a separate pod/prefab
Reviewed By: cortinico
Differential Revision: D41533778
fbshipit-source-id: 642240c93a6c124280430d4f196049cb67cb130b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35436
Using std::optional as react-native has been using C++17 for quite some time
changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D41415031
fbshipit-source-id: d786647f64b4f90cf75409109830ae0885460c17
Summary:
X-link: https://github.com/pytorch/pytorch/pull/89233
The `-weak_framework` flag is no longer necessary, Buck will weakly link frameworks depending on the `target_sdk_version` of the binary being linked.
Reviewed By: ebgraham, malfet
Differential Revision: D41348639
fbshipit-source-id: 47992282ba030294b2304c550d49df13e24e9c79
Summary:
UIRefreshControl has a tight integration with iOS in terms of UINavigationBar/UIScrollView. In this regard, whenever there's a UIScrollView with a UINavigationBar on top, the OS automatically adjusts the contentInset of the UIScrollView to reflect that (something that is exposed to React Native). In a similar manner, UIScrollView passes this along to the attached UIRefreshControl.
By setting the frame manually, the RCTRefreshControl component was preventing this behavior. Although having the option is desired, it should not be done by default. In the past it was possible to adjust for this by manually setting the correct value, calculating the statusBar's height/safeAreaInsets.top and appending 44pt (the UINavigationBar height). However, due to changes related to the Dynamic Island (see [here](https://useyourloaf.com/blog/iphone-14-screen-sizes)), the safe area and the status bar size no longer align, making this calculation more tricky.
In summary: this changes allows `progressViewOffset` to exist (in order to maintain feature parity with Android) but provides the opportunity for the OSs default behavior to kick in when applicable.
| Applying by default | Not applying by default (this change) |
:-------------------------:|:-------------------------:
 | 
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Fix application of _progressViewOffset in RCTRefreshControl to not occur by default (when value is unset)
Pull Request resolved: https://github.com/facebook/react-native/pull/35281
Test Plan: The GIFs attached display the behavior as expected/unexpected. I'm unaware of any tests written for RCTRefreshControl that could be improved to cover this change. Notes appreciated.
Reviewed By: sammy-SC
Differential Revision: D41302080
Pulled By: cipolleschi
fbshipit-source-id: a2a8e6ef1dcc2e73220c2a182b4516f3bbd94f60
Summary:
Fix linter warning when pulling in some code into AR
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D41269423
fbshipit-source-id: 4305d6c362a51e62b19b4d3590fb0823073dff9a
Summary:
This change puts back D40716048 (https://github.com/facebook/react-native/commit/279cfec55fdf404fdb9198edbb37d3adfdfb3bf1) but in the right way, i.e. modifying the script that should generate those changes.
## Changelog
[iOS][Added] - Make the blobs proper TM
Reviewed By: dmytrorykun
Differential Revision: D41312160
fbshipit-source-id: 38850a63eb8d66ffd179743b4948a23340c8782e
Summary:
changelog: [internal]
Removing this to decrease clutter of warnings when devs navigate to Marketplace Home.
Reviewed By: cipolleschi
Differential Revision: D41306378
fbshipit-source-id: a1b7f8ebe1f4bb00e931d609eb97a3bbd5ef9052
Summary:
Cherry pick https://github.com/microsoft/react-native-macos/commit/e877ebfe083ffaa252738477098322504492f4be from React Native macOS into React Native Core. We've had this bug fix in our fork for a while now, so it's probably safe.
=== Original change notes ===
First, misc straightforward deprecated API updates.
Second, defensive changes to potentially address RCTDisplayLink crash.
Real-world data suggests crashes with this stack:
CVDisplayLink::start()
-[RCTDisplayLink updateJSDisplayLinkState] (RCTDisplayLink.m:157)
-[RCTDisplayLink registerModuleForFrameUpdates:withModuleData:]_block_invoke (RCTDisplayLink.m:67)
-[RCTTiming timerDidFire] (RCTTiming.mm:324)
-[_RCTTimingProxy timerDidFire] (RCTTiming.mm:93)
Some symbols are missing in this stack, presumably due to compiler optimizations.
-updateJSDisplayLinkState is calling CVDisplayLinkStart as a result of a
call to "_jsDisplayLink.paused = NO".
-registerModuleForFrameUpdates block is presumably getting called via pauseCallback,
likely via [RCTTiming startTimers], presumably owned by RCTCxxBridge.
The most likely immediate explanation for the crash is that we are calling
CVDisplayLinkStart with a zombie _displayLink pointer.
However there is a lot of indirection here as well as thread-hopping, and
unfortunately no clearly incorrect code that would explain such a zombie pointer.
Some defensive changes:
-explicitly remove the association to pauseCallback when underlying display link object is invalidated.
-remove a prior attempt at additional check in updateJSDisplayLinkState itself as it is not relevant.
-make sure we explicitly set _displayLink to NULL when we release it, such that there is one less failure point.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - RCTDisplayLink fix plus bonus deprecated API cleanup
Pull Request resolved: https://github.com/facebook/react-native/pull/35359
Test Plan: CI should pass.
Reviewed By: cipolleschi
Differential Revision: D41335438
Pulled By: christophpurrer
fbshipit-source-id: 5e97d28eab7dd8e5c81d0a5386df6631e16405a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35315
These headers are needed on react-native-macOS, but not explicitly imported all the time.
It seems that some UIKit header will implicitly import them.
We have other use case in react-native(-iOS) in which we also explicitly importing them - https://github.com/facebook/react-native/search?q=QuartzCore- , hence use following 'that' practice 'here'.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D41229835
fbshipit-source-id: b0182bf4f7905e8e157b341eb62cadec6ba354ca
