Summary:
By leveraging the `PUBLIC_HEADERS_FOLDER_PATH` build settings of Xcode, we can instruct cocoapods to generate the frameworks Headers in a specific folder, for example the `React` folder.
This allows us to maintain the `#include`/`#import` structure, even if the framework has a different name.
However, we need to update the search paths to take into account this extra folder.
## Changelog:
[iOS][Changed] - Generate RCTFabric framework's headers in the React folder
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43425677
fbshipit-source-id: 94a4f3a3c7de86341b3ce3457704e6b8fb9a588e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36210
One of the circular dependencies we have in OSS was between React-Codegen and React-Fabric.
React-Codegen generates component which has to depends on React-Fabric because they need to use the files contained in the `react/renderer/view` folder.
React-Fabric contains some components that depends on RNCore, which was generated inside the React-Codegen folder.
This change generates the RNCore components inside the `ReactCommon/react/renderer/components/rncore` folder, breaking the dependency as `rncore` folder is now contained by React-Fabric itself.
**Fun Fact:** That's how it always should have been. There was already a line in the `.gitignore` to exclude the content of `ReactCommon/react/renderer/components/rncore` folder. I guess that with some of the refactoring/previous projects on Codegen, this requirements has slipped.
## Changelog:
[iOS][Breaking] - generates RNCore components inside the ReactCommon folder and create a new pod for platform-specific ImageManager classes
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43304641
fbshipit-source-id: ebb5033ce73dbcd03f880c3e204511fdce04b816
Summary:
Update podspecs with the right search paths to include the required framework by every module.
## Changelog:
[iOS][Changed] - Update search paths to support `use_frameworks!` with Fabric
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089372
fbshipit-source-id: 4bbfc4b98bd289d66ce4015429d581856d9c05b3
Summary:
This change solve a Circular Dependency where
- `React-Core` depends on `ReactCommon` because `RCTAppSetupUtils.h` (in Core) imports the `RCTTurboModuleManager` (from ReactCommon)
- `RCTTurboModuleManager` in `ReactCommon` depends on `React-Core` because it imports several classes from it (e.g. the `RCTBridge` class)
## Changelog:
[iOS][Breaking] - Moved the RCTAppSetupUtils to the AppDelegate library to break a dependency cycle
Reviewed By: sammy-SC, dmytrorykun
Differential Revision: D43089183
fbshipit-source-id: d7fc36a50811962caf7cff77bb45d42b8cdd4575
Summary:
changelog: [iOS][Fixed] Fix a crash when reloading JS bundle
Do not crash if self is nil.
Reviewed By: blakef
Differential Revision: D43352039
fbshipit-source-id: dd53677ca152d4021e43ed8d0f1b51c071ca3365
Summary:
changelog: [internal]
C++17 has implementation of shared_mutex in standard library. Let's use it instead of folly.
Reviewed By: cipolleschi
Differential Revision: D43275493
fbshipit-source-id: d766251226aa230110011aca94b4e697fe0d31a1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36161
Changelog:
[iOS][Fixed] - Invalid prop values no longer trigger redbox in the legacy renderer
## Context
We are changing React Native to behave more like a browser in the sense that **bad style values are not runtime errors**. (See e.g. D43159284 (d6e9891577), D43184380.) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.
## This diff
This change is similar to D43184380, but here we target the legacy renderer on iOS by removing the redboxes from most of `RCTConvert`'s methods.
I'm intentionally going with the simplest possible improvement which is to downgrade the redboxes to `RCTLogInfo` ( = log to stdout but not the JS console). Leaving the call sites in place (as opposed to deleting them) will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic (though we would likely only build such a diagnostic in Fabric at this point).
Reviewed By: javache
Differential Revision: D43184379
fbshipit-source-id: 5a3d12f5d884372c7dc8743227d58d403caf24e3
Summary:
Changelog: [Internal] Replace assert calls with RCTAssert in RCTSurfaceTouchHandler
We've been recieving crash report tasks related to these calls but it appears (based on D19221204 (23d2a6248c)) that the expectation was that these should be stripped in production and don't cause real problems. RCTAssert does not have that same issue.
Reviewed By: fkgozali
Differential Revision: D43167817
fbshipit-source-id: 45b1b4a3060cfd1e01356c003d63fa4b91c4222a
Summary:
Changelog:
[iOS][Fixed] - Unrecognized fontFamily values no longer trigger a redbox
## Context
We are starting to roll out a new consistent approach to style errors in React Native, where malformed or semantically invalid style values will never be treated as runtime errors. Instead, bad style values will consistently fall back to known defaults; the incorrect visual rendering will serve as the main runtime diagnostic for developers. We will advise developers to rely on static types for additional diagnostics.
This work will take place over multiple commits and possibly multiple releases of React Native.
## This diff
Here we fix this issue as it applies to the `fontFamily` style prop. The legacy (Paper) renderer on iOS is the only concrete implementation that had to change. Fabric and Android already implement the correct behaviour.
h/t EvanBacon for the report: https://twitter.com/Baconbrix/status/1623039650775371792
Reviewed By: huntie
Differential Revision: D43159284
fbshipit-source-id: 6afeef3abc5781e18671708f642073d25f2347e9
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: 0f8dc067ac/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:
Pull Request resolved: https://github.com/facebook/react-native/pull/35789
Changelog: [Internal]
This diff is reverting D41069547 (fee9510b2d) D41062668 (4c40014d43) D40984397 (05968d16e1)
D40984397 (05968d16e1) has been identified to be causing the following test or build failures:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
allow-large-files
Differential Revision: D42371475
fbshipit-source-id: daa01c9215811c397f5cef958fd4620f36295b60
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:
`react-native-screens` has a bug about `UIViewControllerHierarchyInconsistency` when dismissing a `react-native` `<Modal>`. Here is the bug https://github.com/software-mansion/react-native-screens/issues/944
After adding `dispatch_async` block, it solves the issue. But I do not know if this is right.
Here is the example repo https://github.com/wood1986/react-native-modal-crash
You can revert my last commit 86e7bc1adf to reproduce the issue
## 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 the potential race condition when dismissing and presentating modal
Pull Request resolved: https://github.com/facebook/react-native/pull/35705
Reviewed By: cipolleschi
Differential Revision: D42253488
Pulled By: makovkastar
fbshipit-source-id: 3e98fa9e719ecdeddeb2a367b0cd364e15136d56
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
Riccardo Cipolleschi
Samuel Susla
Moti Zilberman
szymonrybczak
Vincent Riemer
Nick Gerleman
Pieter De Baets
Deepak Jacob
Birkir Gudjonsson
Janic Duplessis
gabrieldonadel
Genki Kondo
Prakash Gurung
fabriziobertoglio1987
Sheikh Jamir Alam
Christoph Purrer
Ruslan Lesiutin
Wojciech Lewicki
abing
Liam Xu
admirsaheta
wood1986
Saad Najmi
Ruslan Shestopalyuk
Ruslan Latypov
Michael Anthony Leon
