Summary:
Just a fix of a typo
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D31076782
fbshipit-source-id: 192de92ba080a565acd67e038b370917ea9fcddc
Summary:
When retrieving the device dimensions through the JS `Dimensions` utility, the result of `Dimensions.get` can be incorrect on Android.
### Related issues
- https://github.com/facebook/react-native/issues/29105
- https://github.com/facebook/react-native/issues/29451
- https://github.com/facebook/react-native/issues/29323
The issue is caused by the Android `DeviceInfoModule` that provides initial screen dimensions and then subsequently updates those by emitting `didUpdateDimensions` events. The assumption in that implementation is that the initial display metrics will not have changed prior to the first check for updated metrics. However that is not the case as the device may be rotated (as shown in the attached video).
The solution in this PR is to keep track of the initial dimensions for comparison at the first check for updated metrics.
## Changelog
[Android] [Fixed] - Fix Dimensions not updating
Pull Request resolved: https://github.com/facebook/react-native/pull/31973
Test Plan:
### Steps to reproduce
1. Install the RNTester app on Android from the `main` branch.
2. Set the device auto-rotation to ON
3. Start the RNTester app
4. While the app is loading, rotate the device
5. Navigate to the `Dimensions` screen
6. Either
a. Observe the screen width and height are reversed, or
b. Quit the app and return to step 3.
### Verifying the fix
#### Manually
Using the above steps, the issue should no longer be reproducible.
#### Automatically
See unit tests in `ReactAndroid/src/test/java/com/facebook/react/modules/deviceinfo/DeviceInfoModuleTest.java`
### Video
https://user-images.githubusercontent.com/4940864/128485453-2ae04724-4ac5-4267-a59a-140cc3af626b.mp4
Reviewed By: JoshuaGross
Differential Revision: D30319919
Pulled By: lunaleaps
fbshipit-source-id: 52a2faeafc522b1c2a196ca40357027eafa1a84b
Summary:
ReactSoftException makes it seem like the class is an Exception, when it's actually a logger. This rename I think is more appropriate.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D30251735
fbshipit-source-id: 550bd543388e698774ec31753200bd3f722d8c17
Summary:
It seems that, possibly due to optimizations and refactoring elsewhere in the event system, some TouchEvents are being over-disposed.
This doesn't really pose a problem besides performance; and could even indicate that an Event was in a pool but never properly initialized. In these
cases it seems perfectly reasonable to silently continue, and to log a soft exception. This WILL still crash in debug mode, so we can gather more information
if we find a good repro; otherwise we will continue to get production data from this soft exception if it's an issue and we can investigate further.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D30061178
fbshipit-source-id: 05d1f60afc382ce0a202ac8f3de34770cf9a760d
Summary:
This diff fixes the Android View dimensions in VR
PixelUtil.toSPFromPixel and PixelUtil.getDisplayMetricDensity() are both using getScreenDisplayMetrics() to perform conversion of dimensions. This is not correct because we should take into consideration the density of the Context / Activity instead of the Screen. This problem didn't raise before in Fabric Android because it seems that android OS on phones usually share the scale between the screen and the Activity?
These two methods are only used in Fabric and they were introduced by D9583972 (https://github.com/facebook/react-native/commit/5c0da011cbaa788c52519f8091157ca6d87d8abb) and D9173758 (https://github.com/facebook/react-native/commit/8b5e3fc16b1e58441318b6ada629dcff572dd120)
As part of this diff I'm also deleting the method toSPFromPixel in favor of toDIPFromPixel because I noticed the usages of these methods are meant to use toDIPFromPixel()
changelog: [Internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29864944
fbshipit-source-id: a0a093c120bde21a6cf9e1043a83c31e870d4368
Summary:
In Fabric, we currently incur the cost of (frequently!) flushing non-Fabric UI updates, even if there are no non-Fabric views.
For now it is still possible to run both renderers at the same time, so we still largely continue to use the non-Fabric path, but only use UIImplementation if there is actually a RootView being managed outside of Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29724538
fbshipit-source-id: 0f1148870c04ca9aaed0edfd6b5c55a3756a2bd7
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary:
I suspect that T94864568 is caused by TouchEvents being dispatched after they've been recycled. This needs further analysis, but to stop the bleeding, we can drop events at the point they'd be dispatched before the crash, and log a soft error.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594749
fbshipit-source-id: f50df8df2125b83126616ceaf4e529127d154c7c
Summary:
It is unlikely but possible that the crash T94864568 is caused by a TouchEvent being initialized with a null MotionEvent. Regardless, we should guard against this case.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D29594750
fbshipit-source-id: 3a409b716a9f1eec8017002ae7e23273677e53ba
Summary:
See comments in ReactClippingProhibitedView for details and motivation behind this new feature.
You may have a View class inherit from the ReactClippingProhibitedView interface in order to enable this feature for instances of that View type.
This can be added to Views that should /never/ be clipped from the View hierarchy - namely, TTRC components or other telemetry components that always need to be rendered in order for some feature to function.
Changelog: [Added] Opt-in mechanism to allow native Android Views to be marked as "not clippable", soft exceptions will be logged if these Views are clipped from the View hierarchy
Reviewed By: sshic
Differential Revision: D29472439
fbshipit-source-id: b3be53df836b452aed5dc40514ff585ce0ad812b
Summary:
@public
When PlatformColor is used with backgroundColor, this line would throw, as the object type is not convertible to int.
Changelog:
[Android][Fixed] - Fix Crash in ViewProps.isLayoutOnly
Reviewed By: JoshuaGross
Differential Revision: D29430151
fbshipit-source-id: a1fe801925430dad3a17871bdebb79d942775280
Summary:
Changelog: [internal]
It is recommended to not use `using namespace` in the header file. It changes namespace for anything that imports the header file.
Also keeping imports in header file to minimum is recommended to lower build times.
Reviewed By: JoshuaGross
Differential Revision: D29131371
fbshipit-source-id: ad1868f6200c00023a62a00859d9a05140a12849
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:
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:
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:
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 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:
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:
Noticed while working in MobileHome with android device, when interacting with the Tasks change progress/priority components (MobileHomeTasksDetailsSelectorToken), which provides `borderRadius` style and `backgroundColor: ifSelected ? value : null`, and when `backgroundColor` is `null`, the line changed in this diff crashes (throwing the `NoSuchKeyException` at `ReadableNativeMap:110` [because of isNull check on `ReadableNativeMap:107`])
Changelog:
[Android][Fixed] - Fixed crash when using style borderRadius: any with backgroundColor: null
Reviewed By: JoshuaGross
Differential Revision: D27932828
fbshipit-source-id: 801b04c856ee9dc5a36bbf3e6e3d81de9b1e81a1
Summary:
Changes React Native so that when `accessibilityState` is used to change a view from `selected: true` to `selected: false`, the change in state is announced.
This is how `checked` works; it is unclear why Android does not do this for `selected`, too.
Changelog:
[Android][Added] - TalkBack now announces "unselected" when changing `accessibilityState.selected` to false.
Reviewed By: blavalla
Differential Revision: D27449293
fbshipit-source-id: a6d77b55d63655973ad93c4d5e3743742501f378
Summary:
This issue fixes https://github.com/facebook/react-native/issues/30955 and is a follow up to pr https://github.com/facebook/react-native/pull/24608 which added the basic Accessibility functionalities to React Native.
TextInput should announce "selected" to the user when screenreader focused.
The focus is moved to the TextInput by navigating with the screenreader to the TextInput.
This PR adds call to View#setSelected in BaseViewManager https://developer.android.com/reference/android/view/View#setSelected(boolean)
The View#setSelected method definition https://github.com/aosp-mirror/platform_frameworks_base/blob/master/core/java/android/view/View.java
```java
/**
* Changes the selection state of this view. A view can be selected or not.
* Note that selection is not the same as focus. Views are typically
* selected in the context of an AdapterView like ListView or GridView;
* the selected view is the view that is highlighted.
*
* param selected true if the view must be selected, false otherwise
*/
public void setSelected(boolean selected) {
if (((mPrivateFlags & PFLAG_SELECTED) != 0) != selected) {
// ... hidden logic
if (selected) {
sendAccessibilityEvent(AccessibilityEvent.TYPE_VIEW_SELECTED);
} // ... hidden logic
}
}
```
VoiceOver and TalkBack was tested with video samples included below.
## 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] - Fix Selected State does not announce when TextInput Component selected on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31144
Test Plan:
**<details><summary>CLICK TO OPEN TESTS RESULTS</summary>**
<p>
**ENABLE THE AUDIO** to hear the TalkBack announcing **SELECTED** when the user taps on the TextInput
```javascript
<TextInput
accessibilityLabel="element 20"
accessibilityState={{
selected: true,
}} />
```
| selected is true |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111652826-afc4f000-8807-11eb-9c79-8c51d7bf455b.mp4" width="700" height="" /> |
```javascript
<TextInput
accessibilityLabel="element 20"
accessibilityState={{
selected: false,
}} />
```
| selected is false |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111652919-c10dfc80-8807-11eb-8244-83db6c327bcd.mp4" width="700" height="" /> |
The functionality does not present issues on iOS
| iOS testing |
|:-------------------------:|
| <video src="https://user-images.githubusercontent.com/24992535/111647656-f401c180-8802-11eb-9fa9-a4c211cf1665.mp4" width="400" height="" /> |
</p>
</details>
</p>
</details>
Reviewed By: blavalla
Differential Revision: D27306166
Pulled By: kacieb
fbshipit-source-id: 1b3cb37b2d0875cf53f6f1bff4bf095a877b2f0e
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
Sometimes ```hasActiveCatalystInstance()``` is used to check if it's safe to access the CatalystInstance, which will still crash in Venice.
Previously we mitigate this by changing ```reactContext.hasActiveCatalystInstance()``` to ```reactContext.hasActiveCatalystInstance() || reactContext.isBridgeless()```.
To solve this for all and good the plan is:
1, Rename ```hasActiveCatalystInstance()``` to ```hasActiveReactInstance()``` so it won't sounds like CatalystInstance-only.
2, Implement hasActiveReactInstance() for Venice. D27343867
3, Remove previous mitigation. D27343952
This diff is the first step, by xbgs there are **58** non-generated callsites of ```hasActiveCatalystInstance()``` in code base which are all renamed in this diff.
Changelog:
[Android][Changed] - Rename "hasActiveCatalystInstance" to "hasActiveReactInstance"
Reviewed By: mdvacca
Differential Revision: D27335055
fbshipit-source-id: 5b8ff5e09b79a492e910bb8f197e70fa1360bcef
Summary:
This diff contains the code from the 35 diff stack - D27210587
This diff implement and integrates Mapbuffer into Fabric text measure system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27241836
fbshipit-source-id: f40a780df0723f27da440f709a8676cfcca63953
Summary:
There are races between BackgroundExecutor and Fabric/View teardown, where, because of the way things are set up currently, a View will strongly retain a pointer into some native State object which can keep a host of other objects alive in C++, even after stopSurface, and even after RN itself starts tearing down.
To alleviate this, we more aggressively clear State from Java, without waiting for Java GC: 1) on stopSurface, 2) whenever a State object is stale from Java's perspective.
This should allow us to keep all common updateState semantics, while only introducing a new edge-case that stateWrapper can be destroyed during mounting if stopSurface happens at the same time. In those cases, checking for NPEs should be sufficient.
The possible race condition only really happens with updateState, so it's easier to check for. There should practically be no cases where there's a race between `stopSurface` and `getState`, because `getState` is only really called around state updates and view preallocation, and never after; we still check for NPEs in those cases, but it shouldn't be an issue.
Changelog: [Internal]
Reviewed By: thurn, sammy-SC, mdvacca
Differential Revision: D26858584
fbshipit-source-id: 2ef7467220865380037d69d8de322fe8797f6a12
Summary:
Ship responsibility for most View creation logic to ViewManager, where it already largely lies, and simplify code in Fabric and non-Fabric mounting layers.
Notably, some of this work was *already* being duplicated so we can expect an extremely tiny perf gain here.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26742711
fbshipit-source-id: 4213766d4cd366bc69cd47d4654f7b269bb9e7f4
Summary:
https://github.com/facebook/react-native/issues/31051
When trying to create custom viewmanagers, we don't have props, I have a use case where I want to create views on the basis of provided react prop from react native.
## 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] [Changed] - pass initial props to ViewManager createViewInstance method in non-Fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/31053
Test Plan:
Tested Manually.
(Facebook - see D26719538, which should land first)
Reviewed By: mdvacca
Differential Revision: D26719510
Pulled By: JoshuaGross
fbshipit-source-id: ced78aa919e6b433e22ddb7c9eccc3e3e91950e9
Summary:
This diff extracts ComponentNameRegistry out of Fabric modules
This is necessary to avoid depending on Fabric and regressing APK size for other RN apps (e.g. IG)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26765328
fbshipit-source-id: 0a22c4279146f5243473c74a84e78fad7f08f956
Summary:
Simplify addLifecycleEventListener for the flaky test because we just want to test that listener is working.
Changelog:
[Android][Changed] - Add a spare implementation of addLifecycleEventListener for test purpose.
Reviewed By: PeteTheHeat
Differential Revision: D26749256
fbshipit-source-id: 5af216e6bfa37a15eb189aa24a3df35a7a7112de
Summary:
This diff moves the method getViewportOffset out of ReactRootView. This is necessary to avoid Fabric to depend from paper.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716901
fbshipit-source-id: cec67c24860a776fb361d7cda08d3142e1214c8c
Summary:
We want to be able to instrument touch processing delays in JS, which does not have access to systemUptime; therefore we want a UNIX timestamp, which JS has access to and can compare to the touch time.
It only matters that there is relative consistency between multiple touch events in JS, which is still the case; so this should have no impact on product code.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D26705429
fbshipit-source-id: 0f2db726048fcab9a30e830970d7d8a8d2eae446
Summary:
Right now the FbReactInstanceDelegate provides a list of view managers to the instance during initialization, this means that we're basically eagerly loading all of the view manager classes.
In this change we use ViewManagerResolver instead.
Changelog:
[Android][Changed] - Move ViewManagerResolver into a seperate file
Reviewed By: mdvacca
Differential Revision: D26424214
fbshipit-source-id: 550ade31c256a56d6e32c463f112ea16dd55a218
Summary:
This diff cleans listeners on the destruction of the ReactContext.
changelog: [inernal] internal
Reviewed By: JoshuaGross
Differential Revision: D26259929
fbshipit-source-id: 1843cabdac2fa3e67dcc890afd923b82472d8f66
Summary:
This diff unregisters the UIManagerModule from LifecycleEventListener during turn down of the bridge.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26239156
fbshipit-source-id: b230949228c6e580cca088c395b970a3cff94839
Summary:
Support RCTModernEventEmitter+RCTEventEmitter in an Event class(es). This improves perf in Fabric. Migrate any constructor callsites to the new constructor and deprecate the previous one.
Changelog: [Internal]
Reviewed By: PeteTheHeat, mdvacca
Differential Revision: D26056725
fbshipit-source-id: 771e5dd4cd1aeca3d2afd1a67ee58b9ac21eda79
