Summary:
NativeModules can be created from any number of threads. In the legacy system, `ModuleHolder`, the class responsible for creating NativeModules, has built-in concurrency control to ensure that NativeModule creation is thread-safe. This diff introduces that thread-safety to the TurboModule infra. Basically, after this diff, if `n` threads race to create a TurboModule x, only the first thread will create x. All other threads will wait until x is created.
Changelog:
[Android][Fixed] - Make TurboModule creation thread-safe
Reviewed By: mdvacca
Differential Revision: D20659799
fbshipit-source-id: 2b720fe1ea49e40ae0d6dae50d422f23a6f45520
Summary:
This diff adds a temporary Feature Flag to control a fix in TextInlineView (see previous diffs of the stack)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20812920
fbshipit-source-id: 90fece9b29ba173546d96e4d9baf1ccabb3031b2
Summary:
This diff cleans the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited right after all the view updates for a rootShadowNode have been processed by the UIImplementation class.
This intends to fix the bug reported in the task: T61185028, which root cause seems related to the fact that the variable NativeViewHierarchyOptimizer.mTagsWithLayoutVisited is not cleaned up when updating multiple rootShadowNodes as part of the same batch
changelog: [Android][internal] internal bug fix
Reviewed By: JoshuaGross
Differential Revision: D20812921
fbshipit-source-id: 28067ee29a931d7a9e9c33c90aceb4e3512dac1a
Summary:
This is the first of three PRs related to enabling multi-bundle support in React Native. More details, motivation and reasoning behind it can be found in RFC [here](https://github.com/react-native-community/discussions-and-proposals/issues/152).
Logic responsible for installing globals was pulled out from `loadApplicationScript` to `initializeRuntime` since it should be ran only once, what was left was renamed to `loadBundle`.
It's based on dratwas work from [here](https://github.com/callstack/react-native/tree/feat/multibundle/split-load-application), but applied to current `master` to avoid rebasing 3-months old branch and issues that come with that.
## Changelog
[Internal] [Changed] - split `loadApplicationScript` into `initializeRuntime` and `loadBundle` to enable multi-bundle support in the future
Pull Request resolved: https://github.com/facebook/react-native/pull/27844
Test Plan: Initialized new RN app with CLI, set RN to build from source and verified the still app builds and runs OK using code from this branch.
Reviewed By: rickhanlonii
Differential Revision: D19888605
Pulled By: ejanzer
fbshipit-source-id: 24ace48ffe8978796591fe7c6cf53a61b127cce6
Summary:
Hard-coded to false everywhere, and write-only. We never read from this.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20788252
fbshipit-source-id: ae117ebc51db7045947b9713602527ff4220833e
Summary:
Remove unused feature flag. This is not used within Facebook and I'm not aware of usage outside of FB.
Changelog: [Removed] Removing Android feature flag: lazilyLoadViewManagers
Reviewed By: mdvacca
Differential Revision: D20788210
fbshipit-source-id: 435316e3de7830d7cb7f14537351883e4fc6eeaa
Summary:
## Overview
This diff is an RFC to port a logging feature from iOS to Android.
Changelog: [Internal]
## Motivation
On iOS we have the following log functions and behaviors available for logging native warnings and errors:
- **Warnings** (`RCTLogWarn`)
- Log level 'warn' to console
- Display warning in LogBox
- **Errors** (`RCTLogError`)
- Log level 'error' to console
- Display a native RedBox (needs converted to show a LogBox if available)
- **Logs**
- We also have `RCTLog`, `RCTTrace`, `RCTAdvice`, `RCTInfo`, which just log to the console.
In Java, we have:
- **Warnings**
- **None**, added in this diff
- **Errors** (`DevSupportManager.showNewJavaError`)
- Log level 'error' to console with `FLog.e`
- Display a native RedBox (needs converted to show a LogBox if available
- **Logs**
- `ReactSoftException` (crashes the app??)
- `ReactNoCrashSoftException` (only logs??)
- Others?
## Details
This diff adds a method to pair with `RCTLogWarn`, `DevSupportManager.showNewJavaWarning`, which will log to the console and show a LogBox warning if LogBox is available.
## Concerns
I have a few concerns/questions about the state of logging on Android:
- Should/can we move all of the logging to it's own class, like how RCTLog works?
- Why does some logging happen on DevSupportManager and some in other classes?
- If we moved it all to it's own class, how could we access the reactContext to call the RCTLog JS module
Reviewed By: JoshuaGross
Differential Revision: D20056394
fbshipit-source-id: 32d57e300685e46da8039fc77cb22b4084acf81a
Summary:
There's (potentially) a lot of expensive reflection calls here that, as best I can tell, end up being ignored if the supplied color is null. Better to early return.
Changelog: [General] [Internal] Preclude reflection when setting cursor color if color is null
Reviewed By: JoshuaGross
Differential Revision: D20670594
fbshipit-source-id: 480a988355bbd79008002c4326d4b35035ec2a95
Summary:
Accessing this field via reflection is explicitly blacklisted by Google in Android 10 and higher. They have provided a new API to change the color, which I have implemented here. [The old setColorFilter is deprecated](https://developer.android.com/reference/android/graphics/drawable/Drawable#setColorFilter(int,%20android.graphics.PorterDuff.Mode)) so I also updated that method call as well.
Changelog: [General] [Fixed] Use new setTextCursorDrawable API for Android 10
Reviewed By: JoshuaGross
Differential Revision: D20656068
fbshipit-source-id: 58a92b57c0a892c7c87fc5d735e4ceaa4e987ec7
Summary:
An evolution of D20633188 but more performant.
There are three optimized paths before the slow path.
The first optimized path tries to pair identical nodes from old/new tree, and generate Update mutations, until we hit nodes that are different (indicating either a remove or an insert). This already existed.
The next two optimizations, introduced by Tim in his JS pseudocode, were inspired by ReactJS's diffing algorithm. They work in cases where the rest of the nodes are (1) all removals/deletes or (2) all creates+inserts.
Finally, if those final two optimized paths can't run, it's because there is a mix of delete+remove, create+insert, and "move" operations, mixed at the beginning, middle, and/or end of the list.
This has slightly better average/best-case complexity as the previous implementation.
In particularly pathological cases where all nodes are arbitrarily reordered, or reversed, for instance (ABCDE->EDCBA) the algorithm has the same complexity as the previous algorithm (quadratic).
For now iOS is pinned to the older differ
Changelog: [Internal] Experiment to optimize diffing algorithm in Fabric
Reviewed By: shergin
Differential Revision: D20684094
fbshipit-source-id: d29fba95a0328156c023e1c87804f23770ee1d91
Summary:
`fbsource//xplat` and `//xplat` are equivalent for FB BUCK targets. Removing extra prefix for consistency.
Changelog: [Internal]
Reviewed By: scottrice
Differential Revision: D20495655
fbshipit-source-id: a57b72f694c533e2e16dffe74eccb8fdec1f55f5
Summary:
Changelog: [Android] [Updated]
mOverrideColorScheme should be assigned before the first colorSchemeForCurrentConfiguration call, so the initial setting of mColorScheme will reflect the override
Reviewed By: zackargyle
Differential Revision: D20630173
fbshipit-source-id: a2a2d174d3fc40c14f27dce6a7fa8e67203480c9
Summary:
Changelog: [Internal]
Removing historic layout animations index adjustment (D20323928) broke the Dating Secret Crush screen.
Since flushing animations (D20319824) had to be reverted due to issues with Saved + Privacy Shortcuts (https://fburl.com/tasks/eijtmifu) we need to track pending deletions across `manageChildren` operations.
Reviewed By: JoshuaGross
Differential Revision: D20601079
fbshipit-source-id: c6f116683750e97abe7f988cf361d2a6449e90e6
Summary:
add support to the android implementation of the Picker component for setting the background color.
Changelog: [Android] [Added] - Support item background color in Dialog Picker
Differential Revision: D20566131
fbshipit-source-id: d693b40803fa1051ec955c5728994c820fecd9e9
Summary:
Earlier this week I introduced a change in the old, non-Fabric renderer (D20378633 D20427803) that (gated behind a feature-flag) executes ViewCommands before all other types of commands, as a perf optimization and (I think) a potential fix for a category of race conditions.
I've added more details in comments here.
The Fabric renderer uses the same feature-flag that I introduced for the non-Fabric renderer.
Changelog: [Internal] Fabric
Reviewed By: mdvacca
Differential Revision: D20449186
fbshipit-source-id: bb3649f565f32c417a6247369902333989a043aa
Summary:
Instead of just blindly retrying all ViewCommands if they fail - which could be dangerous, since it's arbitrary imperative commands we'd be executing twice, potentially with bad app state - we only retry if the ViewCommand throws a "RetryableMountingLayerException".
Changelog: [Internal] Optimization to ViewCommands
Reviewed By: mdvacca
Differential Revision: D20529985
fbshipit-source-id: 0217b43f4bf92442bcc7ca48c8ae2b9a9e543dc9
Summary:
Simplifying the dispatchMountItems reentrance and retry logic.
Motivation: cleanup so I can work on dispatching ViewCommands before anything else.
Importantly, this gives us the properties that:
1) Only one function is responsible for calling dispatchMountItems
2) Only one function is responsible for deciding if we shouldn't call dispatchMountItems due to reentrance
3) Only one function is responsible for all cleanup
4) Only one function maintains all of the relevant flags (except dispatchPreMountItems... two total now, instead of 4 before)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20437035
fbshipit-source-id: 5370366790eb25f653bee6c1950e747458374a61
Summary:
Original commit changeset: b594d0e6e9b6
D20319824 introduced a problem in LayoutAnimations, which makes surfaced as the problem in T63911344. This diff reverts D20319824.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D20541918
fbshipit-source-id: ff72b839f57d39051122920a38b2632cbb5ec362
Summary:
Patch for T63997094.
Will still crash in debug mode, and log soft errors, so as not to entirely hide errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D20473855
fbshipit-source-id: 8b052b1ae3c886f83d6a7922feb158172cdcd33d
Summary:
Changelog: [Android] [Added]
Adding:
- OverrideColorScheme interface to AppearanceModule
- setOverrideColorScheme method to AppearanceModule
This allows RN surfaces's color scheme to be overriden by custom theme from the app.
When set, AppearanceModule will use the value from OverrideColorScheme instead of system theme (light/dark)
Reviewed By: JoshuaGross
Differential Revision: D20405810
fbshipit-source-id: 8e562148a75231781649b615fdaf3368beeb477d
Summary:
Allow JS to keep track of mostRecentEventCount and pass it into each event or prop update. We really don't want to separately keep track of that data.
In non-Fabric, the ShadowNode will keep track of the mostRecentEventCount associated to prop updates. In Fabric, that happens on the C++ ShadowNode.
Changelog: [Internal] Simplification to TextInput native state
Reviewed By: mdvacca
Differential Revision: D20374573
fbshipit-source-id: 385fba6ec69a071c78832a686b397699a6c55d67
Summary:
ViewCommands are sort of like setNativeProps updates, in that they're direct manipulations of Views on-screen that don't go through the normal
commit/diff process that other UI updates do. This is an MVP that shows how we can do this in non-Fabric RN.
Changelog: [Internal] experiment, allow ViewCommands to be executed before other types of UIOperations
Reviewed By: axe-fb, mdvacca
Differential Revision: D20378633
fbshipit-source-id: 5f3c54d3c84b4e4f7cb060a9505b20b0e5b7afed
Summary:
See D19204032. In some cases the View might not have a ThemedReactContext, it may be wrapped, so we use a previously-created helper to get the correct context from the View or we throw a soft exception.
Changelog: [Internal] Fabric change
Reviewed By: mdvacca
Differential Revision: D20355126
fbshipit-source-id: 469a3b7f8f2d3b98236f3170dd62c4a6e7e1e46f
Summary:
Work around crash in Android TextInput when default colors are null.
This likely indicates that the Context is corrupted in some way, so this is not a permanent solution.
Changelog: [Internal] Raise soft exception is default platform text color isn't defined
Reviewed By: mdvacca
Differential Revision: D20351080
fbshipit-source-id: d912c9348272c2f3a3b8d571d465d482060efe5a
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:
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
Ramanpreet Nara
Vojtech Novak
David Vacca
maciej simka
Joshua Gross
Rick Hanlon
Samuel Susla
Emilis Baliukonis
Nicholas Tinsley
Spencer Ahrens
Kevin Gozali
Eddie Dugan
Jack Wang
Luna Wei
Héctor Ramos
generatedunixname89002005287564
Jesse Katsumata
Michael Yoon (LAX)
