Summary:
…eption
This is a minor change in `DebugCorePackage.getModule()` method that corrects the `IllegalArgumentException`'s error message, which was probably copy-pasted from `CoreModulePackage`.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Fixed] - Fixed error message in DebugCorePackage.getModule
Pull Request resolved: https://github.com/facebook/react-native/pull/29304
Test Plan: No tests needed.
Reviewed By: RSNara
Differential Revision: D22521091
Pulled By: mdvacca
fbshipit-source-id: 19205f9beb0fc26249985ce2c865e284c4a4add1
Summary:
TurboModuleManager can emit the following events:
- JS Require Beginning
- JS Require Ending
- Module Create (for C++-only TurboModules)
This diff instruments JS Require beginning, and JS Require ending. It also serves as a good stopgap to verify that TurboModule perf logging is set up correctly.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22485529
fbshipit-source-id: a41b88b56627ad2bbcaadac87bf9d530bf07ae81
Summary:
We need to instrument the following markers for TurboModules in Java:
- **Java:** moduleDataCreate
- **Java:** moduleCreate
**Problem:** Perf-logging can be on or off in production. This means that we have to guard every perf-logger call, which can be a bit tedious. Therefore, this diff introduces a Java class called `TurboModulePerfLogger`, which:
1. Enables perf-logging by accepting a `NativeModulePerfLogger` `jni::HybridObject` in its `enableLogging` method.
2. Exposes static methods that call into the `NativeModulePerfLogger`'s Java part, when perf-logging is enabled.
We actually have C++ markers as well:
- **C++:** moduleJSRequireBeginning
- **C++:** moduleJSRequireEnding
- **C++:** syncMethodCall
- **C++:** asyncMethodCall
- **C++:** asyncMethodCallExecution
Therefore, `TurboModulePerfLogger.java` also calls its native method `jniEnableCppLogging` to setup C++ TurboModule perf-logging.
TurboModule C++ logging is done via a similar setup (to Java), using `TurboModulePerfLogger.cpp`. The `jniEnableCppLogging` native method calls into `TurboModulePerfLogger::enableLogging` with the C++ part of `NativeModulePerfLogger`. Then, the TurboModules C++ infra uses the static methods on `TurboModulePerfLogger.cpp` to start/end markers.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22444246
fbshipit-source-id: 66f191056cdcf5d7932ff1916a1de70b82e5f32b
Summary:
## Description
This diff introduces `NativeModulePerfLogger.java`, the Android extension (a `jni::HybridClass`) to `NativeModulePerfLogger`.
### Why is this a Hybrid class?
Because we have C++ and Java markers, and the perf-logger has both a Java and a C++ interface that the application must implement. `jni::Hybrid` classes are a convenient solution for these constraints.
Changelog:
[Android][Added] - Introduce JNativeModulePerfLogger
Reviewed By: ejanzer
Differential Revision: D21318052
fbshipit-source-id: 2f43853b243fa2a629068bb4aced1e3f12f038ba
Summary:
See videos. In some cases when an `Animated.timing` animation was triggered, there are not necessarily any corresponding Fabric commits. This causes the animations to be queued up but never execute... until there's some Fabric commit at a distant point in the future.
We can't immediately flush all animation operations (see inline comments) but we also shouldn't wait forever. Thus, we wait 2 frames and then flush.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22490650
fbshipit-source-id: 1669bfed00f2a92b50f9558fc7ccaf71dc636980
Summary:
Expose `resolveCustomDirectEventName` from UIManager interface for Bridgeless Mode+NativeAnimatedModule.
We cannot remove the interface from the Non-Fabric UIManagerModule yet, as it would break downstream open-source dependencies, so I just marked it deprecated.
Note that this still doesn't totally fix issues with Bridgeless mode: generally I have to navigate to a Bridgeless surface, exit it, and then navigate back, and only on the 2nd navigation does everything seem to work properly...
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483508
fbshipit-source-id: 685126e7e51aa5d0fd60ad5d4ecc44e8c6c3029d
Summary:
The previous assumption was that any animations would result in `addAnimatedEventToView` being called. That's not true in all cases, so sometimes we never subscribed to Fabric lifecycle events, preventing animations from working on some screens and for Venice.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22483509
fbshipit-source-id: c97576675902b4b9e1d4e659c7c1e24c5fe92946
Summary:
Commits can happen during navigation/teardown which creates mount items. If we throw an exception during
teardown because we expect the Context to still be around, we crash too often. Instead, I will rely on
logic in FabricUIManager to ignore queued MountItems if we try to execute them after the surface has been torn down;
and we move the IllegalStateException to actual execution of the mount item in case there's an edge-case we're missing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22470102
fbshipit-source-id: ad98c03994969a3c3f300d6551e90b6516ed2d8b
Summary:
This PR adds support for the `shadowColor` style on Android.
This is possible as of Android P using the `setOutlineAmbientShadowColor` and `setOutlineSpotShadowColor` View methods. The actual rendered color is a multiplication of the color-alpha, shadow-effect and elevation-value.
## Changelog
`[Android] [Added] - Add support for shadowColor on API level >= 28`
Pull Request resolved: https://github.com/facebook/react-native/pull/28650
Test Plan:
- Only execute code on Android P
- Added Android `BoxShadow` tests to RNTester app
Reviewed By: mdvacca
Differential Revision: D21125479
Pulled By: shergin
fbshipit-source-id: 14dcc023977d7a9d304fabcd3c90bcf34482f137
Summary:
This moves ios CameraRoll files from React Native open source into FB internal as part of the Lean Core effort.
Changelog: [Breaking][ios] Remove CameraRoll from React Native
Reviewed By: cpojer
Differential Revision: D22208352
fbshipit-source-id: 894d6aff34ece94648dad68060c13b44974c93bb
Summary:
Pet Peeve: Metro is a brand name. You don't say "the Metro server" just like you don't say "the iPhone phone". This is a leftover from when it used to be called "the packager server".
Note: It makes sense to refer to "the Metro server" when talking about it in the context of Metro's features, like if you are discussing "Metro's bundling" and "Metro's server". However, when talking about the tool itself, just Metro is enough.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22330966
fbshipit-source-id: 667618363c641884df543d88cac65d1e44956ad3
Summary:
In RN 0.62 support for `fontVariant` was added on Android.
Using that prop crashes the app on Android below KitKat (4.3 and below)
To reproduce just add any Text with the `fontVariant` styling prop in the app:
```js
<Text style={{fontVariant: ['tabular-nums']}}>This will crash</Text>
```
It will crash any device running Android below KitKat with the error:
This is caused by `java.utils.Objects` only being available on Android 4.4+
## Changelog
[Android] [Fixed] - Fix font variant crash on Android < 4.4
Pull Request resolved: https://github.com/facebook/react-native/pull/29176
Test Plan:
[TextUtils.equals](https://developer.android.com/reference/android/text/TextUtils#equals) was added as soon as API level 1, so no compatibility issue here.
Tested on Emulator running Android 4.1, no crash anymore.
I've searched for other occurences of `java.utils.Objects` in the project, and this was the only one, so no need to remove other occurences ✅
Reviewed By: JoshuaGross
Differential Revision: D22337316
Pulled By: mdvacca
fbshipit-source-id: 5507b21b237a725d596d47b5c01e269895b16d4a
Summary:
In https://github.com/facebook/react-native/commit/0b63c9464872fed9ff3eb388e32850f2f8c69561, I shipped "Early ViewCommand Dispatch" everywhere but didn't provide a good summary in the commit message.
Here it is:
The "Early ViewCommand Dispatch" experiment was a success, leading to improved UI responsiveness and fewer overall crashes.
Ship to all Fabric and non-Fabric users, and clean up the code a bit.
# Context: what?
ViewCommands are now used in React Native to do things like scroll ScrollViews to a certain position; focus or blur a TextInput; control the value of controlled TextInputs; and much more. These used to be done using setNativeProps, but we're moving everything to ViewCommands, and most of that migration has already finished.
# Context: Why?
Because Fabric does not support setNativeProps, there has been an effort to move all setNativeProps callsites to ViewCommands. Since these callsites are in JS where we can't tell if we're running in Paper or Fabric, both Paper and Fabric callsites are being migrated (mostly already done) to ViewCommands. One such example is Android TextInput, which has been using ViewCommands instead of setNativeProps for several months.
This migration was largely without issues, except TheSavior and I noticed early on that certain things were just... slower with ViewCommands. It was definitely noticeable, but we determined it to be acceptable and moved on.
Recently, it became clear to me that the perf regression may not be acceptable, but there might be an "easy" solution.
# Why are ViewCommands slower than SetNativeProps?
So, a couple things. SetNativeProps on Paper would actually cause a layout pass; the same is not true for ViewCommands, so they should actually be much faster. But they're not! The reason is that ViewCommands are treated as regular mount items, and they are queued up /after/ all other mount items. That means if you're trying to interact with the UI while some part of it is updating, your ViewCommands must wait for portions of the screen to finish rendering before they execute.
In some cases, those views may even disappear before the ViewCommand executes, causing increased exceptions as well as speed degredations.
# Proposal
This experiment that ran with successful results was: to execute ViewCommands /before/ all other types of mount instructions (by maintaining a separate queue). That means if you tap on a TextInput to focus it while the screen is doing some heavy rendering, the next time the UIManager executes a batch of instructions, it will execute the focus operation out-of-order, at the very beginning. From a user perspective this is actually quite noticeable, and works much better than the older behavior.
# Why it's Not That Dangerous
* Is it possible that we'll execute instructions after the corresponding view has disappeared? This was already possible, and is actually less likely now, since it's more likely that the ViewCommand will execute before the Delete instructions executes.
* Is it possible we'll execute instructions BEFORE the view is created? Yes, this is possible and I actually found a repro for it. My solution: allow ViewCommands to be retried, exactly once. If they throw an exception the first time, we requeue which will cause the command to be executed after the current batch of mount items. Interestingly, this seems to be unnecessary in Fabric, so the logic there is a bit simpler (probably because on Android we do view preallocation under Fabric, so views are created way before they're inserted into the view hierarchy, and apparently before ViewCommands have a chance to execute).
* ViewCommands are already an imperative feature that exists outside of the normal React commit cycle. So they're already dangerous. This doesn't change that, but it does make dangerous code *faster*, so that's good.
Changelog: [Android][Changed] ViewCommands on Android now execute earlier, as a perf optimization.
Reviewed By: mdvacca
Differential Revision: D22343648
fbshipit-source-id: 310d94977ac8ca3140ee8aa272272f660efafa36
Summary:
(1) As soon as we know we can StopSurface, stop executing all mountitems by clearing out the root tag.
(2) If a surface has been stopped and there's a batch of MountItems to execute against it, execute only the "delete" operations to clear views from memory.
Both of these should reduce memory usage and improve speed slightly around navigation pops.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321389
fbshipit-source-id: 96a8292a8442528f1bba50d35208885cc4168170
Summary:
While in theory we should never delete views before removing them from the hierarchy, there are some exceptions:
(1) Some mysterious cases that don't seem like bugs, but where the child still seems to keep a reference to the parent:
(2) When deleting views as part of stopSurface.
On #1: in the past we had issues when we assumed that ViewManager.getChildCount() would return an accurate count. Sometimes it's just... wrong. Here, I've found at least one case where a View still has a parent after it's removed from the View hierarchy. I assume this is undocumented Android behavior or an Android bug, but either way, there's nothing I can do about it.
On #2: there are valid cases where we want to delete a View without explicitly removing it from the View hierarchy (it will eventually be removed from the hierarchy when the Root view is unmounted, but it may still be "in" a View hierarchy when it's deleted).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22321374
fbshipit-source-id: 9667bbe778c418f0216550638dc26ca48a58e5fa
Summary:
These flags haven't been used in months. They were useful to uncover some race conditions, but will not be iterated further. The Venice project will obviate the concerns that sparked these experiments in the first place.
These flags have been hardcoded to false for a while.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22319204
fbshipit-source-id: 09415f3bb1ca56e15f357210e966d0483ff384f2
Summary:
According to our experiments it's not better than "stop surface on unmount" in any way, and might regress some metrics. Unclear why, but if it's not necessary and doesn't seem to help, it doesn't make sense to continue this experiment.
We still have a mechanism on the C++ side to stop outstanding surfaces on teardown that does the same thing.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22318864
fbshipit-source-id: 7e678c63e4884382e57d996a7f4c4b7b24c8193a
Summary:
motivation: I was just checking out https://github.com/facebook/react-native/commit/30cc158a875a0414cf53d4d5155410eea5d5aeea
and noticed that the commit, I believe, is missing logic for when `contentOffset` is actually `null`.
That is, consider you render `ScrollView` with `contentOffset` { x: 0, y: 100 } and then change that to null / undefined. I'd expect the content offset to invalidate (set to 0 - hope that's the default).
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Android] [Fixed] - ScrollView, HorizontalScrollView: do not ignore `null` `contentOffset` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/28760
Test Plan:
Tested locally within RNTester
<details><summary>code</summary>
<p>
```js
const Ex = () => {
let _scrollView: ?React.ElementRef<typeof ScrollView> = React.useRef(null);
const [offset, setOffset] = React.useState({x: 0, y: 20});
setTimeout(() => {
setOffset(undefined);
}, 2000);
return (
<View>
<ScrollView
ref={_scrollView}
automaticallyAdjustContentInsets={false}
onScroll={() => {
console.log('onScroll!');
}}
contentOffset={offset}
scrollEventThrottle={200}
style={styles.scrollView}>
{ITEMS.map(createItemRow)}
</ScrollView>
<Button
label="Scroll to top"
onPress={() => {
nullthrows(_scrollView.current).scrollTo({y: 0});
}}
/>
<Button
label="Scroll to bottom"
onPress={() => {
nullthrows(_scrollView.current).scrollToEnd({animated: true});
}}
/>
<Button
label="Flash scroll indicators"
onPress={() => {
nullthrows(_scrollView.current).flashScrollIndicators();
}}
/>
</View>
);
};
```
</p>
</details>
Reviewed By: shergin
Differential Revision: D22298676
Pulled By: JoshuaGross
fbshipit-source-id: e411ba4c8a276908e354d59085d164a38ae253c0
Summary:
After animation has been finished using Native driver there is no final value passed from the native to JS side. This causes a bug from https://github.com/facebook/react-native/issues/28114.
This PR solves this problem in the same way as `react-native-reanimated` library. When detaching it is calling native side to get the last value from Animated node and stores it on the JS side.
Preserving animated value even if animation was using `useNativeDriver: true`
Fixes https://github.com/facebook/react-native/issues/28114
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[Internal] [Fixed] - Save native Animated node value on JS side in detach phase
Pull Request resolved: https://github.com/facebook/react-native/pull/28841
Test Plan: Unit tests for added getValue method passed. Green CI
Reviewed By: mdvacca
Differential Revision: D22211499
Pulled By: JoshuaGross
fbshipit-source-id: 9a3a98a9f9a8536fe2c8764f667cdabe1f6ba82a
Summary:
Early ViewCommand dispatch: ship the experiment everywhere on Android.
Since ViewCommands are totally divorced from the commit cycle currently, and since they are inherently unsafe, we can create a separate queue for them
and retry them if they fail with a specific category of exceptions.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22173050
fbshipit-source-id: 494b7c6b5dfd2aec8ba77ae35d0d58d4d727b9b4
Summary:
This diff avoids accessing window and activities object that has dissapear
changelog: [Android][Fix] Fix crash when updating RN dialog props after the activity disappeared
Reviewed By: JoshuaGross
Differential Revision: D22264672
fbshipit-source-id: 89c9895c8c6b6fec383a0e160847e5059616e265
Summary:
This diff avoids calling to the method setStateListAnimator for users running in Android API < 21 (This method did not exist in Android API < 21)
changelog: [Android][Fix] Fix crash while measuring ReactSlider in Android API < 21
Reviewed By: lunaleaps
Differential Revision: D22164574
fbshipit-source-id: 8163f99eeb78302fc75e2c4938330c699ca8d363
Summary:
Searching for details and maybe a fix for T68843308 crashing in disconnectFromView, "Attempting to disconnect view that has not been connected with the given animated node".
May be related to recent refactoring but it's not clear. Change logic slightly and add more diagnostic information.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22153179
fbshipit-source-id: b95dbaf01ae8bca154c61442898b0f9d3aebb4de
Summary:
This diff refactors the theme management for text input in order to avoid extra state updates.
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22149754
fbshipit-source-id: 8a6dbe63c8d532986dbf785c7b16323e0a980669
Summary:
This is a useful debugging tool that will not be compiled by default, and we have some protection to only compile it in Debug builds so it's less likely to accidentally slip into production.
This has been useful for debugging C++ LayoutAnimations, since Remove/Insert mutations are delayed and fiddled around with a little.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22148853
fbshipit-source-id: 05609507cdf06b73fd3edf5cf7bc95e124ff1135
Summary:
It is possible (most recently, if there are bugs in LayoutAnimations, but also in general) to issue a `removeViewAt` MountItem that removes the incorrect view if, for whatever reason, the View hierarchy has become "corrupt"
and Views are out of order. I added two heuristics to catch if that happens: check the tag of the View being removed if possible, and ensure that all deleted views do not have a parent. This will turn weird visual glitches into
hard crashes, which we want once the UI has become corrupt.
My only concern here is with perf; maybe we could put these behind a debug-only flag or something, but it's probably not a huge deal.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22130186
fbshipit-source-id: 0942b019c3449d68edfb9db1fe8130ea351d1d8f
Summary:
Adjusts the behavior of `blurRadius` for `Image` on Android so that it behaves more closely to other platforms (web and iOS).
Changelog:
[Android][Changed] - Effect of `blurRadius` now more closely matches other platforms.
Reviewed By: shergin
Differential Revision: D22118680
fbshipit-source-id: c6d14aef29b4a086e43badfa78407bfa07f9fee2
Summary: This diff updates the loading banner text and color on Android to match its style on iOS.
Differential Revision: D22066823
fbshipit-source-id: 7f8d6cf1a6c4c48babe919995044978d7a81c674
Summary:
If UIManager disappears, it's likely due to (1) teardown due to memory pressure, (2) teardown due to crash, (3) normal teardown.
In all of those cases, I would just want NativeAnimatedModule to stop executing and fail silently ASAP.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22079209
fbshipit-source-id: 21650abdfdb119a6f4abccd6962d0c09f7c7c6cd
Summary:
Adds support for the `onProgress` event on `Image`, for Android.
Since Fresco does not provide a progress listener on `ControllerListener`, this uses a forwarding progress indicator `Drawable` to pass along values from `onLevelChange`.
Caveat: The ratio between `loaded` and `total` can be used, but `total` is currently always 10000. It seems that Fresco does not currently expose the content length from the network response headers.
Changelog:
[Android][Added] - Adds support for the `onProgress` event on `Image`
Reviewed By: mdvacca
Differential Revision: D22029915
fbshipit-source-id: 66174b55ed01e1a059c080e2b14415e7d268bc5c
Summary:
Changes the `onLoad` and `onError` events on `Image` to be consistent with each other and with the `ImageSource` type.
Changelog:
[Android][Breaking] - On `Image`, `onLoad` and `onError` event objects will no longer have an extra `uri` property.
[Android][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
[iOS][Breaking] - On `Image`, `onLoad` event objects' `source.url` is now renamed to `source.uri`.
Reviewed By: mdvacca
Differential Revision: D22023565
fbshipit-source-id: 5ea7904c697f87e01118bdb81ed50ab0a5aecdce
Summary:
Cleans up `ImageLoadEvent` to minimize constructor confusion and to make the dispatching logic more predictable.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D22023141
fbshipit-source-id: 17e66de867f51121a3f9a6b782dbad700a54231a
Summary:
Since we were not busting the `surfaceActiveForExecution` cache, it is very possible (likely, even!) that a surfaceId is invalidated in between UI ticks but we keep executing items for that surface at the next tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22055303
fbshipit-source-id: 351c13535e85b30e00684fe35fc4aa79ccb5961c
Marcel Lasaj
Ramanpreet Nara
Joshua Gross
Santiago Alfonso Muñoz Rodriguez
Hein Rutjes
Devon Deonarine
Sean Wang
Amir Shalem
Christoph Nakazawa
almouro
fabriziobertoglio1987
generatedunixname89002005287564
Vojtech Novak
TMaszko
David Vacca
Omer Peleg
Lee Callender
Tim Yung
Lulu Wu
Oleksandr Melnykov
