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 (e3367354cc), 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
Summary:
This diff fixes an IllegalArgumentException that's thrown when creating layout with negative width.
This is not a new bug, but it started firing recently (probably caused by a change in text being measured)
stacktrace:
```
stack_trace: java.lang.IllegalArgumentException: Layout: -2 < 0
at android.text.Layout.<init>(Layout.java:265)
at android.text.Layout.<init>(Layout.java:241)
at android.text.BoringLayout.<init>(BoringLayout.java:179)
at android.text.BoringLayout.make(BoringLayout.java:61)
at com.facebook.react.views.text.TextLayoutManager.createLayout(TextLayoutManager.java:290)
at com.facebook.react.views.text.TextLayoutManager.measureText(TextLayoutManager.java:384) [inlined]
at com.facebook.react.views.text.ReactTextViewManager.measure(ReactTextViewManager.java:172) [inlined]
at com.facebook.react.fabric.mounting.MountingManager.measure(MountingManager.java:349) [inlined]
at com.facebook.react.fabric.FabricUIManager.measure(FabricUIManager.java:461)
at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
```
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28015820
fbshipit-source-id: 129cd2a4c492d95d57fcdf3883b967a0b5df639a
Summary:
This change broke some animations on non-Fabric surfaces due to inconsistent batching of animation operations.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013968
fbshipit-source-id: 2f65c799dbe00168f1e756ef0af60206df5a8fcc
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
Summary:
Changelog: [internal]
Prevent redundant calls to RuntimeExecutor by making sure no two calls to the executor are scheduled at the same time.
Reviewed By: mdvacca
Differential Revision: D27989412
fbshipit-source-id: 8f9b1591f7c9c2265fd4b05bf3dc5505ffc2568b
Summary:
With D27975839, RuntimeExecutor will be able to start flushing the queued up NativeModule calls in every call from C++ -> JavaScript. We're going to test this feature to measure its impact. In this diff, I wire up the the MobileConfig to ReactFeatureFlags.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27978112
fbshipit-source-id: 47e1e74398c62755bb0fdc6b54b7fd3aa47eb877
Summary:
## Motivation
With the bridge, every call into JS flushes the queue of NativeModule calls. Fabric bypasses this mechanism, because it uses a RuntimeExecutor that schedules work directly on the JavaScript thread. This diff makes Fabric's RuntimeExecutor also flush the queue of NativeModule calls.
This likely won't fix anything in Fabric, because we don't execute any async NativeModule calls on Fb4a. However, this is necessary for the drainMicrotask work we're doing in D27729702 (7310847758), because (1) we need to drain the Hermes microtask queue on every call from C++ -> JavaScript (2) we drain the microtask queue [inside JSIExecutor::flush()](de477a0df6/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp (L427),L445).
Changelog: [Android][Fixed] - Flush JSIExecutor in Fabric's RuntimeExecutor
Reviewed By: JoshuaGross
Differential Revision: D27975839
fbshipit-source-id: 27f031fb36593253da116a033e30998475eb1473
Summary:
By the time that we call [ReactContext.assertOnNativeModulesQueueThread()](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/bridge/ReactContext.java?commit=747a25280435d276fb975ccfe36fd5e60254c4e4&lines=355%2C359), ReactContext.mNativeModulesMessageQueueThread must be non-null. This implies that two things must have happened:
1. We initialized the ReactContext
2. After initialization, ReactContext.mNativeModulesMessageQueueThread must be non-null.
According to T85807990, ReactContext.mNativeModulesMessageQueueThread is null. Since ReactContext doesn't ever write to ReactContext.mNativeModulesMessageQueueThread aside from during initialization, it must mean that we either didn't initialize properly, or we initialized, but set the NativeModules thread to null. This diff throws IllegalStateExceptions inside ReactContext initialization, which should help narrow down the crash in T85807990.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D27729355
fbshipit-source-id: e39030b7db8862ae76fb644efaafb382a79b8ad0
Summary:
D27682424 (ea1ff374de) updated how animated node batches are executed in Fabric. On Paper, these batches were controlled by native module in some places (batch was executed ~every 2 frames), but some animations were switching animation batching control to JS globally there as well.
This change updates two things:
- If batching is controlled by native, it makes sure batches are calculated correctly.
- At the same time, this change switches control for animation node batching to JS, aligning it with Fabric.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27939659
fbshipit-source-id: d6251bce2a303a4a007dc10297edc0175cc4b348
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:
This diff replaces all usages of int by int32_t. This is to ensure we always use a fixed size for int that matches what's expected on Java.
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27915608
fbshipit-source-id: 634c45796dda1d4434c3ad6ff3e199931c22940b
Summary:
Adds surface id for string logs of the IntBufferBatchMountItem to help debug updates with multiple surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27884232
fbshipit-source-id: c5ec65585830f7aa5b902603bcd1e91b61cfe4c1
Summary:
Refactor MapBufferBuilder to use int to store size of Mapbuffer data
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27904646
fbshipit-source-id: 6b8b96fdd30184b6d35c1d612743eae653854d6d
Summary:
DynamicData can contain a big amount of data, refactoring type to use int instead of short
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904643
fbshipit-source-id: 157064b280e27a9c7c4a4f55af310392b178feda
Summary:
Add extra asserts and early deallocation in ReadableMapBuffer::importByteBufferAllocateDirect
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27904645
fbshipit-source-id: 075a007c4ec5e005b839add054bd68c233b65801
Summary:
This diff fixes the importByteBufferAllocateDirect method.
This was tested enabling importByteBufferAllocateDirect in ReadableMapBuffer.java
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27867055
fbshipit-source-id: 9ef5e93ff6c7903782598dde1c499daa82cd467b
Summary:
To fix [the CI error](https://app.circleci.com/pipelines/github/facebook/react-native/8708/workflows/d584348e-941f-4653-96c2-46375894dfaa/jobs/196410)
There are two errors:
`error: undefined reference to '__android_log_write'` which solved by adding `-llog` linker flag.
`ld: error: cannot find -lc++` which workaround by static linking.
For the root cause, I am thinking that is after [NDK r19](https://developer.android.com/ndk/guides/other_build_systems),
the `-target` should specificy api level.
However, buck does not add this accordingly, e.g. `-target armv7-none-linux-androideabi`
Given wrong target will make NDK to have `cannot find -lc++` error.
The workaround is to use static linking.
Since it was an oss_cxx_library, the change should not have impact to Facebook internal testing.
## Changelog
[Internal] [Fixed] - Fix CI "Build Tests: Android Instrumentation Tests" errors
Pull Request resolved: https://github.com/facebook/react-native/pull/31352
Test Plan: Make CI green
Reviewed By: JoshuaGross
Differential Revision: D27757838
Pulled By: fkgozali
fbshipit-source-id: 8f9c80a89c6240938218abacb8a82e3e2e71adbc
Summary:
Changelog: [Internal]
Inverts registration of a SurfaceHandler with the scheduler: instead of passing a scheduler to the SurfaceHandlerBinding, we can now query the SurfaceHandler and register it in place.
Reviewed By: JoshuaGross
Differential Revision: D27624541
fbshipit-source-id: db5d7f1375fad72a805309a3fcd5a33080e4a4a7
Summary:
Changelog: [Internal]
Links APIs in Fabric and Venice to create a surface without a view and mount it separately when surface is started the usual way.
Reviewed By: mdvacca
Differential Revision: D27339365
fbshipit-source-id: d1b674ce856957465eb6f3a5d7f26eb0ab625353
Summary:
Changelog: [Internal]
`NativeAnimatedModule` on Android currently enforces all animation operations to be processed in batches to ensure that all associated operations are processed at the same time.
Some operations, however, can be triggered outside of the batching calls (e.g. when using `Animated` for tracking touches `PanResponder`), and they are not processed until the next batch.
This change tracks if we are currently processing a batch and doesn't assign a batch number if an operation was triggered outside of `startOperationBatch`/`finishOperationBatch` pair.
Reviewed By: mdvacca
Differential Revision: D27682424
fbshipit-source-id: 2ea8737c353c81557fa586b15aa5760db3e8813f
Summary:
This diff moves DisplayMode out of SurfaceHandler, this is necessary in order to use it from react/uimanager package
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27669846
fbshipit-source-id: 274869d8f2907b1b159f51240440acece09a746f
Summary:
Extends https://github.com/facebook/react-native/pull/30694 to fix tests.
OkHttp v4 was released almost a year ago. Even though v3 is still receiving security and bug fixes, most of the new improvements and features are landing in v4. This PR bumps OkHttp from v3 to v4 and addresses backward-incompatible changes.
Side effects of this upgrade:
- OkHttp v4 depends on Kotlin's standard library, so react-native will have a transitive dependency on it.
- The dex method count of test apk has exceeded the maximum, so multidexing had to be enabled for android tests.
## 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] - Bumping OkHttp from v3 to v4.
Pull Request resolved: https://github.com/facebook/react-native/pull/31084
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: fkgozali
Differential Revision: D27597430
Pulled By: ShikaSD
fbshipit-source-id: 967379b41c2bcd7cfd4083f65059f5da467b8a91
Summary:
## Rationale
- AsyncDevSupportManager.loadSplitBundleFromServer() is an override of DevSupportManager.loadSplitBundleFromServer(), which is used by the bridge. However, AsyncDevSupportManager.loadJSBundleFromServer() has no bridge analogue. This is confusing: Are the methods in AsyncDevSupportManager Venice overrides for bridge related methods? It's easy to think yes, but the answer is no.
- AsyncDevSupportManager.loadJSBundleFromServer() is an additional layer of indirection that provides very little value: all it does it create the JSBundleLoader, and call onReactContextCreated. However, it does so in 11 lines of very confusing code.
A discussion we don't have to have now: Inheritance hierarchies are very difficult to understand and de-tangle. So, instead of using inheritance to make DevSupportManager work with Venice (via AsyncDevSupportManager), should we just refactor DevSupportManager so that it can be customized to work with Venice?
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27577591
fbshipit-source-id: b64dcd65e9a7c85b89443d860d441a0635547916
Summary:
Changelog: [Internal]
After D27016919, some mounting instructions can be executed before the view is attached, which is invalid. This change adds additional queue for such items, which can be later dispatched after view is ready.
The new queue is expected to be empty for usual rendering and used in prerendering flows only. In case of prerendering, it should only hold intermediate items between early start of `SurfaceHandler` and view attach.
Reviewed By: mdvacca
Differential Revision: D27291706
fbshipit-source-id: f383c1d0d7050f271993553b51bf2e387efe1e9e
Summary:
Changelog: [Internal]
Adjusts SurfaceMountingManager to allow starting surface without a view and attaching the view while surface is active.
This change is only meant to work with ReactSurface to allow creating `SurfaceHandler` without mounting views.
Reviewed By: mdvacca
Differential Revision: D27016919
fbshipit-source-id: 995383bc4f1bd298953516007743ffae0edf17c2
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:
Previously I renamed hasActiveCatalystInstance() API in D27335055 (dfa8eb0558), however this API is still used in an OSS class.
In this diff hasActiveCatalystInstance() is added back and marked as Deprecated to avoid breakages and leave the migration choice to OSS users.
Changelog:
[Android][Changed] Mark hasActiveCatalystInstance() as Deprecated
Reviewed By: yungsters
Differential Revision: D27538449
fbshipit-source-id: 30f2f890580ad7f8b41908e18013234b5bac72e9
Summary:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.
To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D27436402
fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
Summary:
D26581756 (86321a35c0) was hacked for fixing T85822390, which was later properly fixed in D27369721, so I removed it in this diff.
Changelog:
[Android][Fixed] - Remove previous fix for "Fix text in ReactTextView sometimes being vertically displayed"
Reviewed By: mdvacca
Differential Revision: D27501405
fbshipit-source-id: 81417069d355936721868ce659b3fe8ce916302e
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:
`InternalNode` will eventually not have a pointer to its parent. This diff removes one of the usages of the `InternalNode#getParent()` API. `InternalNode` will also not host the `YogaNode` eventually; so this diff also removes one of the usages of the `InternalNode#getYogaNode()` api.
Now the `Inputs#freeze` api will pass the parent's `YogaNode` and the `YogaNode` of the node (this) being measured.
Changelog: [Internal] Passes The YogaNode and parent YogaNode in the Inputs.freeze API
Reviewed By: SidharthGuglani
Differential Revision: D27240229
fbshipit-source-id: efc4ec3249a963c3181111f9b989d8ed9e17feb4
Summary:
We need to do this to break a dependency cycle that would happen if we try to have `view` depend on `mounting` just to add some telemetry to `view`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26827446
fbshipit-source-id: 4c415ebf5be3a02c18c80ea8a4a77068cae0f0fe
Summary:
Create YogaProps Interface; this interface represents the inputs to YogaNode for layout calculation.
Changelog: [Internal] Create YogaProps Interface; this interface represents the inputs to YogaNode for layout calculation.
Reviewed By: mihaelao
Differential Revision: D27229274
fbshipit-source-id: 5205caf2384661369d7a2d7e7f3e49ff831a1c92
Summary:
Instead of annotating individual methods with DoNotStrip, we actually want to ensure that nothing in this class gets stripped out.
This also upgrades the yoga/proguard-annotations package for Gradle builds.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27335181
fbshipit-source-id: 5b696c26faf4d1b32a3fd885e42a996aff23f0be
Summary:
android fbjni dependency bump to 0.2.2
The motivation is to address https://github.com/pytorch/pytorch/issues/34682 that pytorch_android and react-native use different versions of fbjni with the same name libfbjni.so
In case of loading 0.0.2 version it is missing functions in binary
Fbjni is not changing much, that's why this will solve that problem for a long time (Until fbjni changed and versions will not be aligned)
## Changelog
[Android][Added] fbjni version bump to 0.0.3
Pull Request resolved: https://github.com/facebook/react-native/pull/31191
Test Plan: Automated (relying on the test suite) and manual testing.
Reviewed By: passy
Differential Revision: D27330370
Pulled By: IvanKobzarev
fbshipit-source-id: 2ea07d80d23f8dbc80e946a8818c1ecb8eb746e8
Summary:
Changelog: [Internal]
FabricUIManager contains a lot of logic related to mounting items and manipulating dispatch queues, which can be safely extracted outside. Apart from decreased logical complexity, this change enables easier modification of the queuing behavior later in this stack.
Majority of the changes is caused by moving existing logic to a different class, no change in behavior expected.
Reviewed By: JoshuaGross
Differential Revision: D27271116
fbshipit-source-id: 86fe45b19bb839f96fde8ba607f72006f6401cc7
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:
The non-Fabric API has a `blockNativeResponder` param in setJSResponder. Make sure to pass that along in Fabric.
On Android this allows us to respect the flag and do the same thing non-Fabric was doing if `blockNativeResponder` is false. It's not clear yet what the impact is on iOS.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27058806
fbshipit-source-id: aa5074fa46191d78f5292a93d9040ab4bb58ca66
Summary:
Media picking wasn't working for Venice because we didn't implement onActivityResult in BridgelessReactFragment so the listener in FBProfileGemstoneReactModule didn't called.
Changelog:
[Android][Changed] - Added Nullable annotation
Reviewed By: mdvacca
Differential Revision: D27045861
fbshipit-source-id: 0ab2961ef0570d92259856b4132507ebb264eb9d
Summary:
On Android we have the notion of "virtual views", which are defined consistently but the logic is scattered and duplicated throughout the codebase.
The logic exists to mark nodes that exist in the ShadowTree, but not the View tree. We want to CREATE, UPDATE, and DELETE them on the platform, but not INSERT or REMOVE
them. They basically exist as EventEmitter objects.
The only issue with this is (1) duplicated code, which opened the possibility for inconsistent definition (2) StubViewTree did not account for virtualized views, which caused
assert crashes in debug mode for certain LayoutAnimations on Android.
By moving the definition to ShadowViewMutation and accounting for it in StubViewTree, asserts are correct and consistent on all platforms.
This was not caught until recently, because, until recently, no asserts actually ran on Android.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27001199
fbshipit-source-id: eb29085317037ba8a286d7813bdd57095ad4746f
Summary:
In DevSupportManagerBase.java->updateLastErrorInfo(), errorType was not recorded like errorMessage and errorStack, we could either remove errorType as a parameter or recorded it for future use. This diff recorded it since it would make the error info complete.
Changelog:
[Android][Changed] - Record latest error type in dev support
Reviewed By: PeteTheHeat
Differential Revision: D26884647
fbshipit-source-id: 712d82667bdc4b3410f4c83a3df9a456af6d9061
Summary:
Changelog: [Internal]
We were using RN util to get pixel density, but it depends on the surface being created after venice instance is initialized. Given that we have context every time we update constraints, it makes sense to use it directly.
Reviewed By: mdvacca
Differential Revision: D26959430
fbshipit-source-id: 78701786efd82857812df689a725ba094fbd226e
Summary:
Just adding more logs I found useful while playing around with the last diff (to verify that these methods were not actually implicated at all).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26972725
fbshipit-source-id: 0e048e1edbfbe5ed32c5277f17a7197e0afdc04f
Summary:
When the height of a HorizontalScrollView changes and there is a `layout` event, it can cause the underlying platform View code to scroll slightly to the right.
I'm... not really sure why, even after looking at the View code for a while. But it is clearly detectable and mirrors issues with RTL that were fixed recently.
This might warrant more investigation, but I believe the fix is relatively safe - we detect if there's an autoscroll only if the height changes and only if the scroll happens in "layout". That scopes the hack pretty well to just this bug.
There aren't really times when we actually want layout to scroll to the right, so... I think this is reasonable.
Changelog: [Changed][Android] Fixed issue that causes HorizontalScrollView to shift to the right when a TextInput is selected and keyboard pops up
Reviewed By: mdvacca
Differential Revision: D26972710
fbshipit-source-id: 441b1a3f07b9b68195a9e5e9a0c8d75c9d24a109
Summary:
Does not impact prod or even debug builds unless you switch on the debug flag. The issue is that we were trying to coerce booleans to integers.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D26970274
fbshipit-source-id: 3327029ae3afc307dd19b089c23c190cb9e3150c
Summary:
This NativeModule will now be type-safe, and TurboModule-compatible.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26956332
fbshipit-source-id: 6651a003c70819934869dd6a8c664ef984d0efcb
Summary:
Create MC to gate execution of JS Responder in Fabric Android
MC.react_fabric.enable_js_responder_fabric_android is enabled by default in the server
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26905296
fbshipit-source-id: 82504174394d1e10fd017435cccd38952404fda0
Summary:
We can override the `scrollTo` method and it's likely/possible that Android internals are calling scrollTo directly. So, we can capture
more cases where the scroll position is changing and needs to be updated in Fabric State.
Unfortunately we still cannot override smoothScrollTo because it is marked as final. For now we just keep the custom `reactSmoothScrollTo` method
and hope that we can catch more cases with `scrollTo`.
Changelog: [Internal]
Reviewed By: sammy-SC, mdvacca
Differential Revision: D26887028
fbshipit-source-id: e2678f1a20640d598abbec9671d6102635f65bb2
Summary:
Changelog: [Internal]
Updates `ReactSurface` to use `SurfaceHandler` internally.
This removes most of the internal state in `ReactSurface` and propagates all the calls to the `SurfaceHandler`.
`FabricUIManager` now uses `SurfaceHandler` to start/stop the surface.
SurfaceId is still used for view operations. SurfaceId is also now mutable to play better with existing Android infra.
Reviewed By: shergin, mdvacca
Differential Revision: D26112992
fbshipit-source-id: 52e6860084d739381317035dc3011956d452063c
Summary:
Followup to D26858584 (00959ffd6b). We should also immediately destroy C++ state memory (which will decrement a shared_ptr) when deleting a view.
This could improve memory while a surface is being used.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26876537
fbshipit-source-id: fc8353bed47db8fdbf5c7f6c6253ac788c460d9a
Summary:
NativeModules have an initialize() method that they use to allocate any resources, set up listeners, etc. This diff imports that method into the TurboModule interface. This way, we don't have to cast TurboModules to NativeModules to initialize them. Also, it makes sense to import this initialization mechanism into the TurboModule infra.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871552
fbshipit-source-id: b8ae515b22928ed678b4003096e0756e991e10ff
Summary:
This diff migrates all NativeModules away from onCatalystInstanceDestroy() to the invalidate() method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D26871595
fbshipit-source-id: 132f6b75e485361835769a2b53bc742eefa47b59
Summary:
## Rationale
The CatalystInstance is going away after we delete the bridge. So, we should migrate away from onCatalystInstanceDestroy() to something else: invalidate().
## Changes
- Introduce the NativeModule.invalidate() cleanup hook.
- Both the NativeModule and TurboModule infra now call this invalidate() method, **as opposed to** onCatalystInstanceDestroy(), to perform NativeModule cleanup.
- **Is this safe?** All our NativeModules extend BaseJavaModule. BaseJavaModule.invalidate() delegates to NativeModule.onCatalystInstanceDestroy(), so NativeModules that implement onCatalystInstanceDestroy(), but not invalidate(), still have their onCatalystInstanceDestroy() method called.
Changelog: [Android][Deprecated] - Deprecate NativeModule.onCatalystInstanceDestroy() for NativeModule.invalidate()
Reviewed By: JoshuaGross
Differential Revision: D26871001
fbshipit-source-id: e3bdfa0cf653ecbfe42791631bc6229af62f4817
Summary:
When debugging this class a lot, I found it helpful to have these logs and it would have been nice if they were here already - I had to rewrite these several times.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26836318
fbshipit-source-id: 08eb9ae19923fc593d1aba031586a02a193d6b2d
Summary:
changelog: [internal]
There were three separate problems preventing measure infra to work correctly with views inside horizontal scroll view in RTL environment.
1. Initial offset is wasn't communicated to Fabric. This is resolved separately as it doesn't affect only RTL: D26778991 (630ac87591).
3. On Android when layout direction is RTL, offset of scrollview is calculated from right.
Reviewed By: mdvacca
Differential Revision: D26779860
fbshipit-source-id: 61572c78091a1f5417102eb38d88ba7d172e6102
Summary:
Whenever layout updates in a horizontal scrollview, in RTL mode we adjust the position - the impact *should* be that initially, we jump from position 0 to the right side of the scroll view,
such that scrolling starts from the right.
However, we were doing this entirely too aggressively before. We should only make this adjustment *if the layout changes the width*.
Changelog: [Android][Changed] Fixed jumpy RTL horizontal ScrollViews. If you have Android-specific JS hacks for handling RTL in ScrollViews, you probably can/probably want to remove them, because they should be reliable now and require fewer hacks.
Reviewed By: mdvacca
Differential Revision: D26771366
fbshipit-source-id: de11bd1cae1414018d88ce44b3583a8b15f3b330
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:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859161
fbshipit-source-id: 654c055c53c0e420c6d9f2b0135055aec34269c9
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859157
fbshipit-source-id: 754a5b4ede8defa8b7742cc42e09cc7cbfe4e18d
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859160
fbshipit-source-id: ce84deafd1f20d1680d333d1a176b0493623a4ee
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859205
fbshipit-source-id: 5398d24d2592de3fbb80ca59192b5b46543aa5c5
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859159
fbshipit-source-id: 8e47cedd4b218a47b33d1209f3ede2fd1531015d
Summary:
If modules are *not* eagerly init'd and expect lifecycle events, make sure (1) onHostResume is called immediately it it's currently active and (2) that listeners are removed in onCatalystInstanceDestroy.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26859158
fbshipit-source-id: 4966d3c49d194c4cb4063edf3a035f6077b76cd9
Summary:
I'm not sure what broke this, but in some cases, DialogModule doesn't get subscribed to LifecycleEventListener events.
This seems to fix it.
Changelog: [Internal]
Reviewed By: mdvacca, RSNara
Differential Revision: D26856016
fbshipit-source-id: 868baf102b85b202180adcbb8bb181dfe603188f
Summary:
Found this crash when rendering ReactEditText under Venice, from comment it's supposed to be called only in Paper, so I adde a Venice check to avoid calling this method.
{F446844248}
Changelog:
[Android][Changed] - Add a new check to avoid calling this method
Reviewed By: mdvacca
Differential Revision: D26781457
fbshipit-source-id: f4c2e890156a37e35aa153c736b50924254e67bc
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:
Changelog: [internal]
StateWrapperImpl shouldn't retain State strongly because cleanup of `StateWrapperImpl` is triggered from Java and isn't guaranteed to take happen before runtime is destroyed.
This should resolve crash where `StateWrapperImpl`'s destruction causes a `~Pointer` to be called after runtime is destroyed.
Chain of ownership that will be broken by storing State weakly inside `StateWrapperImpl`.
`StateWrapperImpl -> ParagraphState -> TextLayourManager's cache -> AttributedString -> ShadowView -> EventEmitter -> EventTarget -> Pointer`
{F451105831}
Reviewed By: JoshuaGross
Differential Revision: D26815275
fbshipit-source-id: 0703c6dccc62c1d152923b786a83273fa8a03694
Summary:
setRemoveClippedSubviews in ReactHorizontalScrollContainerView.java in RTL mode is overzealous and unexpectedly clips out views in a way that is not desirable.
It seems like what is actually happening is that the computed rect for the view is "0,0" and so contents are assumed to always be outside of this rect.
For now I've disabled this feature. We can investigate as a followup.
Changelog: [Android][Changed] Clipping subviews has been temporarily disabled in HorizontalScrollView in RTL mode. Minor/negligible perf impact.
Reviewed By: sammy-SC
Differential Revision: D26808937
fbshipit-source-id: 85af9c3fb542db9ca3aae03413a475695cd53391
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:
This diff integrates the ComponentNameResolver class into ReactInstanceManager
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716900
fbshipit-source-id: e3a5f44485f659a32bf6094eee7985daf634f50f
Summary:
This diff introduces the ComponentNameResolverManager and ComponentNameResolver classes. The purpose of these classes is to integrate NativeComponentRegistryBinding into RN Android
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26716899
fbshipit-source-id: c62fb5c38ddce5325890d2506a6fb17d26043175
Summary:
Changelog: [internal]
Calling `scrollTo` does not report offset change to Fabric core and measure infra can't compute correct values. This results in unresponsive buttons if horizontal scroll view on Android has initial offset set to anything besides default value 0.
Reviewed By: JoshuaGross
Differential Revision: D26778991
fbshipit-source-id: 5cad5cb9926c7923f6efcd56cb4e15c3b958c245
Summary:
## Summary
Bump Android compileSdkVersion and targetSdkVersion to 30
## Changelog
[Android][Changed] Bump Android compileSdkVersion and targetSdkVersion from 29 to 30
Pull Request resolved: https://github.com/facebook/react-native/pull/31078
Test Plan: Circle CI and Sandcastle
Reviewed By: mdvacca
Differential Revision: D26765188
Pulled By: hramos
fbshipit-source-id: a971641cea4860df58ce6e9b0f14405bfc4e0979
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 removes an unnecessary dependency from react buck module
This was causing a regression in apk size in IG
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26755329
fbshipit-source-id: bc45d9717bb0343cd26ed2ccbaa016b55f56b9bf
Summary:
Timestamp is computed differently now and uses system millis as the basis for a monotonic clock. Updating this fixes tests.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26739611
fbshipit-source-id: 4908da68e1c126ea2b0772aaf408d892798549aa
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:
In Fabric we're seeing setJSResponderHandler called during teardown of a surface, which causes a crash because the SurfaceId is no longer available at that point.
Guard against setJSResponderHandler being called on a dead surface.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26734786
fbshipit-source-id: 838d682ee0dd1d4de49993fa479dc2097cf33521
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:
I thought we'd need LayoutDirection on the platform at some point, but it turns out we never use it, and don't seem to need it since components just query via `I18nUtil` one time,
and it's expected that apps restart if language changes and we need to switch between LTR and RTL. So, it seems like we'll not have any need for this on the platform at any point.
And we can save a byte per layout instruction now. Huzzah!
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26660908
fbshipit-source-id: 54c7d132f5fa260a93fc7f09f7cf63059d52ed1f
Summary:
We recently fixed RTL scrolling in Fabric on iOS: D26608231 (e5921f7f38)
Turns out, the mechanism for RTL scrolling on Android is completely different. It requires that content be wrapped in a "directional content view", which is `View` in LTR and `AndroidHorizontalScrollContentView` in RTL, backed by `ReactHorizontalScrollContainerView.java`.
iOS doesn't require that and just uses View and some custom logic in ScrollView itself.
In the future it would be great to align the platforms, but for now, for backwards-compat with non-Fabric and so we don't have to tear apart ScrollView.js, we codegen the AndroidHorizontalScrollContentView so it exists in C++, register the component, and stop mapping it to View explicitly in C++.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26659686
fbshipit-source-id: 3b9c646dbdb7fe9527d24d42bdc6acb1aca00945
Summary:
Changelog: [Internal]
Adds react_debug dependency in Android.mk where it was missing
Reviewed By: mdvacca
Differential Revision: D26617400
fbshipit-source-id: 5ac799269b106eadd881d30490ac34bd2134a9b7
Summary:
## Issue:
Sometimes ReactTextView are vertically displayed as one column with bridgeless.
## Root cause:
After debugging, I found out this is caused by a workaround in 2016 to fix a crash caused by mLayout occasionally being non-null and triggers relayout during setText.
https://github.com/facebook/react-native/pull/7011
## Fix
Revert previous hack, if the crash happens again I'll try to fix it.
Changelog:
[Android][Fixed] - Fix text in ReactTextView sometimes being vertically displayed
Reviewed By: mdvacca
Differential Revision: D26581756
fbshipit-source-id: a373d84dc1ab3d787bda7ec82f2d0865a354cf60
Summary:
The purpose of this change is to make TTRC markers work similarly for bridge loading and bridgeless loading so we could compare performance between them.
There are mainly four cases involved:
```REACT_BRIDGE_LOADING_START,
REACT_BRIDGE_LOADING_END,
REACT_BRIDGELESS_LOADING_START,
REACT_BRIDGELESS_LOADING_END
```
First 2 are for beginning/ending of bridge loading which includes creating fragment, loading JS bundle, running JS bundle and creating react instance. Last 2 are for similar purpose with bridgeless.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D26514499
fbshipit-source-id: 65d6f3cc7de9e07a7a3a802dd77138e74c23aa5b
Summary:
Change lifecycle of stopSurface in a subtle way: mark the surface as stopped in Java first, then in Cxx (currently it happens in Cxx, then Java).
This will cause us / allow us to ignore the final mounting instructions for the Surface, which are all irrelevant since they just have to do with View removal.
We can rely on GC and `unmountReactApplication` to do all of this for us, and save some CPU cycles on stopSurface.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D26469741
fbshipit-source-id: a7f81d44c3cb2138f0ab31feb38852910410c638
Summary:
If there's a JS/native crash and the surface is stopped, the ReactRootView could be reused when the surface is restarted (or potentially to show the errors in a logbox; I'm don't think that's possible, but not 100% sure).
Regardless, now it will crash in those cases because of T83802049. There's no reason to do that, so just mark the ReactRootView as explicitly unused once the surface is stopped.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D26469742
fbshipit-source-id: ee79c094393a8ae8b5c53f04c14b90bc8e1a5a17
Summary:
Litho needs a new API which is called immediately before yoga begins layout calculations so that the InternalNode gets the opportunity to finalise itself; i.e. perform the last mutations and in effect avoid any more mutations to the hierarchy.
See D26373731 where the mutations from `Layout#collectResults` is moved back into the InternalNode.
Changelog: [Internal] Adds new API to YogaNodeJNIBase
Reviewed By: SidharthGuglani
Differential Revision: D26373730
fbshipit-source-id: 471346d3444986ada91e86c95f5f9fb98bcd2fa6
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:
Now we use SurfaceHandler-based APIs to control surfaces in `Binding.cpp` on Android instead of using Scheduler-based APIs.
This is a transitional change; eventually, we will need to wrap C++ SurfaceHandler's into JNI wrappers. For now, it will allow to clean up the C++ part.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D26375641
fbshipit-source-id: 6f293e79cecf50de72294e90d5243ebb02d71236
Summary:
This bug doesn't reproduce anymore in v301+. MC has been enabled since december
https://www.internalfb.com/intern/logview/details/facebook_android_javascripterrors/419f8892e7b1a02f205810219ddfc299/trends?selected-logview-tab=All%20Traces&drillstate={%22start%22:%22Thu,%2028%20Jan%202021%2000:59:54%20-0800%22,%22end%22:%22Thu,%2011%20Feb%202021%2000:59:54%20-0800%22,%22constraints%22:[{%22col%22:%22mid%22,%22op%22:%22==%22,%22vals%22:[%22419f8892e7b1a02f205810219ddfc299%22]}],%22context%22:%22facebook_android_javascripterrors%22,%22metric%22:%22count%22}
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D26398484
fbshipit-source-id: ca85ca211f1a38aa2691f150956a27c878d243bc
Summary:
TurboModuleManager used to be provided by a JSIModules package. In D26193053 (13f100f788), we moved TurboModuleManager creation off JSIModules. However, we didn't move the creation outside the JSIModules guard. So, when there were no JSIModules registered, we simply wouldn't create the TurboModuleManager. This diff fixes that mistake.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26380674
fbshipit-source-id: 66939d11205b1d2eccd8c3b59ca4782e90645cd9
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## 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 source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:
Now:
Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Summary:
In addViewAt, we have this check. Add this same check to removeViewAt.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26381475
fbshipit-source-id: 1050377aa4e528668446fd561ff09c61f27c700f
Summary:
Remove out of data TODO
changelog: [internal] internal
Reviewed By: PeteTheHeat
Differential Revision: D26144400
fbshipit-source-id: c5a97ce98cd7251e40adc15c16fceed4b9c76f81
Summary:
In this diff I'm adding debug assertions to verify that there are no overflows when muptiplying layout metrics by the pointScaleFactor
Ideally these should crash the app, but I'm trying to be conservative.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D26297396
fbshipit-source-id: 068c60f4d89ea9cfd04a2e2174da2043ae150928
Summary:
We have no evidence of this happening on Android, but we are hitting a similar invariant on iOS. Adding this to Android for debugging purposes.
For now it's a SoftException to catch in debug and capture information; if we don't hit this prod at all, we'll elevate to a hard crash.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26281585
fbshipit-source-id: 8ea9cf3ac555b13bf311f24c81bbbbc2845521d5
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 clears the internal maps of NativeModuleRegistry during turn down of the bridge.
This is necessary for a proper cleanup of these modules.
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D26239303
fbshipit-source-id: 6e98e5db60a4f54d02e99b03339b03c17ecc183d
Joshua Gross
David Vacca
Andrei Shikov
sangeethaKP
fabriziobertoglio1987
Kacie Bawiec
Paige Sun
Nadiia D
Samuel Susla
Ramanpreet Nara
Peter Laraia
Lulu Wu
CodemodService FBSourceBuckFormatLinterBot
Kudo Chien
Mike
Araz Abishov
grgr-dkrk
Tim Yung
Aditya Sharat
Ivan Kobzarev
generatedunixname89002005287564
Gaurav Gupta
Héctor Ramos
generatedunixname89002005325676
Valentin Shergin
Igor Klemenski
