Summary:
Changelog: [internal]
layoutDirectionPass down layoutDirection from `RCTSurfacePresenter` down to `YogaLayutableShadowNode`.
In `ParagraphShadowNode`, we propagate layoutDirection from yoga node to `TextAttributes.layoutDirection`.
Reviewed By: shergin
Differential Revision: D20420041
fbshipit-source-id: 86e01d31ea9415acb8579c44c470cac870ec1b8f
Summary:
Changelog: [Internal]
# Problem
SafeAreaView is getting reused, its previous `safeAreaInsets` is top: 44, bottom: 34 so `safeAreaInsetsDidChange` doesn't get called because it doesn't change. Therefore state gets never updates because `safeAreaInsetsDidChange` is never called.
# Solution
Update state whenever a new state is assigned.
Reviewed By: shergin
Differential Revision: D20444198
fbshipit-source-id: 75d1458450c70d74647df4962ddad88d5f6a38d2
Summary:
Changelog: [internal]
# Problem
Assigning `CALayer.contents` implicitly animates the difference. As we keep `UIView` in recycle pool between usages, they keep their previous state. This was causing animation of border when the views were being reused.
# Solution
Wrapping application of mutations in `CATTransaction`.
Reviewed By: shergin
Differential Revision: D20442045
fbshipit-source-id: 214d6c422f23f399dec46b5bf1a38a7b64758160
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to take `view.layer.zIndex` into account when we do hit-testing, so now we don't need to sort *all subviews* on *all levels of hierarchy* every time we process touch down event.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20425987
fbshipit-source-id: 025bd968ae948b9b0a4188845efc0de950fb5cdf
Summary:
Now we have `zIndex` feature implemented in the Core, we don't need to have it implemented on the mounting layer.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20432156
fbshipit-source-id: f77b96919bab21b6628472b9fe58c5f4e3233318
Summary:
In one of our test apps (actually on Mac not iOS, but same code) we very consistently crash in RCTCxxBridge.executeApplicationScript when js debugging, due to a timing issue where another thread has reset _reactInstance in between the null check on self->_reactInstance and usage of it on these lines:
```
} else if (self->_reactInstance) {
self->_reactInstance->loadScriptFromString(std::make_unique<NSDataBigString>(script),
```
The thread doing the reset is doing so switching the executorClass to WebSocketExecutor.
In the scenario we crash, the packager has a bundle ready and quickly returns it, though its a 34MB string being passed to NSDataBigString which must be taking long enough for the other thread to get a chance to reset.
## Changelog
[iOS] [Fixed] - Fix crash in RCTCxxBridge.executeApplicationScript
Pull Request resolved: https://github.com/facebook/react-native/pull/25991
Test Plan: Ran apple code path in normal from bundle file and js debugging scenarios.
Reviewed By: shergin
Differential Revision: D19186065
Pulled By: hramos
fbshipit-source-id: ae1d4b5b50b7fb33b74aba21addc2978e917479f
Summary:
Before this change, fields of EmptyLayoutMetrics have some "invalid" values to allow us to compare equal them individually and get `false`. Turned out that having invalid values there might break some serialization layers, which is no good.
This change fixes that and adds explicit check for EmptyLayoutMetrics before running a comparison of individual fields.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D20324881
fbshipit-source-id: ab8e2a402f6bdfb393fc9b6789decb526fa94dfa
Summary:
Changelog: [Internal]
# Problem
`scrollView.state.contentOffset` was not in sync with actual `contentOffset` in case `contentOffset` is changed programatically.
# Solution
Add a flag `_isUserTriggeredScrolling` that indicates whether the current scroll is triggered by user or not. In case it isn't, update state.
Reviewed By: shergin
Differential Revision: D20098161
fbshipit-source-id: 021d916e7a45a24095a47bb8f84d1102226b672a
Summary:
The new name is get_preprocessor_flags_for_build_mode.
Changelog: [Internal]
Reviewed By: d16r
Differential Revision: D20351718
fbshipit-source-id: 67628ce81e7244f0f72af2d00d92842a649ff619
Summary:
Investigating a crash, I spend half of an hour staring at `__bridge`, `__bridge_retained`, `CFRelease` and etc trying to understand is there a bug or not. Even if I think there was no bug there, it should not be this way. We have a nice abstraction around that madness we should use to make the code obvious.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20260917
fbshipit-source-id: 2b511ebf46a78950c4720e749099134aed1dd890
Summary:
We don't know why exactly it happens but (seemingly) sometime Paragraph component receives an empty State object. This causes a crash because of unchecked access to an instance variable.
This diff introduces an assert in DEBUG mode and the check for prod.
Why is this happens? Hard to say, probably `layout()` method (which updates `State`) is not being called on ShadowNode. Why? One explanation can be that Yoga skips some subtree during layout because it starts from "visibility: hidden" component. We need to investigate it more and figure out what exactly going on and what should we need to improve besides the check. That's why we have an assertion.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D20260512
fbshipit-source-id: 4772855f41c6694be2ed6c0a19da40332d2bb8db
Summary:
All `NSNumber *` arguments of NativeModules need to be marked with `__nonnull`. Otherwise, when TurboModules are disabled, we run into a RedBox.
Changelog:
[iOS][Fixed] - Fix RCTDevLoadingView RedBox on Reload
Reviewed By: PeteTheHeat
Differential Revision: D20292188
fbshipit-source-id: a8a5d0b2070575d7728b6308b129196242671fe6
Summary:
{emoji:26a0} This is a follow up to https://github.com/facebook/react-native/issues/25425 -- which isn't merged yet… See 2a286257a6..125aedbedc for actual diff
Currently, StatusBar native module manages the status bar on iOS globally, using `UIApplication.` APIs. This is bad because:
- those APIs have been deprecated for 4 years
- Apple really, really wants you to have an explicitly defined view controller, and control the status bar there
- it [breaks external native components](https://github.com/facebook/react-native/issues/25181#issuecomment-506792819)
- it's [not compatible with iPadOS 13 multi window support](https://github.com/facebook/react-native/issues/25181#issuecomment-506690818)
for those reasons I we should transition towards view controller-based status bar management.
With that, there is a need to introduce a default React Native root view controller, so I added `RCTRootViewController`. Using it is completely opt-in and there is no breaking change here. However I believe this should be a part of the template for new RN iOS apps.
Additionally, I added `RCTRootViewControllerProtocol` with hooks needed for RCTStatusBarManager to control the status bar. This means apps that want to have total control over their view controller can still opt in to react native VC-based status bar by conforming their root view controller to this protocol.
## Changelog
[iOS] [Added] - Added `RCTRootViewController` and `RCTRootViewControllerProtocol`
[iOS] [Fixed] - `UIViewControllerBasedStatusBarAppearance=YES` no longer triggers an error as long as you use `RCTRootViewController`
[iOS] [Fixed] - Status bar style is now correctly changed in multi-window iPadOS 13 apps if you use `RCTRootViewController` and set `UIViewControllerBasedStatusBarAppearance=YES`
Pull Request resolved: https://github.com/facebook/react-native/pull/25919
Test Plan: - Open RNTester → StatusBar → and check that no features broke
Reviewed By: fkgozali
Differential Revision: D16957766
Pulled By: hramos
fbshipit-source-id: 9ae1384ee20a06933053c4404b8237810f1e7c2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/28058
I'm taking the first step towards supporting iOS 13 UIScene APIs and modernizing React Native not to assume an app only has a single window. See discussion here: https://github.com/facebook/react-native/issues/25181#issuecomment-505612941
The approach I'm taking is to take advantage of `RootTagContext` and passing it to NativeModules so that they can identify correctly which window they refer to. Here I'm just laying groundwork.
- [x] `Alert` and `ActionSheetIOS` take an optional `rootTag` argument that will cause them to appear on the correct window
- [x] `StatusBar` methods also have `rootTag` argument added, but it's not fully hooked up on the native side — this turns out to require some more work, see: https://github.com/facebook/react-native/issues/25181#issuecomment-506690818
- [x] `setNetworkActivityIndicatorVisible` is deprecated in iOS 13
- [x] `RCTPerfMonitor`, `RCTProfile` no longer assume `UIApplicationDelegate` has a `window` property (no longer the best practice) — they now just render on the key window
Next steps: Add VC-based status bar management (if I get the OK on https://github.com/facebook/react-native/issues/25181#issuecomment-506690818 ), add multiple window demo to RNTester, deprecate Dimensions in favor of a layout context, consider adding hook-based APIs for native modules such as Alert that automatically know which rootTag to pass
## Changelog
[Internal] [Changed] - Modernize Modal to use RootTagContext
[iOS] [Changed] - `Alert`, `ActionSheetIOS`, `StatusBar` methods now take an optional `surface` argument (for future iPadOS 13 support)
[iOS] [Changed] - RCTPresentedViewController now takes a nullable `window` arg
[Internal] [Changed] - Do not assume `UIApplicationDelegate` has a `window` property
Pull Request resolved: https://github.com/facebook/react-native/pull/25425
Test Plan:
- Open RNTester and:
- go to Modal and check if it still works
- Alert → see if works
- ACtionSheetIOS → see if it works
- StatusBar → see if it works
- Share → see if it works
Reviewed By: PeteTheHeat
Differential Revision: D16957751
Pulled By: hramos
fbshipit-source-id: ae2a4478e2e7f8d2be3022c9c4861561ec244a26
Summary:
Changelog: [Internal]
Use LayoutContext to pass `fontSizeMultiplier` down to ParagrapShadowNode.
Reviewed By: shergin
Differential Revision: D20184596
fbshipit-source-id: 3965a127069a21328ed19cb3f9732f0a2d1c4d58
Summary:
In order to build dynamic text sizing, `LayoutableShadowNode::measure` needs to accept `LayoutContext`
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D20184598
fbshipit-source-id: 8928b59d51948caf3654f40049212a89a91dceb6
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
This is a redo of D16969764, with a few extensions.
## Changes
1. Move `RCTDevLoadingView.{h,m}` to `CoreModuels/RCTDevLoadingView.{h,mm}`
2. Extract ObjC API of `RCTDevLodingView` into `RCTDevLoadingViewProtocol` in `ReactInternal`.
3. Create API `RCTDevLoadingViewSetEnabled.h` in `ReactInternal` to enable/disable `RCTDevLoadingView`
Changelog:
[iOS][Added] - Make RCTDevLoadingView TurboModule-compatible
Reviewed By: PeteTheHeat
Differential Revision: D18642554
fbshipit-source-id: 6b62e27e128d98254b7a6d018399ec1c06e274fc
Summary:
`nativeId` type is `NSString`, not `NSNumber`. The `.h` file already has the proper type but `.mm` had a wrong one.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D20135465
fbshipit-source-id: e5f9fbf4940d3883334c910f96f0aa850a069d8c
Summary:
We are moving towards 100%-prettified files. That's another step when we apply Clang Format for `React/Fabric`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20112417
fbshipit-source-id: 020d818e5cb8e2f509c5276738c8f252f6817a56
Summary:
Changelog: [Internal]
# Problem
Calling `UIManager::updateState` does not increment state revision because it calls `ConcreteComponentDescriptor::createState` which creates new state with state revision 1.
# How did this propagate?
This error propagated itself in TextInput when trying to input a value, you would be only allowed to type in 1 character.
Reviewed By: JoshuaGross
Differential Revision: D20072844
fbshipit-source-id: 37b8173307e1d91d6e9c41b5ff2e185dde31cc38
Summary:
Changelog: [Internal]
If `layer.mask` was set and the view got reused without having a different `layer.mask`, this value would persist between reuses.
I also added a call to `super finalizeUpdates` as it is best practice to call super, the parent class right now doesn't do anything but in the future we might add there some default logic.
Reviewed By: shergin
Differential Revision: D20030174
fbshipit-source-id: c90be3f4e9a8f3814000f177a3d50061f5aa120c
Summary:
We recently updated React Native's docs site to have its own domain reactnative.dev and needed to update the URLs in the source code
CHANGELOG:
[INTERNAL]
Reviewed By: hramos
Differential Revision: D20072842
fbshipit-source-id: 1970d9214c872a6e7abf697d99f8f5360b3b308e
Summary:
The accessibility roles and states description strings are not able to be localized on iOS platform. Those strings are exposed to the end users so it should be localized. This PR is to add localized strings as a resource bundle to the React Core Pod so that any React Native app integrating the React Native dependencies using CocoaPods can get the localized accessibility roles and states description.
## Changelog
[iOS] [Added] - Add localized accessibility strings to React Core pod
Pull Request resolved: https://github.com/facebook/react-native/pull/27995
Test Plan: Verified with RNTester app.
Differential Revision: D19975587
Pulled By: PeteTheHeat
fbshipit-source-id: f8eb4e25194f0cd603c98a6221ec87503a2826ed
Summary: This diff reverts the iOS LogBox module back to the UIWindow strategy used by Redbox.
Reviewed By: sammy-SC
Differential Revision: D19941390
fbshipit-source-id: 4aea09137ea9e8bfc166a733272647a79102bf35
Summary:
Changelog: [Internal]
Switching queue here is not necessary if we are already on the main queue.
This is important for Fabric SSTs, otherwise images are missing.
Reviewed By: shergin
Differential Revision: D19907908
fbshipit-source-id: 52e82484afc8e2f591d0c5cc126952990d992e96
Summary:
This refactors some logic which sets up HMRClient in JS. The logic should live in RCTDevSettings, so it is shared in bridge/bridgeless mode.
This also means the logic will be compiled out when `RCT_DEV_MENU` is false.
Reviewed By: RSNara
Differential Revision: D19563629
fbshipit-source-id: 5c2553be9fd686a2a178f03bb5eed7a82cbadb1b
Summary:
Changelog: [Internal]
When I was originally implementing this view command (D19471025), I misunderstood the desired behaviour.
The text parameter isn't meant to change text in the specified `select` but it is supposed to override text of entire text input.
Reviewed By: shergin
Differential Revision: D19793484
fbshipit-source-id: 64ba36ddfa27ac5a0adf48495cb4e985a429e005