Summary:
In https://github.com/facebook/react-native/pull/32695, the `Performance.now()` implementation changed to use unix epoch timestamps instead of a monotonic clock.
This is problematic, because it means that performance measurements get skewed if the device clock changes between two measurements.
With this change, the clock is now monotonic (and the implementation stays consistent between platforms).
More details and repro steps can be found in [this issue](https://github.com/facebook/react-native/issues/33977)
Closes https://github.com/facebook/react-native/issues/33977
## Changelog
[General] [Fixed] - Use monotonic clock for performance.now()
Pull Request resolved: https://github.com/facebook/react-native/pull/33983
Test Plan:
Run on iOS and Android:
```
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: JoshuaGross, cipolleschi
Differential Revision: D37066999
Pulled By: dmitryrykun
fbshipit-source-id: 298547bf39faea1b025c17ff2d2e1a03f929865b
Summary:
It turned out the previous attempt to rely on the Event's UIManagerType wasn't sufficient, as not all Fabric touch event had a surfaceId set on them, e.g. Modal etc.
This brings back the UIManagerType detection based on reactTag, but do it only for non-rootView to keep handling touch via the right dispatcher for rootView as well.
Changelog: [Fixed][Android] Bring back non-rootview touch handling based on reactTag
Reviewed By: JoshuaGross, sshic
Differential Revision: D37063335
fbshipit-source-id: 76e2d7ae5f00006c5ecaf50c86920ea6e85155b7
Summary:
This diff adds an assertion to make sure the pending events are enqueued only when the event emitter is null. This is to avoid unexpected workflow when we queue events but we should just dispatch them.
Changelog:
[Android][Internal] - Make sure we only queue events when event emitter is null
Reviewed By: javache
Differential Revision: D36916482
fbshipit-source-id: fff305615b302ece26bc2482c826b74de4f70266
Summary:
D36784563 (https://github.com/facebook/react-native/commit/ec307e0167deca7f17640cd3c5a60f6be5f47b62) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Changelog
[Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Reviewed By: makovkastar
Differential Revision: D36994688
fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6
Summary:
This diff address an edge case when the pending events are enqueued when the surface is stopped. In this case we will reset map that holds view state to null, which will cause NPE.
Changelog:
[Android][Fixed] - Fix edge case when we enqueue a pending event to views on stopped surface
Reviewed By: javache, gorodscy
Differential Revision: D36912786
fbshipit-source-id: 3ae5a4b08a0a6bf55538d69ac80a101c2c3d899a
Summary:
When tapping on ReactRootView and having Fabric enabled, the touch logic mistakenly dispatch the event to JS via the legacy renderer. This is because the destination was computed based on reactTag (odd = legacy, even = Fabric), but root view tag happens to be always odd (always ends with 1). This change uses the right destination based on what the Event itself tells us, instead of deriving from the reactTag.
Changelog: [Android][Fixed] Fix Fabric touch event dispatching for root views
Reviewed By: JoshuaGross, sshic
Differential Revision: D36917300
fbshipit-source-id: 838b4e135d7df07c37040bd47d71370ff10df067
Summary:
This diff fixes the rendering of transparent borders in RN Android views
The fix clips the view ONLY when there is a border color that's non transparent
This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web
Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android
Reviewed By: JoshuaGross
Differential Revision: D36890856
fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced
Summary:
In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36885646
fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3
Summary:
Right now, when we change the keyboardType on android between between default and email, the value keyboard type stays as email (specially noticeable with the key next to the spacebar, that changes between the comma (`,`) to the at sign (`@`)).
This is because the mask we are using when updating the input is only taking into account the class, and not the flags nor the variations.
We don't apply all masks because it may interfere with flags assigned by other props, like multiline or secure text entry. Therefore, we have created our own mask, taking into account all the variations and flags that the keyboardType prop may set. This may be hard to maintain, since whenever we add any other keyboard type, we have to take these flags into mind.
The error I was trying to fix was in particular regarding going back and forward from email, but this fix may solve other similar issues with other keyboard styles.
## Changelog
[Android] [Fixed] - Fix a bug where the keyboard, once set as email, won't change back to default.
Pull Request resolved: https://github.com/facebook/react-native/pull/33924
Test Plan: In order to test this PR, any test code with a TextInput, and a way to change the value of the keyboardType should work. We should be able to see how the keyboard changes to the correct type without staying, for example, on the email state.
Reviewed By: lunaleaps
Differential Revision: D36784563
Pulled By: makovkastar
fbshipit-source-id: 74d7b61b3c07feea4e4050d7a07603a68b98e835
Summary:
tldr; `ReactEditText` and Android's emoji support in Android's AppCompat 1.4.0 / 1.4.x conflict in an odd way, causing NPEs.
`ReactEditText` defines an `InternalKeyListener`, `mKeyListener`, that it uses to make sure input from all keyboards works correctly. This listener is normally initialized at the end of the constructor.
Unfortunately, some versions of `AppCompatEditText`, most notably the version in the App Compat `1.4.0-alpha0x`, the [minimum version required for the Play Store's emoji compliance](https://developer.android.com/guide/topics/ui/look-and-feel/emoji2#appcompat) call `setInputType` from `AppCompatEditText`'s constructor. `ReactEditText` operates on the key listener inside of `setInputType` and since the `AppCompatEditText` constructor is called via call to `super` before the key listener is initialized, these versions of app compat can cause NPEs when used with React Native.
The fix is simple; check to see if `mKeyListener` is null, and initialize it if it is. This is necessary in both the constructor and inside of `setInputType`.
## 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
-->
https://github.com/facebook/react-native/wiki/Changelog
[Android] [Fixed] - NPE in `ReactEditText.setInputType` when React Native is used with some versions of a AppCompat 1.4.x. (and possibly others)
Pull Request resolved: https://github.com/facebook/react-native/pull/33920
Test Plan:
1. Build an app with both React Native and load it inside an app that is using AppCompat 1.4.x
2. Add a text field using React Native.
3. Open the screen of the app that contains the text field.
If you're working from this branch, you'll be fine. If you're working from main you'll get an NPE.
I can put together a test repo if needed.
Reviewed By: kacieb
Differential Revision: D36802622
Pulled By: cortinico
fbshipit-source-id: e7646da9a1ef0e0334152aecab0f972ca25092ec
Summary:
Adding a flag to prepare for the phase 3 of the new architecture. This is still work in progress, not usable yet.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36767843
fbshipit-source-id: 338d775681f2890461608b403749c3a7f05f84ff
Summary:
Followups to View Recycling diffs to improve things / clean up things a bit. This also fixes memory warnings which were not hooked up before.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36707792
fbshipit-source-id: 410e70bf0eeec5569566138af547e1601394d0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33897
Now the exception will display the class which caused the exception as well as helpful information as to why.
We've seen this happen a bunch due and have been very confused by the error message. It turns out that this processor runs before the classes listed are compiled. This means that if there's a compile error (or a missing import) the user will only see that this processor crashed, and not the compile error.
The additional information in the error is:
`java.lang.RuntimeException: Could not load classes set in ReactModuleList.nativeModules. Check that they exist and are imported correctly on class: com.meta.x.y.ReactPackage`
In this case, `com.meta.x.y.ReactPackage` is the class which needs to be fixed. Before, the error message made no mention of this class or the annotation.
Changelog: [Internal] This will change the way the annotation processor crashes. It will throw a RuntimeException instead of a ClassCastException.
Reviewed By: javache
Differential Revision: D36606279
fbshipit-source-id: aedf9682286fba49e23716b7eda16b2dd3b13422
Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
Changelog: [Internal][Changed] - Make the same optimization on enter/leave/move pointer events being dispatched by a mouse input.
If any ancestor view is listening to enter/leave events (just capture) then we dispatch the enter/leave event.
Reviewed By: vincentriemer
Differential Revision: D36601638
fbshipit-source-id: d6b5c32ae50bcf000100bcb878ca2ca89bd5c02e
Summary:
RN-Tester is currently crashing at startup time due to an NPE.
This PR fixes it.
## Changelog
[Android] [Fixed] - Fix NPE on `ReactEditText` due to null mFabricViewStateManager
Pull Request resolved: https://github.com/facebook/react-native/pull/33910
Test Plan: Tested locally that RN Tester runs both in Debug and in Release
Reviewed By: cipolleschi
Differential Revision: D36666440
Pulled By: cortinico
fbshipit-source-id: f004ff228fb4f9ff339aac606858d47de3706426
Summary:
There are two methods in ReactRootView to handle touch events "onInterceptTouchEvent" and "onTouchEvent", for Venice we have ReactSurfaceView inherits ReactRootView but the implementation for above 2 touch handling methods still calls into it's super implementation which uses the bridge.
In this diff we make ReactSurfaceView inherits ReactRootView's "dispatchJSTouchEvent" and "dispatchJSPointerEvent". So that Venice has separate implementation for touch events handling.
Changelog:
[Android][Changed] - Revamp touch event dispatching methods
Reviewed By: fkgozali, JoshuaGross
Differential Revision: D36629466
fbshipit-source-id: fb7c5950afe6249d22edd3fac3fa5d3b83b3af84
Summary:
This op code was incorrectly configured to take two args, while it only takes one.
Changelog: [Internal]
Differential Revision: D36664590
fbshipit-source-id: 6e1fdb9f64bbd32fbe05bbd174f94ae57292bcf9
Summary:
This diff cleans up several Android Makefiles which we're not using anymore
as they've been replaced by CMake files.
There are still 3 Makefiles left, which I'm aiming to remove in the near future.
Changelog:
[Internal] [Changed] - Remove unused Makefiles from React Native core
Reviewed By: javache
Differential Revision: D36660902
fbshipit-source-id: 8afffac74d493616b0f9414567821cd69f4ef803
Summary:
There's no need for this to be a setter/getter, as there are no side-effects, and it means we can use the same helper method to read it as other feature flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36595602
fbshipit-source-id: d27c01bd39d03606a6f8c17ba181a8cd0bf58dbb
Summary:
Enables two new experiments (and the current behaviour as default) to speed up access to TurboModule methods from JS.
1) HostObject - Current behaviour
2) Prototype - Connect the TM HostObject via `__proto__`, and cache any methods accessed on the wrapper object.
3) Eager - Eagerly store all methods on the wrapper object, do not expose the HostObject to JS at all (TurboModules no longer need to be HostObjects in this scenario)
Changelog: [Internal]
Reviewed By: JoshuaGross, rubennorte, mdvacca
Differential Revision: D36590018
fbshipit-source-id: c9565eb239eb6aeee0f06b581ff8cd72a92073fc
Summary:
* Make constructor private, all access is through install()
* Use nullability of longLivedObjectCollection_ instead of separate bool disableGlobalLongLivedObjectCollection_
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D36592492
fbshipit-source-id: d65e779e1ac9fbe121937c5a20763aefcd589795
Summary:
In D36345402 (https://github.com/facebook/react-native/commit/56e9aa369f5c13af38cf80ba47e9eb29d835ec89) I changed the behaviour for mount items to be skipped if they were just setting zero values. AndroidTextInput is the only component that I'm aware of that has non-zero padding by default, and we account for this when creating the native shadow node. This optimization broken TextInput use-cases that explicitly request zero-padding, since we end up ignoring it.
To keep this optimization, explicitly init ReactTextInput's padding to 0, but only in Fabric. `updateState` was the closest thing I could find to a Fabric-only callback, once it's fully rolled out, we can also move this to the constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545775
fbshipit-source-id: 07bb96032c69d7e350980b0b975e637b66c307ed
Summary:
I have never seen these asserts fire in production. They're pretty cheap but the cost is not zero. We will use annotations and test carefully in debug if we need to ensure that something runs on a particular thread - which we do anyway.
Motivation: this method is called /extremely frequently/, everywhere in the mounting layer. And 99.99% of the time it's completely useless and results in absolutely no signal. In many cases, it will be called hundreds or thousands of times during a single operation (for example, when executing the IntMountBuffer items, each sub-item will call this many times).
Wall-clock time is usually low according to systrace (sometimes there are odd spikes), but over time these do add up and it seems good to save a few ms here and there.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36539399
fbshipit-source-id: 3e023be64b8c9f0e6c3c8347c077ce9fa38f74a4
Summary:
It's useful to have more systrace markers that are all the same, so that they can all be aggregated and work underneath them aggregated across an entire trace. As it is, this marker gets treated as unique nearly every time which makes analysis harder.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36533075
fbshipit-source-id: 925afa7db152eca1166891b41e7c6f6a511840af
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
Splitting these changes of from D36482630, which is a minor improvement to the singleOp experiment. Since we call start/finish already on the native side, we don't need to repeat it from JS.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36541700
fbshipit-source-id: 7d61669710faca3153be557fb2d214011eda87c5
Summary:
* Make inner classes static where possible
* Make member variables final when set from constructor
* Remove Nullable on `mFabricViewStateManager` and associated checks
* Remove `createInternalEditText` which has moved to the ShadowNode (paper-only)
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36545807
fbshipit-source-id: 85517511d1734f0e55de5caa012e32feb40e8492
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary:
`test_android` is currently broken as it tries to build with `source = "7"` (the default).
This is a best guess fix to try to fix this issue.
## Changelog
[Internal] - Attempt to fix test_android by specifying source 8
Pull Request resolved: https://github.com/facebook/react-native/pull/33890
Test Plan: Will rely on CI
Reviewed By: cipolleschi
Differential Revision: D36589814
Pulled By: cortinico
fbshipit-source-id: 8ef50f8531b9d4367d2f2c75a312e8fdaf38fd85
Summary:
This will fix a crash on Motorola devices on Android 7, where WebView fails to load due to initialisation issues in the WebViewChromiumFactoryProvider (Caused by org.chromium.base.library_loader.ProcessInitException).
## Changelog
[Android][Fix] - Exception with `Cannot load WebView` message will initialising WebView (along with existing checks)
Pull Request resolved: https://github.com/facebook/react-native/pull/33867
Test Plan: <img width="1368" alt="Screenshot 2022-05-19 at 02 21 57" src="https://user-images.githubusercontent.com/933314/169154293-c442a54f-96f5-4309-a6ce-c8f9c4beeb17.png">
Reviewed By: javache
Differential Revision: D36517673
Pulled By: cortinico
fbshipit-source-id: 4fa5b903529eb04d01ed8fa540cbd883224e8e62
Summary:
I'm finding it useful to keep track of a few additional numbers when doing perf analysis in Fabric.
Also making it easier to enable just these perf logs without all of the other verbose Fabric logs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36500518
fbshipit-source-id: e57e1e75131c5d59da876d1decb96d4da386f025
Summary:
We were calling the wrong operation from the MegaOp which caused indices to become offset. Trivial fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D36482822
fbshipit-source-id: 83ebc37a8773f0277db4caff9d3e7c9c91931ddb
Summary:
Which idiot wrote this? Oh yeah, I did.
This was introduced in D36109810 (https://github.com/facebook/react-native/commit/bf405d70837e1319cfa83e4c5cbb7c9a69abd820) so hasn't been around too long luckily.
Changelog: [Internal]
Reviewed By: cortinico, GijsWeterings
Differential Revision: D36480272
fbshipit-source-id: b0fbb6b820185185359c6c75f77f2921dc892b02
Summary: Changelog: [Android][Fixed] Scroll views would still receive scroll events when nested in a view with `pointer-events: "none"`
Differential Revision: D36423921
fbshipit-source-id: 87b8a236e15dda7b648b6fc649187e95a9a2cc42
Summary:
Noticed that we emit a large amount of (admittedly cheap) mountitems as part of node creation for values that are all zero (e.g. padding, overflowinset), which we can assume to be already initialised with these values on the native side.
There's a further opportunity to do this for State as well, as ReactImageComponentState exports just empty maps to Java.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36345402
fbshipit-source-id: 8d776ca124bdb9e1cd4de57a04e2785a9a0f918c
Summary:
We introduce a few optimizations:
(1) Previous diff: We defer calling any NativeAnimatedModule methods by waiting 1ms before flushing the queue, and debouncing until no flush is requested. Practically, this just means that we'll call NativeAnimatedModule methods N times at once, at the end of a render loop, instead of N times smeared throughout the render loop.
(2) Additionally, instead of calling N methods, we create multi-operation argument buffer and call a single NativeAnimatedModule API, which should essentially throttle NativeAnimatedModule API calls to once-ish per frame. On the native side, this also reduces a lot of overhead associated with scheduling work on the UI thread (we schedule 1 function to run on the UI thread and perform N operations, as opposed to scheduling N functions to run on the UI thread).
TODO:
- implement stubs for iOS
- write gating code so this can be properly tested in VR and in fb4a
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36338606
fbshipit-source-id: 29ac949b53b874683128a76525586c22def3143b
Summary:
We try to remove the use test_ownership_2020 oncall, which was created to enforce oncall field in test module. This diff stack tries its best to guess who the right oncall is for these "unowned" tests.
If you don't think this belongs to you, please
1. Either re-assign to another team to your best knowledge
2. Or delete the test
Every test should have an owner!
Differential Revision: D36404812
fbshipit-source-id: daf57e860d3700928ae4518897d87247a672eae4
Summary:
Noticed that (LockFree)EventDispatcherImpl had NativeAnimatedNodesManager as a listener 100+ times, as listener registration can happen multiple times from Animated node creation. Since listener management on event dispatcher is thread-safe, we can avoid the thread hop for this.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36316102
fbshipit-source-id: f2f417b69885def87f88460d8b1e0b35b66726cb
Summary:
This diff fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
When a cached image is loaded, we will dispatch the event to JS immediately. This is could happen after the view is created during pre-allocation phase, when the event emitter is not instantiated yet. In that case, we will see [an error](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManager.java#L927) and the event will effectively be ignored.
To fix that we introduced a queue in this diff for those events. They will be dispatched in order when the view is mounted and the event emitter is non-null.
Changelog:
[Android][Fixed] - Fixed an edge case that event dispatching is failed after pre-allocation of a view and before the view is mounted.
Reviewed By: mullender
Differential Revision: D36331914
fbshipit-source-id: cd065b0b36978cb5f0aac793d8d16f07a48f0881
Summary:
Currently on Android, React Native can only accept font resource IDs which it internally converts into Typeface objects. This change allows ReactFontManager to be passed a Typeface at runtime to enable e.g. downloading fonts on demand.
Changelog:
[Android][Added] - Ability to pass a Typeface object to ReactFontManager in addition to a font resource ID
Reviewed By: makovkastar
Differential Revision: D36138123
fbshipit-source-id: b314e8c7fc28174b5caa017076b6eb3d4f6dbaa8
Xin Chen
Olivier Payen
Kevin Gozali
Charles Dudley
David Vacca
Joshua Gross
Daniel Espino García
Andy Zolyak
Nicola Corti
Daniel Abramowitz
Luna Wei
Lulu Wu
Pieter De Baets
Rubén Norte
Rachit Mishra
Tianyu Li
Derek Thurn
