Summary:
Changelog: [Internal]
This solves the problem of viewToAdd indices being invalid if the deletes are asynchronous within the scope of one `manageChildren` call.
Since deletions are performed first, we keep a set of tags being deleted.
During view insertion, we iterate through and filter those tags out of our count.
Reviewed By: JoshuaGross
Differential Revision: D20324643
fbshipit-source-id: 150230428fcd65b8c43cc1f2331e9ce02d31fff9
Summary:
Changelog: [Internal]
Track delete animations and when `manageChildren` is called on a certain view tag, finish all pending deletion animations before manipulating children
Reviewed By: JoshuaGross
Differential Revision: D20319824
fbshipit-source-id: b594d0e6e9b6fecc5eca2938f284be631494e55c
Summary:
Changelog: [Internal]
# Context Timeline
* ~March 2019 landed D14529038 (I'll be referring to this as "index adjustment fix")
which attempted to fix a reproducible issue with layout animations: P127130177, see Spencer's diff for more context: D14245985
* May 2019 I realized that "index adjustment fix" has a bug in it and attempted to fix with D15485132, but was eventually reverted because of other crashes
* Just recently have been getting tasks related to crashes that are attempting to either remove or add a view that is out of bounds which is caused by invalid index because of the "index adjustment fix".
# What is this diff doing?
I'm removing the "index adjustment fix" because I found that the original layout animation repro, P127130177, no longer repros on latest master with the "index adjustment fix" reverted.
Additionally, I've found a consistent crash in (RN bookmark > Sample Integration App > Relay Sample Friends) of a bad view deletion because of the "index adjustment fix"
Removing the index adjustment fix may have effects elsewhere but it seems better to remove this and go back to what layout animations was doing a year ago than to continue on in this half-baked state.
Reviewed By: JoshuaGross
Differential Revision: D20323928
fbshipit-source-id: ba4a222915add00e98a9936ba2a8efc4006fb8e3
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
This diff fixes the rendering of the TextInput RNTester examples in catalyst app.
The root cause of the bug is that we were parsing the props of the text using the TextAttributeProps class, this is incorrect because TextAttributeProps is a holder of the C++ TextAttributes and not TextProps, but the name is confusing.
As a consecuence there was some mistmaches of types during parsing and that was throwing an exception in some examples.
I created the task T63643819 to refactor these classes to make this cleaner.
I'll be working on T63643819 next week, now I want to unblock this bug.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20320969
fbshipit-source-id: 7b47546ba4f34df2a7fa151ab200823ea2eeb696
Summary:
In this diff I'm doing the following:
- Deprecating the method UIManagerModule.resolveRootTagFromReactTag
- Removing the callsites to the method UIManagerModule.resolveRootTagFromReactTag
- Refactoring the callsites in order to keep the same behavior for rootTags
- Throwing an exception if this method was being called with a non rootTag
- Controlling this change of behavior with a MC
This is possible because long time ago we refactored all the callsites to this method to ensure we only use rootTag. I'm making extra steps to make sure this deprecation is safe and we don't break production if this method was being called with a non Root Tag.
changelog: [Android][Deprecated] We are deprecating the method UIManagerModule.resolveRootTagFromReactTag, this will not be supported in the next version of RN
Reviewed By: fkgozali
Differential Revision: D20309166
fbshipit-source-id: 8b89ba889313ae03ed543f402b68f1bb4064ca68
Summary:
Do we need this? Is it possible for any of these codepaths to execute in production? If so, it would be nice to avoid NPEs or even scheduling work on the UI thread.
Maybe we want to add soft exception logging for if these paths are called?
Changelog: [Internal] make sure LogBox does even less work when it's not hooked up
Reviewed By: rickhanlonii
Differential Revision: D20156812
fbshipit-source-id: ba9faedcb3b0951e6913724ca99549dc2d16237e
Summary:
On Android, when changing the props on TextInput component, there are cases where behavior is incorrect.
ex: there were two other PR requests to fix the following issues:
1) TextInput doesnt respect the autoCapitalize prop when keyboardType is set to "default"
2) Password visibility is broken
But those PRs ended up breaking a transition from phone-pad to default
Root cause
- The issue is that the bits that Android defines to store the InputType flags are reused.
- For example, the previous issue: TYPE_TEXT_FLAG_CAP_WORDS and TYPE_NUMBER_FLAG_DECIMAL are both using 0x00002000 bit. So when switching input types from phone-pad to default (text), it is not known if this bit should be cleared. It could have been set for capitalize or for indicating the num pad should be generic.
the solution is to always unset the TYPE_CLASS flags before setting the keyboardType so the user has the correct keyboard.
Changelog: [Fixed] TextInput transition from phone-pad to default
Reviewed By: JoshuaGross
Differential Revision: D20263334
fbshipit-source-id: 0b283fbd6314bf10b90f760917447d2439aaa147
Summary:
Marketplace eagerly initializes a few NativeModules. These NativeModules are TurboModule compatible, and the device/user is in the TurboModule test. So these NativeModuels should be returned from the TurboModule system. However, for some reason, we end up doing a lookup on the `NativeModuleRegistry` for these NativeModules.
This means that either:
1. The TurboModuleManager isn't attached to the CatalystInstance
2. The TurboModuleManager returned null from getModule.
These logs will help us get to the bottom of what's going on.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D20260150
fbshipit-source-id: bb554ead412ad3b0fa7502b77f575365608ebc98
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]
# Problem
Fabric didn't know about content offset, even though `reactSmoothScrollTo` calls `updateStateOnScroll`, the value of content offset is {0, 0}.
# Fix
Call `updateStateOnScroll` from `reactSmoothScrollTo` with where the scroll view is going to be rather than where it is.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20248959
fbshipit-source-id: b1da645576dd5e8dce29e7e1d90ab232e0df9fd5
Summary:
# Problem
HorizontalScrollView was not reporting its `contentOffset` to Fabric, therefore `measure` was returning wrong value.
# Solution
Copy over implementation of `updateState` from scrollView. I noticed that there is a lot of duplication between the two classes, that's why I decided to duplicate `updateState` as well.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D20247552
fbshipit-source-id: 48b1eb0c11198a32531effe55301f8d554e92130
Summary:
Currently the error messages lead users to assume that all problems are because we're trying to use the ReactContext too early; it could be because we're using it too late, after it's been destroyed. Because of D17944723, it could be because we're accessing too late, after teardown.
Changelog: [Internal] making some error messages more specific and helpful
Reviewed By: mdvacca
Differential Revision: D20251909
fbshipit-source-id: e236d57e4d7d9c778d41de95160c242bcd69b3c9
Summary:
This diff fixes the RN Android codegen to support null values for Color typed props.
This was already supported but it recently changed as part of D20169335, when we added the new prop type "color".
changelog: [internal]
Reviewed By: TheSavior
Differential Revision: D20213689
fbshipit-source-id: 42d624de3d1296582f4dcc9c7decd0c02aacca98
Summary:
Turns out that dispatchMountItems was reentrant, meaning that something (in particular, updateState) could cause mount items to be queued up which would then be executed synchronously, out-of-order, in the middle of the previous dispatchMountItems call.
We will continue to monitor this and see how often we're reentering: T63181639 and via any soft exceptions that are logged.
For context, there are currently three ways dispatchMountItems gets called: 1) On every UI Tick in the UI thread, in a loop; 2) via animations, via synchronouslyUpdateViewOnUIThread, which happens to fail a *lot* currently; 3) when there is a commit on the UI thread, like with a Java->C++ state update. We must account for reentrance and failure in all three cases and make sure the `mInDispatch` flag is reset after success or failure in all of those situations.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20170160
fbshipit-source-id: 834f1d9b65000caa7f2eea4849e5e7951d2b6be6
Summary:
D19837753 updated the native platforms to support complex color objects however the diff failed to build when going through this code path (as we do at Facebook).
This updates the automatic PropSetter classes to go through the new Color handler.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20169335
fbshipit-source-id: 8eb9c8b48b1840832b3aec9ffcb83c3cf614ce0e
Summary:
$title
Now that the codegen handles the new PlatformColors, regenerating the checked in native component files.
Changelog:
[Internal]
(Note: this ignores all push blocking failures!)
Reviewed By: mdvacca
Differential Revision: D20175914
fbshipit-source-id: fa7b8e5139dcfe06f49582d7810fae12e1e1fb4b
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:
Tracing isn't supported in OSS builds, so use `hermes/hermes.h` instead
of `hermes_tracing.h` to avoid pulling in any unnecessary dependencies.
Changelog: [Internal]
Reviewed By: dulinriley
Differential Revision: D20201826
fbshipit-source-id: 4c2977db191bb9a1a82310888a435b761629169b
Summary:
This line was and apparently has always been triggered from the
HermesExecutorFactory. We just didn't notice because we didn't build with
assertions.
Changelog: [Internal] Don't crash on load when assertions and Hermes are enabled
Reviewed By: dulinriley
Differential Revision: D20163138
fbshipit-source-id: af672bb51eeb1833f3e27ad9a00921731c345fc5
Summary:
This diff implements serialization and deserialization of text attachments as part of the calculation of layout of text components
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087251
fbshipit-source-id: dbcbd22f856aadace14343205548154ea80c8464
Summary:
ez diff to remove TODO to support inlinew Views in Fabric + venice
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20088698
fbshipit-source-id: bd7cbbd76a8c13edf94d4eecac0dd670ccd0d209
Summary:
We are currently unintentionally including both libhermes-executor-release.so
and libhermes-executor-debug.so in all OSS RN builds.
RN tries both in turn, but since they both exist and the release executor is compatible
with the debug build, we always get the release executor without debug functionality.
While we sort this out, switch the load order. Since the debug executor is not compatible
with the release build, so it'll fail to load and try the next one.
ChangeLog: [Android] Fix Hermes debugger being disabled by default
Reviewed By: mhorowitz
Differential Revision: D20163828
fbshipit-source-id: ee4d87f40e42a7c8eedfdb7e1fc17eb3e5966ba5
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:
This is step 3 in creating a new DevSupportManager with a better async API for loading the JS bundle from Metro.
Right now DevSupportManagerImpl calls a method on its ReactInstanceManagerDevHelper delegate when the JS bundle is done being downloaded from the server. However, I want to move to a callback-based method for bridgeless mode (similar to packager status). In this diff, I'm adding a protected method that uses a callback, and then calling that from `reloadJSFromServer` with a callback that calls the delegate, to preserve existing behavior.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19871102
fbshipit-source-id: 2dbb6b91c5b927df86c3db42aa11e080d57ea78e
Summary:
This is the second step in creating a new DevSupportManager impl with more async-friendly APIs for bundle loading, which I'll use in bridgeless mode. This diff creates a new interface, AsyncDevSupportManager, and two implementations, mirroring what we currently have.
This new interface doesn't define any methods yet.
Changelog: [Android][Changed] Specify DevSupportManager.setPackagerLocationCustomizer in DevSupportManager impls
Reviewed By: mdvacca
Differential Revision: D19870812
fbshipit-source-id: 042a43e1a3055aba6d7325f948060300b5bf17f3
Summary:
This is the first step for adding my own async APIs for DevSupportManager to use in bridgeless mode.
To avoid having to add these APIs to the DevSupportManager interface + both of its implementations, I'm instead splitting DevSupportManager into a base class + final impl so I can more easily share logic with the new impl I'll create.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D19846619
fbshipit-source-id: c67b0231f4e6581fb484f9a4899ed0b7f08fb684
Summary:
Looks like there could be cases when the NativeHirearchyManager may be asking if it should animate on a view that has been removed. Adding a null check
Changelog:
[General] [Fixed] - Check null values in shouldAnimate
Reviewed By: makovkastar
Differential Revision: D20063054
fbshipit-source-id: 5b3b1c27b9aba57a592bd8d4e27a970cf0912b5d
Summary:
Run clang-format and add .clang-tidy with `clang-diagnostic-*` to several more directories in order to catch any problems.
Changelog:
[Internal]
Reviewed By: shergin
Differential Revision: D19860169
fbshipit-source-id: 7785aab010c8e6945cc6b5c9b68cb8ee0cdbb7fa
Summary:
We were already doing this for ViewCommands sent with integer IDs; we should do the same for now with String commands. Otherwise, screens with TextInputs are unusable during development because these exceptions are thrown very often around reload and navigation.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20127446
fbshipit-source-id: a5d65ff6ae5b520fd0efffa5c325b5cca3bd53a0
Summary:
For backwards-compatibility with Paper, we're implementing a feature in Fabric that will allow TextInputs to use the default padding from the theme in Android.
Note that this uses some pretty ugly hacks that probably shouldn't be used inside of components at all: looking directly at rawProps, overriding props/Yoga styles in the component descriptor, etc. I would (personally) really like to kill this feature entirely unless and until we can find a more elegant solution.
Changelog: [Internal]
TextInputs are still not pixel-perfect with Paper, but they're much closer, and the underline visual glitchiness is no longer an issue.
Reviewed By: mdvacca
Differential Revision: D20109605
fbshipit-source-id: 543282843e0a9f03a504d72d7a014431099bd64c
Summary:
This diff:
1. Updates `update-specs.js` to also check in the JNI TurboModules codegen output.
2. Updates all the checked in OSS codegen.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19907536
fbshipit-source-id: 179e01aff05f4c970c20f1482f096dbca10caed3
Summary:
This diff disables the rendering of TextInlineViews in ClassicRN when the users is running with Fabric enabled.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087254
fbshipit-source-id: b4664b17b4c845d212f72e75eee58860fe31abee
Summary:
This diff changes the Fabric measure API in order to support attachments parameters
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20087252
fbshipit-source-id: 20e1526aaa3695d38d0805416df8a32adb8296ad
Summary:
Changelog: [Android] [Changed] - Internal storage now will be preferred for caching images from ImageEditor.
Now we try to write to internal cache directory first.
If that fails (due to no memory error or other IOException), we attempt to write to external storage (if that is allowed).
I introduced additional configuration flag, `allowExternalStorage` which is true by default.
And i updated documentation for new behaviour - see
`ImageEditor.cropImage(..)` comment.
Reviewed By: makovkastar
Differential Revision: D19878158
fbshipit-source-id: 7e338ce68f535f74c62b5eecd5a94af7e7396f8b
Summary:
Until now, there were two measure functions that differ in only one parameter (rootTag). The rootTag is used to use the context associated to the tag as part of the calculation of layout, otherwise it just uses the ReactApplicationContext.
This diff unifies both method into an unique method that
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20081281
fbshipit-source-id: b1f6a6cedbf78f36f36fd0f93407c23c6996d76b
Summary:
I think this NativeModule was converted before we checked in the Java codegen output for TurboModules. I'm making `DeviceInfoModule` extend `NativeDeviceInfoSpec` to properly make it a TurboModule.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D19911145
fbshipit-source-id: fcec8c5b991bd9fd991e690dfa51f1bd36117e5f
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:
This diff disables preallocation of virtual nodes, I'm doing this as an intermediate step to eradicate virtual nodes from the android mounting layer.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048996
fbshipit-source-id: 8fe0b03bcfcfd83a3093d1503ac93a20a5e9a57e
Summary:
This diff extends the MountingManager to not fail when trying to update event emitter of a non created view. This is necessary as intermediate step to remove virtual nodes out of the RN Fabric Android
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20048998
fbshipit-source-id: c2a3633400ac67c2f46ec52ed3ad80289ff6aeb9
Summary:
This diff cleans up mobile config and ReactFeatureFlags that are not used anymore
changeLog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026794
fbshipit-source-id: 3d941db195075a9cf49b7ecc0bf1ee839fcca189
Summary:
This diff enables support for TextInlineViews with dynamic sizes by default, removing old code and calls to MCs.
changelog: [internal]
Reviewed By: JoshuaGross, makovkastar
Differential Revision: D20026795
fbshipit-source-id: 48adf356b418866d937be9b478d9186342a07de8
Luna Wei
Jesse Katsumata
David Vacca
Logan Daniels
Joshua Gross
Michael Yoon (LAX)
Ramanpreet Nara
radex
Samuel Susla
generatedunixname89002005287564
Valentin Shergin
Eli White
Tom Underhill
Will Holen
Kevin Gozali
Emily Janzer
Ram N
Héctor Ramos
Nikita Kraev
Rachel Nabors
Joshua Selbo
