Commit Graph

112 Commits

Author SHA1 Message Date
Joshua Gross 4f3b174120 Guard against setId being called on the ReactRootView outside of RN core
Summary:
The RootView being managed by Fabric should have an id of View.NO_ID when it is "handed over" to RN. This is true for Fabric and non-Fabric
and setting a custom id on the ReactRootView has never been supported. I'm temporarily (?) adding an additional check earlier and into ReactRootView to hopefully
catch any of these issues early.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D26077509

fbshipit-source-id: 59e1ec080504e50698acc654c29120f039238a96
2021-01-26 10:51:28 -08:00
Joshua Gross 47cd7edf14 Fix race between initial updateRootLayoutSpecs and startSurface
Summary:
In some cases, onMeasure/onLayout are called on the RootView before `startSurface` in Fabric has been able to set surfaceId on the RootView.

With the new SurfaceMountingManager, this causes a crash because we need a valid surfaceId to perform an operation. Before the SurfaceMountingManager refactor, a surfaceId of 0 would be passed to `mBinding.setConstraints` in the FabricUIManager, and setConstraints in C++ noops if there's an invalid surfaceId.

For now, FabricUIManager will also fail silently if the surfaceId is invalid when updateRootLayoutSpecs is called, just to be conservative and to be consistent with previous behavior. This will be upgraded to a hard-crash in the future.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D26051266

fbshipit-source-id: ca2d80f899cdba9b3962af68546bd83b77be0680
2021-01-25 12:53:08 -08:00
David Vacca 5a37773e53 Fix race condition in FabricUIManager.StartSurface method
Summary:
This diff fixes a race condition in the execution of FabricUIManager.StartSurface method.
The rootcause is that startSurface is executing getViewportOffset from a background thread.

changelog: [internal]

Reviewed By: shergin

Differential Revision: D25617154

fbshipit-source-id: 9351201088164e74bb0b9454e30651e1de0da912
2020-12-17 16:18:13 -08:00
David Vacca 3ac7a4d6ba Prevent ReactRootView to load UIManagerModule when running with Fabric Enabled
Summary:
Prevent ReactRootView to load UIManagerModule when running with Fabric Enabled

changelog: [Internal]

Reviewed By: ejanzer

Differential Revision: D25453879

fbshipit-source-id: 98e88db17a86ae60e14efb070df9b2da082ae127
2020-12-09 20:59:31 -08:00
David Vacca 74a756846f Fix race condition on startSurface
Summary:
The root cause of this bug is a race condition between the onMeasure method and setupReactContext.

ReactInstanceManager.attachRootView() method is responsible of the initialization of ReactRootViews and it is invoked by ReactRootView.onMeasure() method in the UIThread

Important initialization steps:
1. Clear the Id of the ReactRootView
2. Add the ReactRootView to the mAttachedReactRoots
3. Call StartSurface (if the bridge has been initialized)

Sometimes, when this method is invoked for the first time, the bridge is not initialized, in those cases we delay the start of the surface.

Once the bridge is initialized, StartSurface is called by the setupReactContext() running in the NativeModuleThread.

Since onMeasure can be called multiple times, it is possible that we call "StartSurface" twice for the same ReactRootView, causing the bug reported on T78832286.

This diff adds an extra check to prevent calling "StartSurface" twice. The fix is done using an AtomicInteger comparison and it is gated by the flag "enableStartSurfaceRaceConditionFix". Once we verify this works fine in production we will clean up the code, remove the flags and maybe revisit the API of ReactRoot.

changelog: [Android] Fix race-condition on the initialization of ReactRootViews

Reviewed By: JoshuaGross

Differential Revision: D25255877

fbshipit-source-id: ca8fb00f50e86891fb4c5a06240177cc1a0186d9
2020-12-04 19:58:10 -08:00
Joshua Gross 2e6eea8390 Remove enableStopSurfaceOnRootViewUnmount feature flag
Summary:
This feature flag (enableStopSurfaceOnRootViewUnmount) was used to gate usage of the "stopSurface" API, which is now fully supported, and has been used
in the FB app for several months. This is safe to ship in code.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D25275192

