forked from microsoft/react-native-macos
-
Notifications
You must be signed in to change notification settings - Fork 0
Fix Android Build Issues for RN64 Upgrade for patches through 2020-06-30 #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
amgleitman
merged 1 commit into
amgleitman:amgleitman/0.64-merge-2020-06-30
from
msgharpu:android_fix_2408
Aug 24, 2021
Merged
Fix Android Build Issues for RN64 Upgrade for patches through 2020-06-30 #3
amgleitman
merged 1 commit into
amgleitman:amgleitman/0.64-merge-2020-06-30
from
msgharpu:android_fix_2408
Aug 24, 2021
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
amgleitman
pushed a commit
that referenced
this pull request
Sep 21, 2021
Summary:
This diff allows specifying the preemptive compilation threshold via CompileFlags.
Users get a toggle in CLI and RuntimeConfig that allows choosing between 1. fully eager, 2. fully lazy, 3. use default thresholds ("smart"). The default is #3.
However, since we use `-O` by default, it overrides any lazy compilation when
using the `hermes` binary.
ChangeLog: [Internal] Inspector updated to use new RuntimeConfig laziness control
Reviewed By: tmikov
Differential Revision: D23356463
fbshipit-source-id: 508b7b2e6a218346c69acfec97e7891e388f0e9b
amgleitman
pushed a commit
that referenced
this pull request
Nov 10, 2021
Summary: This fix is still a little hypothetical. We have a few different JS errors that we're seeing with bridgeless mode that seem to be caused by Fabric trying to access `__fbBatchedBridge` from C++. I think what's happening is: 1. User encounters an unrelated JS error very early in rendering a new surface (possibly while the bundle is still loading?) 2. In release builds, BridgelessReactFragment handles the error by stopping the surface and rendering a retry button (actually, the surface is stopped in a bunch of places in BaseFbReactFragment, which might be why this is popping up now - I recently refactored that class to share more of its logic in bridgeless mode) 3. Fabric stops the surface by first checking to see if the custom binding `RN$stopSurface` exists; if not, it falls back to calling the registered callable module `ReactFabric`. I think #3 is where things are going wrong for bridgeless mode; if you call stopSurface before `RN$stopSurface` is installed (which happens when ReactFabric shim is required) then you'll fall back to the bridge version. My solution here is to instead rely on a flag set in C++ to determine whether we're in bridgeless mode, and then check to see if the stopSurface binding has been installed. If not, we just noop - if the ReactFabric shim hasn't been required, we probably don't actually have a React surface that needs to be stopped. At least, that's my current theory. We'll see if this actually works. Changelog: [Fixed][iOS] Fix an issue calling stopSurface in bridgeless mode before surface is started Reviewed By: mdvacca Differential Revision: D25453696 fbshipit-source-id: bff76675c43989101d0ba5ae0aba60089db230bf
amgleitman
pushed a commit
that referenced
this pull request
Nov 15, 2021
Fix `yarn lint` in fb66merge branch
amgleitman
pushed a commit
that referenced
this pull request
May 6, 2022
Summary: Previous iterations of this diff that were reverted: D30678341 (facebook@8009459), D30868627 (facebook@abd0f38). With the power of selects, we can move the base AppleTVOS flags into the regular base Apple flags. While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as it's driving me insane. Note - This puts get_visibility_option() on all Apple builds. I believe this is the right thing to do as everything except macOS static libraries already do it, and it shouldn't affect binaries. Changelog: [Internal] Reviewed By: mzlee, jdonald Differential Revision: D31024459 fbshipit-source-id: be85296cda3612836c1c74632dc52f6e3f89512e
amgleitman
pushed a commit
that referenced
this pull request
May 6, 2022
…ake #3) Differential Revision: D31024459 (facebook@0a46e5e) Original commit changeset: be85296cda36 fbshipit-source-id: ceb8e5a3cda57a40a876b07133d8021942308878
amgleitman
pushed a commit
that referenced
this pull request
Jun 13, 2022
Summary: This diff adds `overflowInset` values in RN Android. These values are used to give an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR: {F687030994} In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`. This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (facebook@e35a963), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode. This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)" To fix this issue, I added the support to `overflowInset` to RN Android by 1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction 2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java` 3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages 4. Adding implementation of getter and setter for `overflowInset` in various views 5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code. Changelog: [Internal][Android] Reviewed By: JoshuaGross Differential Revision: D33133977 fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary
Fix the Android Build Issue in latest merge for RN64 upgrade