Commit Graph

3703 Commits

Author SHA1 Message Date
David Vacca afd836957f Fix Text paddings in Fabric
Summary:
Text paddings in Fabric are managed by LayoutMetrics, the current implementation of Fabric is incorrectly using padding data from Text Props to set the padding in the view.
This diff refactors the update of Text in Fabric in order to avoid using padding prop data

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D18211638

fbshipit-source-id: de05e7daa6185d854ce1b6580a1e44ae55d3176e
2019-10-31 14:02:49 -07:00
Elisa Lou 27d7d3fed5 update android AppearanceModule to support dark mode in all OS versions
Summary:
We no longer need to gate by OS version since we want to allow in-app theming. This diff ensures that we are passing in the updated system context to retrieve the correct app theme.

Changelog:
[Android] Enable AppearanceModule for all OS versions

Reviewed By: mdvacca

Differential Revision: D18224915

fbshipit-source-id: 42d5db8497d8bead32c49e3e2a25d4ba779e2b33
2019-10-31 10:05:38 -07:00
Joshua Gross 426868b6c2 Add enable_nullify_catalyst_instance_on_destroy MC and gate setting mCatalystInstance to null in ReactContext
Summary:
Mostly for easing open-source migration and not making a backwards-incompatible change (yet), we'll set this to false by default. Every app can opt-in to this if wanted but it's not necessary. This change is part of experiments surrounding more-aggressive teardown for Fabric and Bridgeless mode.

Changelog: [Internal] - This has the effect of (by default) disabling the previous diff which caused ReactContext teardown to always set mCatalystInstance to null. Now that is opt-in behavior and off by default, so it's not longer a breaking change.

Reviewed By: mdvacca

Differential Revision: D18207302

