Summary:
This is a re-land of D28810022 (https://github.com/facebook/react-native/commit/7e9c741146e1b3aa542ecfe138765e95ddddac3f), which was reverted due to T92179998. The fix is in D28938530. This issue could also be resolved by preventing more view preallocations (D28811419 (https://github.com/facebook/react-native/commit/8ca18f0b602a08cd9a5c9f6681bb5dc74e0d34f7)).
---
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued.
Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28938637
fbshipit-source-id: c9e290a24ed15c28881e3eead4a5f580f66b288f
Summary:
setJSResponder/clearJSResponder have been in use in prod for a while and are stable. Ship them in code.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28889894
fbshipit-source-id: 1c42526cd890d528062eeb50761fc49cc6109d76
Summary:
Several accessibilityRole strings are hardcoded to only English on Android. Swap them to just use the platform constants. This way, TalkBack will handle translations.
This change swaps roles "search", "button", and "togglebutton" roles to use the platform description.
Changelog:
[Android][Changed] Localize "search", "button", and "togglebutton" accessibility roles by using the platform roles
Reviewed By: lunaleaps
Differential Revision: D28077246
fbshipit-source-id: 5b88a6fd7e78b3426506f253b823ecca0608c4bc
Summary:
Gradle has been showing below warning for a while, and this PR fixes the warning using maven-publish plugin, thus taking us one step closer to Gradle 7.x.
> The maven plugin has been deprecated. This is scheduled to be removed in Gradle 7.0. Please use the maven-publish plugin instead. Consult the upgrading guide for further information: https://docs.gradle.org/6.9/userguide/upgrading_version_5.html#legacy_publication_system_is_deprecated_and_replaced_with_the_publish_plugins
Configured maven-publish plugin according to https://developer.android.com/studio/build/maven-publish-plugin, also added **installArchives** task for backwards compatibility.
## Changelog
[Internal] [Changed] - use maven-publish plugin to build and publish Android artifact
Pull Request resolved: https://github.com/facebook/react-native/pull/31611
Test Plan: ./gradlew :ReactAndroid:installArchives will create **android** directory for local maven repository with **react-native** package.
Reviewed By: yungsters
Differential Revision: D28802435
Pulled By: ShikaSD
fbshipit-source-id: 7bc7650a700e1a61213c5ec238bcb24fdca954db
Summary:
Don't allocate large arrays on stack when copying native pointers, use heap based array.
Today the code copies the native pointers on the stack, since it may be too big, lets make sure to use heap based allocating using std::vector.
This array is afterwards converted into a reversed map from index to pointer, so it is heap based anyhow.
Changelog: [Internal] Don't allocate large arrays on stack when copying native pointers, use heap based array
Reviewed By: Andrey-Mishanin
Differential Revision: D28747213
fbshipit-source-id: da69b4b2d0960fdade9f07f44654b30d6dacc43a
Summary:
The RuntimeExecutor that Fabric gets from the bridge doesn't call JSIExecutor::flush(). In the legacy NativeModule system, we're supposed to flush the queue of NativeModule calls after every call into JavaScript. The lack of this flushing means that we execute NativeModule calls less frequently with Fabric enabled, and TurboModules disabled. It also means that [the microtask checkpoints we placed inside JSIExecutor::flush()](https://www.internalfb.com/code/fbsource/[62f69606ae81530f7d6f0cba8466ac604934c901]/xplat/js/react-native-github/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp?lines=427%2C445) won't be executed as frequently, with Fabric enabled.
Changelog: [Android][Fixed] - Flush NativeModule calls with Fabric on Android, on every Native -> JS call.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D28620982
fbshipit-source-id: ae4d1c16c62b6d4a5089e63104ad97f4ed44c440
Summary:
Virtual views that are flattened and don't "FormsView" on-screen should not be preallocated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28811419
fbshipit-source-id: 949dcbf4cf3791355c58af785603b35fa50f3f02
Summary:
This hack should not be necessary. It should be fixed at Differ or LayoutAnimations level if there are existing issues there.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810021
fbshipit-source-id: 98b8d2ae9991ad527a3b3e90943d75063b2a4496
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued. Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810022
fbshipit-source-id: ae4c8b4eefe619d9a99fa5f90f612d6dd4880da5
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
Removes stale feature flag that was in production for a couple of months. Fix helped to decrease number of crashes significantly, so we can remove it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28757995
fbshipit-source-id: 375da09c11f265e8bbe03cd99de1b83f168420ce
Summary:
Touch event logic has been recently modified to contain surfaceId only in the new renderer. This change aligns OSS tests that have been failing for them.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28749961
fbshipit-source-id: 483ab3ac97bbdc4f1fbdb2a8c699ef060cca9f77
Summary:
Adds logs to indicate that MountItem was queued instead of executed.
Also moves logging of preMount items to dispatcher for consistent logging with other items.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28690203
fbshipit-source-id: 14d24f0bebb97a810127f5187b4d46f66b6c836f
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
EventDispatcherImpl uses synchronized blocks all over to make it thread-safe. I'm concerned about the perf implications of this and creating contention between JS and UI threads.
This is locked behind a feature flag.
Enabled only for Fabric in StaticViewConfig mode, and a feature flag, for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28591331
fbshipit-source-id: ea8f93a2e1343ce37fa78690dcb62fe03594120f
Summary:
FlatList relies heavily on onScroll events + the measure API. In Fabric, usage of `measure` relies on C++ having an accurate view of the current scroll position of the ScrollView.
We already have a mechanism for updating the scroll position in C++ using UpdateState. But, it is only used currently at the /beginning/ and /end/ of scrolling, and UpdateState is not called /during/ scrolling at all.
This means that we will see a series of events like this while scrolling:
```
Scrolling begins
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 0
JS event: onScroll x=0, y=0
JS event: onScroll x=0, y=100
JS event: onScroll x=0, y=200
...
JS event: onScroll x=0, y=1000
UPDATE C++ STATE: scrollLeft = 0, scrollTop = 1000
```
Notably, not many C++ state updates are queued; and the last one is queued AFTER the JS event is sent. The last JS event and UpdateState will race, which means that sometimes the C++ update will /lose/ and C++ will have an inaccurate view of the world when FlatList receives the onScroll event and calls `measure`.
My proposed solution, gated behind a feature flag, is to delay /some/ onScroll events until the C++ UpdateState has made its way back to Java, and send UpdateStates more frequently. The balance here is that UpdateState is a relatively expensive operation, so we probably still want to call it /less/ than we call onScroll. This means that `measure` will still return some incorrect results but will return correct results more frequently. Win?
Changelog: [Internal[
Reviewed By: mdvacca
Differential Revision: D28558380
fbshipit-source-id: 11c7cd714fae67ee5a94c4413be988481413ec03
Summary:
It's not supported, and building with libc++ using its unstable ABI
exposes the issue. Include the header to get the complete type.
Changelog: [Internal]
Reviewed By: lanza, sammy-SC
Differential Revision: D28405500
fbshipit-source-id: 65e039a465d8d736eaecb89e82895889fd2379ca
Summary:
This diff creates a ReactFeatureFlag to initialize MapBufferSo file during Fabric initialization.
This is necessary to be able to compare properly Mapbuffer vs ReadableNativeMap (because ReadableNativeMap c++ files is already included in the bridge so file)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D28436044
fbshipit-source-id: 338e1bb72b5313dc29a309e1b0e979e7c8bd1c18
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27938536
fbshipit-source-id: 750b0e21e0ecbd7aa5a14885ebc70aae82203bd4
Summary:
Call `onDropViewInstance` on all Views when stopSurface is called.
We used to do this but stopped doing it ~6 months ago. This did not cause any prod issues but is not correct.
This allows product code to do cleanup upon view deletion.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28388929
fbshipit-source-id: a8f06d4b1b12a11a907667e0a837c653db035941
Summary:
See comments inline for motivation. It's not safe to use viewtag of an Event to infer whether or not the view is in a Fabric or non-Fabric RootView.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28365566
fbshipit-source-id: 187ddcc5d5a43a31a71232fdb2f1f5b334bec8c2
Summary:
This diff is a follow up of D28360679 (https://github.com/facebook/react-native/commit/e3367354cc93f17b830ed8dc601dff5e87748dd1), here we refactor the access of ReactFeatureFlags from C++ to use methods instead of fields
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28362066
fbshipit-source-id: caed5e7fddeb6c0d9846fb037152befa8f1ed5c2
Summary:
Since we are now using ReactFeatureFlag from C++, we need to ensure redex doesn't strip its fields.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28360678
fbshipit-source-id: 74604e2d008a056c161d8b6ab8f5b30807087d9e
Summary:
This diff refactors the way we are populating the 'MapBufferSerializationEnabled' context cointainer key to use ReactFeatureFlags instead of MobileConfig.
This is necessary to make sure we always use a consistent value between C++ and Java. e.g. to prevent SEV like S230730 set different values in java and c++ code
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28360679
fbshipit-source-id: baef9d53f84de25c5671483dcd995674bfa61984
Summary:
Updates Gradle script to include new version of folly (synced to iOS update)
Adds fmt and libevent as well as some boost ASM sources to enable compilation of folly futures.
Changelog:
[Android] Updated folly to 2021.04.26
Reviewed By: fkgozali
Differential Revision: D28124377
fbshipit-source-id: d44c5a1ded5ee7ad514a9df14ea2ba326d4aa0e3
Summary:
This diff deletes ReactFeatureFlags.useViewManagerDelegatesForCommands, this has been enabled in prod for 9+ months
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28265338
fbshipit-source-id: 2f07cb83d6ef9191f9ebea52e230490ef98d6e2d
Summary:
Support ScrollAway in ReactScrollView for Fabric/non-Fabric.
Changelog: [Android][Added] Support for ScrollAway native nav bars added to ReactScrollView
Reviewed By: mdvacca
Differential Revision: D28308855
fbshipit-source-id: 9a922159ef50fb7c8e9c484a4b97ca57ab248496
Summary:
This diff deleted the ReactFeatureFlags.useViewManagerDelegates, this has been enabled for 9+ months
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28265339
fbshipit-source-id: f5c97e77ca4fc72d2e2b8f891e800e362177d67a
Summary:
this is a quick refactor of the string tags used in UIManagerHelper
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28243264
fbshipit-source-id: c32c9908d40e6184d7e940b14c9782799db3f891
Summary:
This diff refactors the UIManagerHelper.getUIManager method to return null when there's no UIManager registered for the uiManagerType received as a parameter.
This is necessary to workaround: https://github.com/facebook/react-native/issues/31245
changelog: [changed] UIManagerHelper.getUIManager now returns null when there's no UIManager registered for the uiManagerType received as a parameter
Reviewed By: fkgozali
Differential Revision: D28242592
fbshipit-source-id: c3a4979bcf6e547d0f0060737e41bbf19860a984
Summary:
This diff creates a MC to verify impact of eager initialization of fabric classes, the purpose is to remove this code, but before doing that I would like to verify what's the impact.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D28223943
fbshipit-source-id: 6f7c4701fb730fe1c0629ec13ead592ff619373f
Summary:
This diff ensures that the dispatch of switch events is performed using the proper UIModule
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28204930
fbshipit-source-id: 625b536ab3106efa7dbf583589dfe268b880a6a0
Summary:
Fix Readme link to Testing section
Fix Readme link to Testing section
## 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 link to Testing in React Native Android ReadMe file
Pull Request resolved: https://github.com/facebook/react-native/pull/31387
Test Plan: Change has been made to a Readme documentation, no changes in code
Reviewed By: TheSavior
Differential Revision: D28192184
Pulled By: PeteTheHeat
fbshipit-source-id: 6d4503f68398accacead116b43981e03e4c1430a
Summary:
This issue fixes https://github.com/facebook/react-native/issues/30935 screenreader does not announce Image disabled accessibilityState.
As stated in AOSP View.java, the framework will handle routine focus movement, views indicate their willingness to take focus through the `isFocusable` method https://bit.ly/3dCnyHb
```
* <p>The framework will handle routine focus movement in response to user input. This includes
* changing the focus as views are removed or hidden, or as new views become available. Views
* indicate their willingness to take focus through the {link #isFocusable} method. To change
* whether a view can take focus, call {link #setFocusable(boolean)}.
```
The property is updated through its shadow node `ReactImageManager` method `setAccessible` https://bit.ly/3dDuK5L
```java
* <p>Instances of this class receive property updates from JS via @{link UIManagerModule}.
* Subclasses may use {link #updateShadowNode} to persist some of the updated fields in the node
* instance that corresponds to a particular view type.
```
## 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] - adding setAccessible to ReactImageManager to allow screenreader announce Image accessibilityState of "disabled"
Pull Request resolved: https://github.com/facebook/react-native/pull/31252
Test Plan:
**<details><summary>CLICK TO OPEN TESTS RESULTS</summary>**
<p>
Enable audio to hear the screenreader
TEST SCENARIO
- The user moves the screenreader focus to an image and the screenreader reads the Image accessibilityLabel "plain network image"
RESULT
- The screenreader announces the accessibilityState disabled after reading the Image accessibilityLabel "plain network image"
```javascript
<Image
accessible={true}
accessibilityLabel="plain network image"
accessibilityState={{disabled: true}}
source={fullImage}
style={styles.base}
/>
```
<video src="https://user-images.githubusercontent.com/24992535/112670432-2f366d00-8e61-11eb-843f-4b56f4a06a91.mp4" width="700" />
</p>
</details>
Reviewed By: kacieb
Differential Revision: D28194597
Pulled By: lunaleaps
fbshipit-source-id: 5f89ce5c714405506261885ac6fea2c15c2e1f23
Summary:
Changelog:
[General][Added] Add support for "togglebutton" accessibilityRole
# Context
The role for ToggleButton, which is needed on Android to implement toggle buttons correctly, is not currently supported.
# What does this diff do?
Adds support for accessibilityRole `"togglebutton"`.
On Android, this maps to class `"Android.widget.ToggleButton"`.
iOS does not have an equivalent trait for togglebutton, so I set it to be the same as setting `accessibilityRole="button"` for iOS.
# Caveats - checked vs selected
It seems to me like this role currently requires that you set `accessibilityState={{checked: true/false}}`. The behavior is strange when setting `selected` state, I think because on Android ToggleButtons are meant to use `checked` to indicate toggled on/off.
This is tricky because typically on iOS if you have a toggle button, you would use `selected` instead of `checked`, so RN users are likely to mess this up.
Possible solutions:
1. document that you should use `checked` state on Android for toggle buttons (and maybe throw a warning if someone passes in `selected`).
2. have RN ignore it if someone passes in accessibilityState `selected`, if this role is used.
3. Have RN convert passed in `selected` state to `checked` on the Android side.
Reviewed By: nadiia
Differential Revision: D27976046
fbshipit-source-id: 4ce202449cf2371f4bf83c4db2d53120369ee7b0
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Joshua Gross
fabriziobertoglio1987
Kacie Bawiec
Dulmandakh
Amir Shalem
Ramanpreet Nara
David Vacca
Andrei Shikov
Joshua Selbo
Andres Suarez
Shoaib Meenai
Samuel Susla
sangeethaKP
Paige Sun