fbshipit-source-id: fa22bfd00aa023297bc19c83c138f133e9ff1645
2020-12-02 20:10:00 -08:00
Joshua Gross f1fbfebccb Add ReactRootView perf markers
Summary:
Add three markers for ReactRootView perf logging: onMeasure, attachToReactInstanceManager, and updateLayoutSpecs.

It is suspected that one or all of these have regressed under Fabric in some cases.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D24909635

fbshipit-source-id: 6b6c0cc792c4b2d72f2360d6cffc02ef00e8a88b
2020-11-12 15:54:58 -08:00
ajpaulingalls 0e9296b95d Update the cached dimensions when orientation changes (#30324)
Summary:
Currently the dimensions are created once, and then cached.  This change will reload the dimensions when the device orientation changes to insure that dimension update events follow orientation changed events.

this should help address the following issues, that I know of:
https://github.com/facebook/react-native/issues/29105
https://github.com/facebook/react-native/issues/29451
https://github.com/facebook/react-native/issues/29323

## 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] - Dimension update events are now properly sent following orientation change

Pull Request resolved: https://github.com/facebook/react-native/pull/30324

Test Plan: Open up RNTester app.  Select the Dimensions API list item.  Rotate the device and verify that the dimensions are correct based on orientation.

Reviewed By: fkgozali

Differential Revision: D24874733

Pulled By: ejanzer

fbshipit-source-id: 867681ecb009d368a2ae7b67d94d6355e67dea7b
2020-11-11 11:03:19 -08:00
Joshua Gross 4b58038515 Log stack trace when unmountReactApplication is called in Fabric
Summary:
Sometimes stopSurface crashes when unmountReactApplication is called under Fabric; knowing the stack trace up to this point might assist in debugging.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D24532027

fbshipit-source-id: f350e77fb1a2de52eb146b449f1d2f6e960fa017
2020-10-26 12:33:31 -07:00
Joshua Gross 0d02c60bae Don't call FabricUIManager.stopSurface from ReactRootView with invalid ID
Summary:
There are cases under investigation where unmountReactApplication is called before the ReactRootView gets an ID; in some or all of those cases, UIManagerBinding.stopSurface cannot get the ReactFabric JSI module and crashes there.

It's still unclear why `unmountReactApplication` is being called in these circumstances - maybe another crash causing React Native teardown?

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D24214712

fbshipit-source-id: 796594653f4ff6d87088c4841b89f06cc873b46f
2020-10-09 03:15:35 -07:00
Joshua Gross c547757913 Perf improvement: don't call uiManager.updateRootLayoutSpecs on every ReactRootView.onLayout
Summary:
In D23640968 (https://github.com/facebook/react-native/commit/78b42d7fb7180102c1e8ec917dcccd2d9d4076db) I introduced a mechanism to update offsetX/offsetY whenever onMeasure/onLayout were called, to ensure that `measureInWindow` had the correct metrics and would work properly.

However, now `uiManager.updateRootLayoutSpecs` gets spammed and is called too often. For example, whenever a TextInput is focused/blurred, `uiManager.updateRootLayoutSpecs` may be called 5+ times even though
the measure specs/offsets may only change once.

Thus, we just compare with previous values before calling into the UIManager. This should give us a very small perf improvement.

Changelog: [Internal]

Reviewed By: shergin

Differential Revision: D24176867

fbshipit-source-id: f0dcc816e651a843607e9e5d40d8f3489894d4ba
2020-10-07 23:12:55 -07:00
Samuel Susla 2c896d3578 Do not attach root view until size is available
Summary:
Changelog: [internal]

# Why is text laid out twice in Fabric?

Layout constraints (min and max size) change during startup of Fabric surface.
1. `Scheduler::startSurface` is called with max size being {inf, inf}.
2. `Scheduler::constraintSurfaceLayout` is called with max size equal to viewport.

These are two operations that don't happen one after the other and on Android, CompleteRoot is called from JS before second operation is called. This triggers layout with max size {inf, inf} and later when second operation is called. Layout happens again now with correct size.

# Fix
Make sure `Scheduler::startSurface` is called with proper values and not {inf, inf}.

Reviewed By: JoshuaGross, yungsters

Differential Revision: D23866735

fbshipit-source-id: b16307543cc75c689d0c1f0a16aa581458f7417d
2020-09-28 04:20:55 -07:00
Joshua Gross 78b42d7fb7 Take viewport offset into account in UIManager.measureInWindow
Summary:
D23021903 (https://github.com/facebook/react-native/commit/154ce789723f6e65785bcfc00da399ad9184bdfb) but for Android.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23640968

fbshipit-source-id: 7a743ebd0ea2b573d6ef17b418ad98ec616b11d3
2020-09-11 13:43:26 -07:00
fabriziobertoglio1987 45954ac5dc keyboardDidHide wrong screenY coordinates with windowTranslucentStatus=true (#29292)
Summary:
This issue fixes https://github.com/facebook/react-native/issues/27526, related issue https://github.com/facebook/react-native/issues/27089
Avoid returning the wrong screenY coordinates on event keyboardDidHide.
getWindowVisibleDisplayFrame retrieves the overall visible display size in which the window this view is attached to has been positioned in. This takes into account screen decorations above the window, for both cases where the window itself is being position inside of them or the window is being placed under then and covered insets are used for the window to position its content inside. In effect, this tells you the available area where content can be placed and remain visible to users, since anything below the StatusBar is not visible to the user, the method does not work with translucent StatusBar (android:windowTranslucentStatus).

This commit fixes this issues removing the white bar at the bottom of the view when using windowTranslucentStatus.

## 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] - keyboardDidHide wrong screenY coordinates with windowTranslucentStatus=true

Pull Request resolved: https://github.com/facebook/react-native/pull/29292

Test Plan:
Works in all scenarios, but **I did not change RNTester `windowTranslucentStatus`**. I would like to discuss the potential breaking changes connected to not using [getWindowVisibleDisplayFrame](https://developer.android.com/reference/android/view/View#getWindowVisibleDisplayFrame(android.graphics.Rect)) with `keyboardDidHide`.

I would be happy to build an alternative functionality to calculate the WindowVisibleDisplayFrameHeight under request from the Facebook Team.

**WITHOUT** `android:windowTranslucentStatus`

| **BEFORE** |
|:-------------------------:|
|  <img src="https://user-images.githubusercontent.com/24992535/86804255-0eca4680-c077-11ea-8c79-95ba297d05ba.gif"  />|

| **AFTER** |
|:-------------------------:|
| <img src="https://user-images.githubusercontent.com/24992535/86804265-10940a00-c077-11ea-8cb8-a304cc5de363.gif"  /> |

**WITH** `android:windowTranslucentStatus`

| **BEFORE** |
|:-------------------------:|
|  <img src="https://user-images.githubusercontent.com/24992535/86804458-3a4d3100-c077-11ea-8f3e-7c43eaa08d70.gif"  height="" />|

| **BEFORE (log)** |
|:-------------------------:|
|  <img src="https://user-images.githubusercontent.com/24992535/86806330-0d018280-c079-11ea-9266-c3bcf23a35da.png"  height="" />|

| **AFTER** |
|:-------------------------:|
| <img src="https://user-images.githubusercontent.com/24992535/86804464-3b7e5e00-c077-11ea-8487-34c87f076e5f.gif" height="" /> |

| **AFTER (log)** |
|:-------------------------:|
| <img src="https://user-images.githubusercontent.com/24992535/86806042-c4e26000-c078-11ea-9c3c-cac5319bef65.png" height="" /> |

RNTester **WITHOUT** `android:windowTranslucentStatus`

| **BEFORE** | **AFTER** |
|:-------------------------:|:-------------------------:|
|  <img src="https://user-images.githubusercontent.com/24992535/86805348-176f4c80-c078-11ea-8e2a-e2d84af5c278.gif"  width="300" height="" />| <img src="https://user-images.githubusercontent.com/24992535/86805324-13432f00-c078-11ea-9e70-fa2606eee86b.gif" width="300" height="" /> |

I remain available to do improvements. Thanks a lot. Fabrizio.

Reviewed By: JoshuaGross

Differential Revision: D22521125

Pulled By: mdvacca

fbshipit-source-id: e2cb90163abb1baa00b1916e431971b011522565
2020-07-15 13:14:41 -07:00
Joshua Gross b69041f086 Feature-flag gate stopSurface on root view unmount
Summary:
Gate stopSurface behind a feature flag.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D22054480

fbshipit-source-id: 3ea48ab46aeb3532fc7a3dd83659d7c32891ec06
2020-06-15 18:43:30 -07:00
Joshua Gross 03174f1cad Call stopSurface when ReactRootView is unregistered
Summary:
In the past, in Fabric (Android), we never called stopSurface. Ever! This is bad for memory and can cause other issues, so... let's not do that.

Instead, when the ReactRootView is being torn down, we check the View ID to see if it's a Fabric RootView, and if it is, we call Fabric's stopSurface method.

Fabric stopSurface only has impact on (1) Fabric mount instructions being executed after that point and (2) tells JS to stop running the surface, on the JS thread, asynchronously.

Anecdotally it looks like all the MountItems involved in deleting and removing views from the hierarchy are executed before stopSurface is called.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21965837

fbshipit-source-id: 5169c5a1e339fd9e016ae1234d8389b2bd30be70
2020-06-09 23:23:10 -07:00
Joshua Gross 983b0a0903 Remove logs related to T62192299
Summary:
Removing logs related to T62192299 that we don't need anymore.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D21773629

fbshipit-source-id: d16c01f87be3ed7512fe90b6e261b4c7efbd3068
2020-05-29 15:48:24 -07:00
David Vacca 09487e4e95 Cleanup ReactRootView
Summary:
This diff removes the variable 'useSurface' which wasn't beeing used in ReactRootView anymore

changelog: [Internal][Android] Internal cleanup of ReactRootView

Reviewed By: JoshuaGross

Differential Revision: D21318109

fbshipit-source-id: f850b27811608d16b22b6a3964455b172705c4c7
2020-05-01 00:19:58 -07:00
Ramanpreet Nara 9263eb5d38 Part 2: Make CatalystInstanceImpl.getNativeModule Nullable
Summary:
This is the codemod portion of the parent diff.

I modified all call-sites to `ReactContext.getNativeModule` to do a null check on the returned NativeModule.

Changelog:
[Android][Fixed] - Check if NativeModules returned from CatalystInstanceImpl.getNativeModule are null before using them.

Reviewed By: JoshuaGross

Differential Revision: D21272028

fbshipit-source-id: 6bd16c6bf30605f2dfdf4c481352063712965342
2020-04-28 12:18:17 -07:00
Joshua Gross b8664182da Remove allowDisablingImmediateExecutionOfScheduleMountItems feature flag
Summary:
No longer needed.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20747684

fbshipit-source-id: a8077519b7670d72e23267b1c1423556ec97be3f
2020-03-30 16:50:41 -07:00
Joshua Gross 6239ace5a3 For T62192299, log on AppRegistry.runApplication
Summary:
Fabric debugging.

I also have an agenda of removing all instances of `ReactConstants.TAG`, because it's overly broad and not helpful during debugging.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D20016401

fbshipit-source-id: 91e5cd7e8eb662b1a4a887c1e4e66a31ec741b46
2020-02-20 17:51:26 -08:00
David Vacca 39089b4c45 Refactor calls to UIManagerHelper.getUIManager
Summary:
This diff refactors the usages of UIManagerHelper.getUIManager() to make sure we always consider null objects.
Some of the callsites were throwing a NullPointerExcetpion, now they throw a more explicit exception.

changelog: [internal]

Reviewed By: makovkastar

Differential Revision: D19383064

fbshipit-source-id: 1806a37528e80cab1c8fdff5eb631aaf47bde819
2020-01-22 17:50:13 -08:00
Emily Janzer cc3e27d484 Don't update dimensions for a new ReactRootView if they haven't changed
Summary:
ReactRootView currently caches the last seen DisplayMetrics so we can compare them against the current values in DisplayMetricsHolder to determine if the screen dimensions have changed. (If they have changed, we emit an event to notify JS of the new dimensions).

However, ReactRootView initializes these member variables with empty DisplayMetrics, which means that the first time we check against them in onGlobalLayout, we will *always* emit an event to JS.

This seems reasonable if you only have one ReactRootView, but if you create a new RRV for each RN screen in your app, then you're going to get updated dimensions on each navigation event, even though the screen dimensions have probably not changed.

In this diff, I'm no longer storing the DisplayMetrics in ReactRootView at all, but instead am using temporary variables to check the new DisplayMetrics values against the old.

Changelog: [Android][Fixed] Only update dimensions in ReactRootView if they've changed

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D19395326

fbshipit-source-id: c01aee73064764503c9b49208032c790b83a1d29
2020-01-17 21:13:22 -08:00
David Vacca f0b6f8441b Expose SurfaceID as part ReactRootView
Summary:
This diff exposes the surfaceID as part of ReactRootView.

Changelog: [internal]

Reviewed By: JoshuaGross

Differential Revision: D18474014

fbshipit-source-id: 98f651b211d3cc4df88c6b1eb257bc12129eff57
2019-11-15 17:28:12 -08:00
Joshua Gross ce226c1f28 Fix T54997838
Summary:
Fixes T54997838 by preventing any view mutations during `onMeasure` calls.

There might still be places where this is possible, but this is where I'm seeing all the crashes currently.

See comments in ReactRootView for why views were mutated during onMeasure.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D18518591

fbshipit-source-id: 1406af8a6b0bfcc86f4cc5b451b3967f312dfd85
2019-11-14 21:23:32 -08: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
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
David Vacca aa5edca0e2 Migrate Nullable and NonNull annotations to AndroidX
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.

The purpose of this change is to bring consistency in the annotations used by the core of RN

Reviewed By: makovkastar

Differential Revision: D16054504

fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
2019-07-11 16:23:29 -07:00
Oleksandr Melnykov 6c0f73b322 Format Java code in xplat/js/react-native-github
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.

```arc f --paths-cmd 'hg files -I "**/*.java"'```

drop-conflicts

Reviewed By: cpojer

Differential Revision: D16071725

fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
2019-07-02 04:16:46 -07:00
Tim Yung 739651afa1 RN: Simplify Context Creation (Android)
Summary:
Every call site is either already using `createReactContextInBackground` correctly or guarding the invocation using `hasStartedCreatingInitialContext`. This is an unnecessary and overly complex dance that can be simplified.

This revision simplifies the use of `createReactContextInBackground` by integrating the check. This is not a breaking change.

Reviewed By: zackargyle, mdvacca

Differential Revision: D15566632

fbshipit-source-id: 7b50285c9ac6776d1297d2c9c53dff208851b722
2019-05-30 18:50:43 -07:00
Emily Janzer 298f59c5d3 Use startSurface on Android
Summary:
We currently have two different codepaths for actually rendering a surface with Fabric on iOS and Android: on iOS we use Fabric's `UIManagerBinding.startSurface` to call `AppRegistry.runApplication`, but on Android we don't; instead we use the same codepath as paper, calling `ReactRootView.runApplication`.

This diff does a few different things:
1. Unify iOS and Android by removing the `#ifndef` for Android so that we call `startSurface` for both
2. Pass through the JS module name on Android so that this actually works (it currently passes in an empty string)
3. Remove the call to `ReactRootView.runApplication` for Fabric so that we don't end up doing this twice
4. Copy over some logic that we need from `ReactRootView.runApplication` (make sure that root layout specs get updated, and that content appeared gets logged)

Reviewed By: mdvacca

Differential Revision: D15501666

fbshipit-source-id: 5c96c8cf036261cb99729b1dbdff0f7c09a32d76
2019-05-28 12:23:00 -07:00
nossbigg cea0a2b61a Set duration=0 for android keyboard events (#24994)
Summary:
Set duration=0 for android keyboard events. Brings actual implementation closer to existing flowtypes, and duration is set to 0 to minimize impact on existing keyboard event consumers.
Follow up to #24947, upon cpojer's [input](https://github.com/facebook/react-native/pull/24947#issuecomment-494681618) :)

## Changelog

[Android] [Added] - Set duration=0 for android keyboard events
Pull Request resolved: https://github.com/facebook/react-native/pull/24994

Differential Revision: D15449394

Pulled By: cpojer

fbshipit-source-id: d43096238bd38d189fbec54fc2d93f17010d9ddb
2019-05-22 05:41:22 -07:00
nossbigg 168a67e4b2 Return endCoordinates for keyboardDidHide keyboard event (#24947)
Summary:
This pull request enhances the Keyboard API event emitter for Android upon `keyboardDidHide` by returning a `KeyboardEvent` with a meaningful `endCoordinates` property (instead of emitting a null as of current implementation). This change standardizes the `keyboardDidHide` keyboard event emission across both iOS and Android, which makes it easier for developers to use the API.

In particular, the semantics of `endCoordinates` emitted during the `keyboardDidHide` event on Android will match nicely with semantics of the same event emitted on iOS:
- `screenY` will be height of the screen, as that the keyboard has collapsed to the bottom of the screen
- `screenX` will be 0, as the keyboard will always be flush to the sides of the screen
- `height` will be 0, as the keyboard has fully collapsed
- `width` will be the width of the screen, as the keyboard will always extend to the width of the screen

Also, the flowtypes for `KeyboardEvent` have been further improved and are more explicit to better highlight the different object shapes (see `IOSKeyboardEvent` and `AndroidKeyboardEvent`) depending on the platform.

## Changelog

[Android] [Added] - Return endCoordinates for keyboardDidHide keyboard event
Pull Request resolved: https://github.com/facebook/react-native/pull/24947

Differential Revision: D15413441

Pulled By: cpojer

fbshipit-source-id: aa3998542b7068e9852467038f57310355018379
2019-05-21 03:46:50 -07:00
David Vacca 1b4678105b Ensures constraintSurfaceLayout is executed before 'JS run application' starts
Summary:
This diff ensures the method scheduler.constraintSurfaceLayout is executed before the JS run application start.
This is necessary to properly set the pointScaleFactor for the Root before running JS.

This is a workaround to fix a bug when the pointScaleFactor changes over time for the rootShadowNode. The bug is easily reproducible when rendering the "fabric" indicator on Fabric screens. During the first render of a Fabric screen this method was called before "JS run application" starts, and the Fabric indicator was render correctly.
Beacuse of timing of measure APIS, the second time a Fabric screen is rendered the method is called after the "JS run application process started", as a consecuence the Fabric indicator is not rendered correctlly (the pointScaleFactor is incorrectly assigned into the layout metrics of the Fabric indicator text).

We still need to analyze why the pointScaleFactor is not correctly assigned when it is set after the "JS run application process started", but this will be part of another diff.

Reviewed By: shergin

Differential Revision: D15303554

fbshipit-source-id: 7d985cefee20fd40dbe04166c1a1358b3f3ddc85
2019-05-10 16:32:01 -07:00
Luna Wei 135ba492fb Detach dependency on RRV for Instance Manager
Summary: Remove dependency on ReactRootView in ReactInstanceManager by creating a rough interface (ReactRoot) so that either a Surface or ReactRootView can be attached to ReactInstanceManager.

Reviewed By: ejanzer, mdvacca

Differential Revision: D14158890

fbshipit-source-id: b7ab4654b1e0ef8343230a3c15023653a7f23a4b
2019-04-10 13:13:16 -07:00
Luna Wei bc06d1cc9c Use a surface switch
Summary: Flesh out how surface will be used with a flag in ReactRootView

Reviewed By: mdvacca

Differential Revision: D14112897

fbshipit-source-id: adf6078048dbf83452d3523f0530a4d6dca7b3e8
2019-02-28 17:30:13 -08:00
David Vacca 2e42cc7652 optimize calls to updateRootLayoutSpecs
Summary: This diff changes the onMeasure method of the RootView to optimize the amount of times we call updateRootLayoutSpecs in Fabric

Reviewed By: shergin

Differential Revision: D14198155

fbshipit-source-id: ff2deee04540899c25d4e38b0bd93333f74c6ace
2019-02-24 11:58:47 -08:00
Luna Wei e758435167 Refactor the way UIManagerModule uses measure specs
Summary:
Instead of using measure specs to set certain yoga properties on the root node (like max width, auto width, specific width), use yoga's calculateLayout(width, height) instead. The measure specs will be stored in the shadow node. This allows us to remove duplicated code that processes the measure specs and allows us to remove other logic like the enableLayoutCalculation() method.

This diff also removes MeasureSpecProvider. MeasureSpecProvider was originally introduced to pass previously measured view measure specs to the initial creation of the root shadow node, but it turns out that this is unnecessary. We can update the root layout specs from the root view instead.

Reviewed By: mdvacca

Differential Revision: D9729744

fbshipit-source-id: 79b0b27ca879758f5dc3fc7cc8a0d38856a6cc79
2019-02-21 20:04:23 -08:00
Luna Wei c974b5e966 Remove SizeMonitoringFrameLayout
Summary: SizeMonitoringFrameLayout was used to set layout contraints on the root shadow node when the native view's size changes. Since then, we introduced ways for the root node to use proper layout contraints using the root view's measure specs, which provides more accurate constraints for the root node, so SizeMonitoringFrameLayout is no longer needed. This ends up making a lot of UIManagerModule's method signatures cleaner

Reviewed By: mdvacca

Differential Revision: D9565720

fbshipit-source-id: c569cd15991a09987cc01e89612dc9193ad99b45
2019-02-12 18:23:09 -08:00
Dulmandakh 4d95e85f64 remove unnecessary Android version checks (#23277)
Summary:
React Native's minSdkVersion is 16, or we support Android versions 16 (Jelly Bean) and above. But in the code we have many checks if Android is Jelly Bean or newer, which are unnecessary. This PR removes unnecessary Android version checks, also uses Android version names instead of numbers.

[Android] [Changes] - remove unnecessary Android version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23277

Differential Revision: D13955909

Pulled By: cpojer

fbshipit-source-id: 6b1caa5ef4fe42273d3c69a6617fff140a697b5c
2019-02-05 03:08:16 -08:00
Listen 1fde677cfc Remove duplicated OnGlobalLayoutListener to improve performance (#22849)
Summary:
We are writing a native navigation library. When there are more than a dozen `ReactRootView` in the application, the application will be very stuck. It doesn't improve much, even if we remove the invisible ReactRootView from the View hierarchy temporarily.

After debugging, we found that we were not able to remove `OnGlobalLayoutListener` in `onDetachedFromWindow` because  this listener was added twice. One is in `onAttachedToWindow` and the other is in `attachToReactInstanceManager`.

We added the following code by inheriting ReactRootView.

```java
    Override
    protected void onAttachedToWindow() {
        try {
            Method method = ReactRootView.class.getDeclaredMethod("getCustomGlobalLayoutListener");
            method.setAccessible(true);
            // remove duplicated GlobalLayoutListener
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
                getViewTreeObserver().removeOnGlobalLayoutListener((ViewTreeObserver.OnGlobalLayoutListener) method.invoke(this));
            } else {
                getViewTreeObserver().removeGlobalOnLayoutListener((ViewTreeObserver.OnGlobalLayoutListener) method.invoke(this));
            }
        } catch (NoSuchMethodException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        } catch (InvocationTargetException e) {
            e.printStackTrace();
        }
        super.onAttachedToWindow();
    }
```

It turns out that there is no pressure even if  opening hundreds of pages that contain ReactRootView (remove ReactRootView from the View hierarchy temporarily in the invisible pages).

Changelog:
----------

[Android] [Fixed] - Remove duplicated `OnGlobalLayoutListener` to improve performance.
Pull Request resolved: https://github.com/facebook/react-native/pull/22849

Differential Revision: D13682818

Pulled By: hramos

fbshipit-source-id: 1f1bc8cd5fc4e01a1bc2f2a4784822b4eae92fdc
2019-01-15 20:45:07 -08:00
Spencer Ahrens 7b5277bb75 mostly working on Android + OTA
Summary:
It works great on iOS, and mostly works on Android, and is now OTA'able as part of the screen config! Haven't done template view yet. One remaining issue:

Layout is borked on Android. I'm guessing the issue has to do with the timing of setting the constraints in `updateRootLayoutSpecs` and calling `mBinding.startSurface` which actually builds the shadow tree. If I try to call `updateRootLayoutSpecs` earlier, it just crashes immediately. Here's the layout it spits out, which clearly has -440 for the x of 420006, which is the RCTText component, causing it to get cut off on the left of the screen:
```
updateLayoutMountItem for reactTag: 420006 x: -440, y: -13, width: 931, height: 78
updateLayoutMountItem for reactTag: 420010 x: 26, y: 79, width: 0, height: 1651
updateLayoutMountItem for reactTag: 420012 x: 0, y: 26, width: 0, height: 158
updateLayoutMountItem for reactTag: 420016 x: 0, y: 210, width: 454, height: 454
updateLayoutMountItem for reactTag: 420018 x: 454, y: 210, width: 455, height: 454
updateLayoutMountItem for reactTag: 420022 x: 0, y: 690, width: 454, height: 454
updateLayoutMountItem for reactTag: 420024 x: 454, y: 690, width: 455, height: 454
updateLayoutMountItem for reactTag: 420028 x: 0, y: 1171, width: 454, height: 454
updateLayoutMountItem for reactTag: 420030 x: 454, y: 1171, width: 455, height: 454
updateLayoutMountItem for reactTag: 420032 x: 0, y: 1651, width: 0, height: 0
```

Reviewed By: mdvacca

Differential Revision: D12813192

fbshipit-source-id: 450d646af4883ff25184141721351da67b091b7c
2018-11-05 15:43:55 -08:00
David Vacca 83c7303a19 Trivial cleanup in ReactRootView
Summary: Trivial clanup of imports in ReactRootView

Reviewed By: fkgozali

Differential Revision: D12899430

fbshipit-source-id: 83bb052bbeee9e02e91157305420a2dd799e60e2
2018-11-03 01:14:07 -07:00
Andrew Chen (Eng) 59aada873e Remove overflow hidden killswitch
Summary: There hasn't been any reports of overflow issues since the last issue was fixed in v183 (July 30th). Let's remove this flag

Reviewed By: yungsters

Differential Revision: D10020006

fbshipit-source-id: 593c7d2c2bef5f0bd60d5de1941cd58f7fd6ccc7
2018-09-25 11:52:19 -07:00
Héctor Ramos 1151c096da Update copyright headers to yearless format
Summary: This change drops the year from the copyright headers and the LICENSE file.

Reviewed By: yungsters

Differential Revision: D9727774

fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
2018-09-11 15:33:07 -07:00
David Vacca 8b5e3fc16b Update size of Root ShadowNode when RootView changes its size
Summary: This diff updates the size of RootShadowNode and re-render RN views when the Size of the Android React View changes

Reviewed By: achen1

Differential Revision: D9173758

fbshipit-source-id: 7cc6bbfb646025c3ec1773ab041eb9207623af71
2018-08-28 23:03:34 -07:00
Jiaqi Wu 9c71952f20 Fix overflow issue in root view
Summary:
Set clipChildren to false by default in ReactRootView.java so that Overflow: visible/hidden will work for the root view.

Moved sDefaultOverflowHidden from ReactViewGroup.java to ViewProps.java so that it can be used in both ReactViewGroup.java and ReactRootView.java.

Reviewed By: mdvacca

Differential Revision: D8727140

fbshipit-source-id: b593bed63e479cdbd22e4a025b936e6aeb28fc8c
2018-07-19 17:46:53 -07:00
Andrew Chen (Eng) de09fd53bd Remove setJSEntryPoint from ReactRootView
Summary:
Doesn't look like it was ever used according to diffgrep https://our.intern.facebook.com/intern/diffgrep/?author=&expand_all=false&filepath=&matcher=strmatch&query=setJSEntryPoint&repo=fbsource&rev_type=all&result_size=3&search_order=2&source&target=added%20or%20removed

axe is this okay?

Differential Revision: D8730783

fbshipit-source-id: 1e6b9e8fbd50c108a24b592793060a5344f1d0b1
2018-07-06 12:33:00 -07:00
David Vacca 6e359c4589 Initialize Event Emitter as part of UIManagerModule
Reviewed By: achen1

Differential Revision: D8216184

fbshipit-source-id: 3b188804e2dad2b112f566da49a939eb4338713d
2018-05-30 22:06:40 -07:00
David Vacca 54acf3a431 Deprecate UIManagerModule#getEventDispatcher and refactor usages
Reviewed By: shergin

Differential Revision: D7832079

fbshipit-source-id: 263a2f8ff96ab6e14b91395644710b4d5f36dc50
2018-05-30 22:06:40 -07:00