fbshipit-source-id: 7acfc894415e966f652c7049849eef79c440a135
2019-10-29 16:21:12 -07:00
Maurus Cuelenaere c2c4b43dfe Add Android support for fontVariant prop (#27006)
Summary:
Android was missing support for the `fontVariant` prop in TextViews, this PR adds that.

## Changelog

[Android] [Added] - Add Android support for fontVariant prop
Pull Request resolved: https://github.com/facebook/react-native/pull/27006

Test Plan:
Since I can't get RNTester to work locally (it crashes when loading `libyoga.so` on `No implementation found for long com.facebook.yoga.YogaNative.jni_YGConfigNew()`), I'll post some screenshots below of our app showing the difference.

We are using a slightly different [version](https://github.com/getdelta/react-native/commit/10cafcaa0798e5dbe8b56d461885fa84c6953739) of this commit, since we're still on 0.60, but the gist remains the same when rebased on master.

Before:
![Screenshot_20191025-130325__01](https://user-images.githubusercontent.com/1682432/67566586-7b3f2880-f728-11e9-85c0-57667d645153.jpg)

After:
![Screenshot_20191025-130444__01](https://user-images.githubusercontent.com/1682432/67566599-842ffa00-f728-11e9-988a-1b12ee393b83.jpg)

Differential Revision: D18179642

Pulled By: mdvacca

fbshipit-source-id: 03a050aa76e7bafa0343354dfa778cf74af5abd2
2019-10-29 00:29:20 -07:00
Marco Munizaga 6ebd3b046e Cap selection indices when text changes (#26680)
Summary:
This PR https://github.com/facebook/react-native/pull/22723 cached selections, so if you had a cached selection indicies, but updated the text to be an empty string, then this would crash.

As reported in https://github.com/facebook/react-native/issues/25265 and other issues of `setSpan(4 ... 4) ends beyond length`

## Changelog

[Android] [fixed] - Crash in TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/26680

Test Plan:
```
input.setNativeProps({ text: "xxx", selection: {"begin": 0, "end": 3}});
input.setNativeProps({ text: ""});
```

Differential Revision: D18189703

Pulled By: cpojer

fbshipit-source-id: 67d9615a863fd22598be8d6d4553dec5ac8837ed
2019-10-28 22:38:53 -07:00
Joshua Gross 0bea6a9b19 Work around ancient race condition in ReactInstanceManager
Summary:
See T55861104. In rare cases if `removeReactInstanceEventListener` is called right after (like, a small number of CPU instructions later, on a different thread) we allocate the `listeners` array with a certain size, then we could have one or more `null` listeners in the array, which is what we've been seeing in prod, at very low volumes, for several years. Without solving the root of the race condition we can just add a null check here.

Maybe it's also possible that if `addReactInstanceEventListener` is called on another thread in a racey way, that the size will be incremented on the array before we can access the additional member. That seems crazy, but maybe.

While this has been firing for multiple years it seems like a more recent change caused a regression. This diff doesn't address that and only resolves the crash.

Changelog: [Internal]

Reviewed By: ejanzer

Differential Revision: D18192801

fbshipit-source-id: c1000cfcdf6f251b03061d1386eabb9f0617a7d3
2019-10-28 19:28:01 -07:00
Joshua Gross aa27645cf0 Guard against UIManagerHelper.getUIManager returning null
Summary:
Because the `mCatalystInstance` of the ReactContext can be null during teardown, there are technicaly cases where `UIManagerHelper.getUIManager` can return null. In those cases we check for a CatalystInstance and raise a SoftException, and return null. We must then guard in every case where we call `getUIManager` to prevent NullPointerExceptions.

See T56103679.

Currently crashes are coming from `PropsAnimatedNode.restoreDefaultValues` calling `UIManagerModule.synchronouslyUpdateViewOnUIThread` on teardown/at the end of an animation as RN is being torn down.

This can happen in both Paper and Fabric.

In dev this will still crash because the SoftException will trigger a crash. It will be a noop with logged warnings in production builds.

Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D18165576

fbshipit-source-id: 7059e04ca339208dd64a0a08a375b565cb8cda02
2019-10-27 23:13:33 -07:00
Joshua Gross b55146f776 Check that CatalystInstance is active for non-NativeModule callsites of ReactContext.getJSModule
Summary:
In previous diffs I migrated many (all?) NativeModules in FB and open-source to check for `hasActiveCatalystInstance` before calling `getJSModule`. We log SoftExceptions in those cases to find more potential race condition and lifecycle bugs without crashing.

In this diff, I migrate all the non-NativeModule callsites that I could find.

Previous diffs: see D18032458, D18035359, D18032788, D18092136, D18092137, D18112989, D18134400

Changelog: [Internal]

Reviewed By: mdvacca, mmmulani

Differential Revision: D18134694

fbshipit-source-id: 4729abfb84280b634463b1cd9b4dd808f310b6e7
2019-10-25 16:16:00 -07:00
Joshua Gross 9446277fc1 Simplify API of getReactApplicationContextIfActiveOrWarn
Summary:
Simplify the API of `getReactApplicationContextIfActiveOrWarn`. We don't need to pass so much information into this method to collect good SoftExceptions.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D18134400

fbshipit-source-id: 0a250ab0252a44121f3339a31506a0a6c4c7cd35
2019-10-25 16:16:00 -07:00
David Vacca a1a56fe4e5 Add NonNull annotation to FabricUIManager API
Summary:
This diff annotates FabricUIManager class with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients

Changelog: Add NonNull annotation to FabricUIManager API

Reviewed By: JoshuaGross

Differential Revision: D18010917

fbshipit-source-id: 760ba04b78693cb184172c0fe613c7f808a49031
2019-10-25 15:11:53 -07:00
David Vacca a8ce2dcf89 Refactor logging of Fabric React Markers when running on the UI Thread
Summary:
This diff refactors the execution of the logging of Fabric React markers to be executed after the MountItems are executed on the UI Thred
Changelog: Improve logging of Fabric react markers

Reviewed By: JoshuaGross

Differential Revision: D18010920

fbshipit-source-id: e36306102d190119a89c16e660b855acab1528fe
2019-10-25 15:11:52 -07:00
David Vacca c5321e8514 Refactor the cancellation of DispatchUIFrameCallback
Summary:
This diff refactors the stopping of DispatchUIFrameCallback on FabricUIManager to make it thread safe

Changelog: Refactor the cancellation of dispatching of Mounting operations for Fabric

Reviewed By: JoshuaGross

Differential Revision: D18010922

fbshipit-source-id: 305bc65576698cb785a2a2308cbd03db4a9a97e4
2019-10-25 15:11:52 -07:00
David Vacca 619e27e9a1 Annotate core classes of Fabric with NonNull and Nullable annotations
Summary:
This diff annotates core classes of Fabric with NonNull and Nullable annotations, this will help analysis of nullability plus improving integration with Kotlin clients

Changelog: Add NonNull annotation to Fabric core classes

Reviewed By: shergin

Differential Revision: D18010918

fbshipit-source-id: 40fe68470b97cdf740f52dfeb9130465aab5e6df
2019-10-25 15:11:51 -07:00
David Vacca a58fcbff0b Add NonNull annotation to Fabric Event classes
Summary:
This diff annotates Fabric MountingManager and Events classes with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients

Changelog: Add NonNull annotation to Fabric Event classes

Reviewed By: shergin

Differential Revision: D18010923

fbshipit-source-id: fb9d5683bbd51fa25dda9b2023f9c411c3ff541d
2019-10-25 15:11:50 -07:00
David Vacca 27d71fc725 Make sure MountItems use @NonNull annotation
Summary:
This diff annotates MountItems classes with NonNull annotations, this will help analysis of nullability plus improving integration with Kotlin clients
Changelog: Add NonNull annotation to Fabric MountItems

Reviewed By: JoshuaGross

Differential Revision: D18010921

fbshipit-source-id: 4c2bded87f7af1ddb941b2a49e390e51984890c0
2019-10-25 15:11:50 -07:00
David Vacca ed905027cd Add support for Text.textBreakStrategy prop into RN Android for Fabric
Summary:
This diff extends the rendering on Text on Android to support textBreakStrategy prop.

Changelog: Add support for Text.textBreakStrategy prop into RN Android for Fabric

Reviewed By: JoshuaGross

Differential Revision: D18101403

fbshipit-source-id: c7f0b1cdc0de05172f0978d4dd3493620dcd941a
2019-10-24 19:55:15 -07:00
Joshua Gross 94cb4bf90c In modules or classes that call ReactApplicationContext.getJSModule, ensure that there's still a CatalystInstance alive
Summary:
In D18032458 we introduce getReactApplicationContextIfActiveOrWarn. In this diff, modules that access a JS or Native module through ReactApplicationContext need to check if the CatalystInstance is still alive before continuing.

Modules that don't derive from `ReactContextBaseJavaModule` manually check for the catalyst impl and log their own SoftExceptions.

In this diff we also introduce SoftExceptions that by contract never cause crashes, even in debug mode.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D18112989

fbshipit-source-id: 868f01f388aa2db3518db9f873f2afc2a62eed45
2019-10-24 17:29:08 -07:00
Emily Janzer e7f6210d5d Don't attempt to connect to React devtools every 2s
Summary:
When testing out the NetworkOverlay, I noticed that we were creating a lot of WebSocket connections for localhost:8097. Rick found that this is because we're trying to connect to React devtools every 2 seconds: https://github.com/facebook/react/blob/master/packages/react-devtools-core/src/backend.js#L67 and it appears we create a new WebSocket every time.

Dan suggested that we use opening the dev menu as a trigger for attempting to connect to React devtools. This diff uses RCTNativeAppEventEmitter to emit an event from native when the dev menu/dialog is shown, and listening to that event in JS to attempt to connect to devtools.

I'm also making the change of passing in a websocket instead of just passing in the host + port; this way it will only attempt to connect once on each call to `connectToDevTools` (otherwise, we would attempt to reconnect every 2 seconds as soon as the dev menu is opened, and then the next time the menu is opened we'd so start that *again*, and so on - I could have it keep track of whether it's already connecting and avoid doing it again, but this is easier and should be sufficient, I think).

We should probably also update the suggested troubleshooting tips on the devtools page to reflect this change, so that people don't get confused.

Changelog: [General] [Fixed] Fix issue where we attempt to connect to React devtools every 2 seconds

Reviewed By: mmmulani

Differential Revision: D17919808

fbshipit-source-id: 4658d995c274574d22f2f54ea06d7f29ef2f54dc
2019-10-23 10:30:43 -07:00
Emily Janzer 6b3d4e41ee Convert WebSocket module to TurboModule
Summary:
Implement the TurboModule interface in WebSocketModule.

Changelog: [Internal]

Reviewed By: mdvacca, RSNara

Differential Revision: D17587622

fbshipit-source-id: 6135ad79955c014a648cd29e21e91c71bbee5d44
2019-10-22 19:34:39 -07:00
David Vacca d9f7f99d91 Report error if font size value is zero or negative
Summary:
Text font size should not be negative, this diff throws an exception if TextView uses negative of zero font size

Changelog: [[internal]]

Reviewed By: shergin

Differential Revision: D18068071

fbshipit-source-id: 4074dca2019b6223eef68a407570258adbceaa43
2019-10-22 18:07:00 -07:00
David Vacca 229fa32ab6 Fix TextAlign prop in Fabric
Summary:
Text didn't support horizontal textAlign in Fabric for Android, this diff fixes that

Changelog: Add support for TextAlign prop in Fabric

Reviewed By: makovkastar

Differential Revision: D18068072

fbshipit-source-id: 3f8b1ba46989b55197fe9aa60ba2fb055b003d67
2019-10-22 14:30:23 -07:00
Joe Loser ba18ee9b87 Replace folly::make_unique with std::make_unique (#26730)
Summary:
There is a mixed usage of `folly::make_unique` and `std::make_unique`. Soon, `folly::make_unique` may be removed (see [this PR](https://github.com/facebook/folly/pull/1150)). Since `react-native` only supports C++14-compilers and later, switch to always using `std::make_unique`.

## Changelog

[Internal] [Removed] - Replace folly::make_unique with std::make_unique
Pull Request resolved: https://github.com/facebook/react-native/pull/26730

Test Plan:
Running the existing test suite. No change in behavior is expected.

Joshua Gross: buck install -r fb4a, make sure MP Home and forced teardown works okay on android

Reviewed By: shergin

Differential Revision: D18062400

Pulled By: JoshuaGross

fbshipit-source-id: 978ca794c7e972db872a8dcc57c31bdec7451481
2019-10-22 12:21:41 -07:00
Moti Zilberman 468d1a2d2e Render collapsed frames in RedBox
Summary:
Renders frames in RedBox in a greyed-out style when their `collapse` field is set to `true`. This avoids outright hiding information in the stack trace while still drawing attention to frames that are likely to be more meaningful.

Changelog: [General] [Changed] - Render collapsed JavaScript frames in RedBox

Reviewed By: rickhanlonii

Differential Revision: D18039438

fbshipit-source-id: 527588f11c0bff495842be7036cd1293bab65eb9
2019-10-22 11:05:36 -07:00
David Vacca 7935174d48 Fix negative letterspacing in Fabric android
Summary:
This diff adds support for negative letterspacing values in Fabric android
Changelog: add support fot negative letterspacing values in Fabric android

Reviewed By: JoshuaGross

Differential Revision: D18054648

fbshipit-source-id: de1b906e6b8c0b021ffdc2e4bdad243075230667
2019-10-22 10:20:04 -07:00
Joshua Gross 2ea33044bd Use getReactApplicationContextIfActiveOrWarn in modules that access JS or Native modules through ReactApplicationContext
Summary:
In D18032458 we introduce `getReactApplicationContextIfActiveOrWarn`. In this diff, modules that access a JS or Native module through ReactApplicationContext need to check if the CatalystInstance is still alive before continuing.

Changelog: [Internal]

Reviewed By: furdei

Differential Revision: D18032788

fbshipit-source-id: 5152783afd0b93b8ce0970fe4a509ea71396a54a
2019-10-21 15:59:21 -07:00
Joshua Gross b12a29cfcb Implement getReactApplicationContextIfActiveOrWarn in ReactContextBaseJavaModule to generalize checking hasActiveCatalystInstance and warning when it's dead
Summary:
In three previous diffs (D18020359 D17998627 D17969056), I implemented this logic in three different modules. There are potentially hundreds of modules where we should be implementing this check, so I'm moving the important logic into ReactContextBaseJavaModule.

Additionally, `WebSocketModule` was retaining its own copy of ReactApplicationContext instead of using the built-in `getReactApplicationContext`, so I removed that ivar from `WebSocketModule`.

Changelog:
[Internal]

Reviewed By: mdvacca

Differential Revision: D18032458

fbshipit-source-id: 9114120d3b80334df8d2e0813e36d21c667fc1bd
2019-10-21 15:59:21 -07:00
David Vacca e21ed675ec Refactor FabricSoLoader to ensure sDidInit is accessed correctly
Summary:
sDidInit can be accessed from different threads, this diff refactors the definition of this variable to be volatile and also to be assigned at the end of the staticInit() method.

Changelog:
Ensure proper initialization of FabricSoLoder

Reviewed By: ejanzer

Differential Revision: D18010919

fbshipit-source-id: 3ec7b19fdc15056b90fc01281b8c3888e93a7dd3
2019-10-21 14:42:45 -07:00
Joshua Gross cd12f256e9 Change tearDownReactContext ordering to prevent null assertion
Summary:
In `tearDownReactContext`, `reactContext.destroy()` sets `mCatalystInstance` to null. We cannot call `reactContext.getCatalystInstance()` after that without hitting an assertion. Change ordering so that doesn't happen in reload or teardown.

Changelog: [Internal]

Reviewed By: makovkastar

Differential Revision: D18041279

fbshipit-source-id: 22658dc506b76cf58aee1008841abacfe9410c9d
2019-10-21 11:47:39 -07:00
David Vacca 585dfff22b Disable preallocation of views in Mounting layer of fabric
Summary:
This diff adds an experiment to disable the preallocation of views on the mounting layer of Fabric

Changelog:
Add a ReactNativeConfig to configure the preallocation of views in the mounting layer of Fabric

Reviewed By: shergin

Differential Revision: D17949681

fbshipit-source-id: 0af63df22aff9e94289bc8a8217c79222f1fd61c
2019-10-21 11:47:39 -07:00
Joshua Gross 1e9d4cde4b Wait until everything is destroyed before returning from CatalystInstanceImpl.destroy
Summary:
CatalystInstanceImpl.destroy does a bunch of stuff in each of the relevant threads (Native Module thread, JS thread, UI thread).

This change creates a V1 destroy method (unchanged) and a V2 destroy method. The goal is to resolve (and catch!) race conditions in native modules and JSI modules that could occur during teardown; and mitigate race conditions that occur in RN teardown, like deallocation of C++ objects (scheduler, JS VM, and UIManager for Fabric).

Changelog:
[Internal] Experiment to fix deallocation race conditions

Reviewed By: mdvacca

Differential Revision: D18001677

fbshipit-source-id: 5955da0a7b726491c7d749642475f0fba74cce5a
2019-10-19 02:30:09 -07:00
Joshua Gross 9ddc038e54 WebSocketModule should verify that Catalyst is alive before getting a JS module
Summary:
WebSocketModule can be called asynchronously while the ReactContext/CatalystInstance is being torn down. Trying to get a JS module at this time will result in a crash if the ReactContext has already torn down Catalyst. Check explicitly that Catalyst is still alive before trying to emit an event to JS via some JS module.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D18020359

fbshipit-source-id: 1b77abd457c7d97bd241389251890bb682b6fde3
2019-10-19 02:30:09 -07:00
Joshua Gross 46a28e5460 AppStateModule should verify that Catalyst is alive before getting a JS module
Summary:
AppStateModule can be called indirectly when the ReactContext is torn down. Trying to get a JS module at this time will result in a crash if the ReactContext has already torn down Catalyst. Check explicitly that Catalyst is still alive before trying to emit an event to JS via some JS module.

Changelog: [Internal]

Reviewed By: ejanzer, mdvacca

Differential Revision: D17969056

fbshipit-source-id: dd446de57280e588a73f3e228bac82b3d67ecdc0
2019-10-19 02:30:09 -07:00
Joshua Gross f8bf65b8fd Make sure FabricUIManager doesn't double-free Binding, or double-destroy itself
Summary:
While unlikely, in exceptional cases it's possible that `onCatalystInstanceDestroy` is called multiple times, especially since there's no restrictions as to which thread this is called on (currently it's only called on the JS thread from CatalystInstanceImpl) and no synchronization. Make sure it tears down cleanly if called multiple times, and report soft exceptions if that's detected.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D18001678

fbshipit-source-id: 4a7c37b5b3c2207ba1dd9c7d85690391f799518d
2019-10-19 02:30:08 -07:00
Joshua Gross 95a43f3366 Set mCatalystInstance to null when destroying ReactContext
Summary:
We want ReactContext to blow up if it tries to use `mCatalystInstance` after `destroy` is called.

Changelog:
[[Internal]]

Reviewed By: mdvacca

Differential Revision: D17944723

fbshipit-source-id: cfe8a8b98473f53dd68bbcd91a71f58bd7a0c503
2019-10-19 02:30:08 -07:00
Joshua Gross 526a010ad7 Add ThreadConfined(UI) to CatalystInstanceImpl.destroy
Summary:
This already has an assert that `destroy` should only be called on the UI thread. Add an annotation.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D17989113

fbshipit-source-id: fd44f321cbcb7f0a18383ca6226cce72e5991eea
2019-10-18 15:08:53 -07:00
Andres Suarez aee88b6843 Tidy up license headers [3/n]
Summary: Changelog: [General] [Fixed] - License header cleanup

Reviewed By: yungsters

Differential Revision: D17952693

fbshipit-source-id: 8fcb8e58a2e04e7a3169f4d525bffc00835768e6
2019-10-16 10:06:34 -07:00
Andres Suarez 3b31e69e28 Tidy up license headers [2/n]
Summary: Changelog: [General] [Fixed] - License header cleanup

Reviewed By: yungsters

Differential Revision: D17952694

fbshipit-source-id: 17c87de7ebb271fa2ac8d00af72a4d1addef8bd0
2019-10-16 10:06:34 -07:00
Andres Suarez 722feeb02b Tidy up license headers [1/n]
Summary: Changelog: [General] [Fixed] - License header cleanup

Reviewed By: yungsters

Differential Revision: D17952695

fbshipit-source-id: 81aa607612ba1357ef7814ef20371335151afe7e
2019-10-16 10:06:33 -07:00
Joshua Gross a440613654 Add ThreadConfined(UI) annotations to relevant methods in ReactContext
Summary:
Add ThreadConfined(UI) annotations to relevant methods in ReactContext.

Changelog:
[[Internal]]

Reviewed By: mdvacca

Differential Revision: D17944686

fbshipit-source-id: ce93c6ffa2a523532cbe709650054638412da59e
2019-10-16 00:19:34 -07:00
Joshua Gross 71d2c07c6e Unconditionally log when destroying FabricUIManager
Summary:
Unconditionally log when destroying FabricUIManager.

Changelog:
[[Internal]]

Reviewed By: mmmulani

Differential Revision: D17944621

fbshipit-source-id: 89f97ff966ae5b071eb0b50d888b41b264d9dab9
2019-10-16 00:19:34 -07:00
Andres Suarez e1cfeaddd4 Move non-license comments out of license header
Summary: Changelog: [General] [Fixed] - License header cleanup

Reviewed By: cpojer

Differential Revision: D17749100

fbshipit-source-id: edca9c73a065e9fc311109cd6efeb1f75451a55a
2019-10-15 20:12:12 -07:00
David Vacca c65267ca6f Allow update of state to receive null objects
Summary:
This diff changes updateState method to support null stateWrappers, before this method would crash with a NullPointerException, now it allows the null object to reach the view manager.

Changelog: Add support for update of nullable localState in Fabric

Reviewed By: JoshuaGross

Differential Revision: D17939651

fbshipit-source-id: c62555905e39f9e0db75b9e1d1b93f33d0560266
2019-10-15 18:52:26 -07:00
Sharon Gong baa66f63d8 Announce accessibility state changes happening in the background (#26624)
Summary:
Currently the react native framework doesn't handle the accessibility state changes of the focused item that happen not upon double tapping. Screen reader doesn't get notified when the state of the focused item changes in the background.
To fix this problem, post a layout change notification for every state changes on iOS.
On Android, send a click event whenever state "checked", "selected" or "disabled" changes. In the case that such states changes upon user's clicking, the duplicated click event will be skipped by Talkback.

## Changelog:
[General][Fixed] - Announce accessibility state changes happening in the background
Pull Request resolved: https://github.com/facebook/react-native/pull/26624

Test Plan: Add a nested checkbox example which state changes after a delay in the AccessibilityExample.

Differential Revision: D17903205

Pulled By: cpojer

fbshipit-source-id: 9245ee0b79936cf11b408b52d45c59ba3415b9f9
2019-10-14 00:28:34 -07:00
Joshua Gross fa1c2be387 Slightly more aggressive FabricUIManager teardown
Summary: Tear down FabricUIManager more aggressively. The rest of the ivars here we can't set to null (yet) because they're marked as final.

Reviewed By: mdvacca

Differential Revision: D17878342

fbshipit-source-id: a1c8ace2603750ac39c3d97e1aca6c486ba5fb79
2019-10-11 11:41:37 -07:00
Pavol Fulop c35a419e5d Make android modal to appear underneath translucent StatusBar (#26706)
Summary:
As described in https://github.com/facebook/react-native/issues/26559 , the modal is not appearing underneath translucent StatusBar so you can see previous view underneath the StatusBar instead. As a solution you can now provide prop to set the modal to have translucent StatusBar and therefore the content will appear underneath. I tried to reuse layout flags that are possibly set if you use StatusBar component but sadly values in them do not reflect the props set by StatusBar component.

## Changelog

[Android] [added] - Added statusBarTranslucent prop to Modal component, to indicate if StatusBar should appear translucent.
Pull Request resolved: https://github.com/facebook/react-native/pull/26706

Test Plan:
### With StatusBar translucent

![image](https://user-images.githubusercontent.com/3984319/66131336-8bfdf200-e5f3-11e9-940e-c6bb3f67ea6f.png)

``` <Modal statusBarTranslucent>```
### Without

![image](https://user-images.githubusercontent.com/3984319/66131403-a768fd00-e5f3-11e9-9814-ff7592b4ceac.png)

``` <Modal>```

Differential Revision: D17872874

Pulled By: mdvacca

fbshipit-source-id: 8c4b48a75cddf86c4429b62d0c63313e7a2dd1b8
2019-10-10 22:14:23 -07:00
Joshua Gross 7c20dc65d9 Add asserts and annotations for FabricUIManager UI-thread methods
Summary: These methods are (or should be) only called on the UI thread. Make those assumptions explicit.

Reviewed By: mdvacca

Differential Revision: D17865205

fbshipit-source-id: 9b3acf8f3215a07b1a667ced55e50e99a488de79
2019-10-10 22:01:10 -07:00
Joshua Gross 299eb9f440 Explicitly set mBinding to null in FabricUIManager
Summary: Although `mBinding` is unregistered which means the connection to the JNI-bridged Cxx object can be destructed, we still hold onto the `mBinding` Java object after unregistering. That doesn't seem desirable, I think we should just clear it out here for consistency.

Reviewed By: mdvacca

Differential Revision: D17865206

fbshipit-source-id: 1ad8643c48ba0b2d52620a7b8ebe8a52928648ef
2019-10-10 20:36:56 -07:00
Joshua Gross c82e27030c Add UI thread assertions and annotations to ReactRootView
Summary:
Add UI thread assertions and annotations to ReactRootView. Shouldn't have any immediate effect since these methods already call other methods that assert they're on the UI thread. Doing this to hoist assumptions higher up.

Doing some very simple refactoring to the way cleanup happens to ensure aggressive cleanup in more instances.

Reviewed By: shergin

Differential Revision: D17860291

fbshipit-source-id: c87e0336594fa2327271b648eb8340e250235250
2019-10-10 14:38:32 -07:00
Oleksandr Melnykov 1dc03f4858 Back out "[react-native][PR] Set rounded rectangle mask on TouchableNativeFeedback's ripples"
Summary: This PR caused a regression with shadows, see https://github.com/facebook/react-native/issues/26544.

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D17809320

fbshipit-source-id: 0c83cd211425622ada0fd8c492f43df0536a4b8a
2019-10-09 10:39:04 -07:00
David Biedenbach df9abf7983 Fix Issue 23870: Android API - View.getGlobalVisibleRect() does not properly clip result rect for ReactClippingViewGroups (#26334)
Summary:
This PR addresses issue https://github.com/facebook/react-native/issues/23870 (`View.getGlobalVisibleRect()` is broken in some use cases)

The issue affects the following Android APIs:
- ViewGroup.getChildVisibleRect()
- View.getGlobalVisibleRect() (Which calls into ViewGroup.getChildVisibleRect)
- View.getLocalVisibleRect() (Which calls into View.getGlobalVisibleRect())

According to Android documentation, View.getGlobalVisibleRect() should provide a rect for a given view that has been clipped by the bounds of all of its parent views up the view hierarchy. It does so through the use of the recursive function ViewGroup.getChildVisibleRect().

Since React Native has a separate clipping mechanism that does not rely on Android UI's clipping implementation, ViewGroup.getChildVisibleRect() is unable to determine that a rect should be clipped if the clipping view is a ReactClippingViewGroup. This resultantly breaks some important use cases for things like testing with Detox, which relies on this functionality to tell when a component is on-screen, as explained in the above referenced issue.

The rationale of the fix is essentially to implement logic analogous to [ViewGroup.getChildVisibleRect()](https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/view/ViewGroup.java#6176), discarding irrelevant Android clipping modes, and instead testing against the 'overflow' property, restoring the originally intended functionality. This is implemented as an override to ViewGroup.getChildVisibleRect() in the following classes:

 - ReactViewGroup
 - ReactScrollView
 - ReactHorizontalScrollView

Unfortunately, since the public ViewGroup.getChildVisibleRect() API recurses into a `hide` annotated API which cannot be overridden, it was necessary to provide this override in each of the above React Native classes to ensure the superclass implementation would not be called, which would break the recursion.

## Changelog

[Android] [Fixed] - View.getGlobalVisibleRect() clips result rect properly when overflow is 'hidden'
Pull Request resolved: https://github.com/facebook/react-native/pull/26334

Test Plan:
The functionality in question is neither used internally nor exposed by React Native, and thus only affects Android native modules that use the above referenced APIs.

As such, I have primarily performed testing with a forked example project that had been submitted with issue https://github.com/facebook/react-native/issues/23870, originally by d4vidi.

The example project can be found here:
- [Configured to build against RN Master](https://github.com/davidbiedenbach/RNClipVisibilityBugDemo/tree/rn-master)
- [Configured to build against PR branch](https://github.com/davidbiedenbach/RNClipVisibilityBugDemo/tree/fix-23870)

(Original project here: https://github.com/d4vidi/RNClipVisibilityBugDemo)

### Bug in effect:

When built against RN master, it can be observed that fully clipped views are reported as visible, as in the below screenshots.

#### Views inside a ReactViewGroup do not report as clipped

![BugScreen1](https://user-images.githubusercontent.com/1563532/64999573-314b6300-d89d-11e9-985e-294bd51a0ba9.jpg)

#### Views inside a ReactScrollView do not report as clipped

![BugScreen2](https://user-images.githubusercontent.com/1563532/64999580-38727100-d89d-11e9-8186-96b25c937edc.jpg)

#### Views inside a ReactHorizontalScrollView do not report clipping properly

![BugScreen4](https://user-images.githubusercontent.com/1563532/64999588-3f00e880-d89d-11e9-9477-7b79e44c5e46.jpg)

### Bug fixed

When built against the PR branch, fully-clipped views no longer report visible.

#### Views inside a ReactViewGroup report clipping properly

![FixScreen1](https://user-images.githubusercontent.com/1563532/64999634-6b1c6980-d89d-11e9-8534-b26b638bf4d8.jpg)

#### Views inside a ReactScrollView report clipping properly

![FixScreen2](https://user-images.githubusercontent.com/1563532/64999641-7079b400-d89d-11e9-8f95-4d6e28bcf833.jpg)

#### Views inside a ReactHorizontalScrollView report clipping properly

![FixScreen4](https://user-images.githubusercontent.com/1563532/64999645-74a5d180-d89d-11e9-9754-170bb3b620a2.jpg)

Reviewed By: mdvacca

Differential Revision: D17782658

Pulled By: yungsters

fbshipit-source-id: 0cd0d385898579a7a8a3e453f6ba681679ebe496
2019-10-07 22:23:12 -07:00