Summary:
Convert Bridge-only checks to overridable functions and make Bridgeless override them in ReactSurfaceView so that the checks will work for Bridgeless as well.
Issue fixed:
https://fb.workplace.com/groups/rn.support/permalink/24231137939841493/
Changelog:
[Android][Changed] - Convert Bridge-only calls to overridable functions
Reviewed By: javache
Differential Revision: D43063348
fbshipit-source-id: a1c181d27c1669f6033f3fb783c5a668b7c2585b
Summary:
Changelog:
[internal] - DescriptionSome tooling breaks when the JavascriptException is obfuscated. This change prevents the exception from getting obfuscated, allowing tools to detect them without symbolicating.
Differential Revision: D43091424
fbshipit-source-id: aae4768397bd78433a1d496ecac4a1442422d912
Summary:
Changelog: [internal]
Pass RuntimeScheduler to Binding in Venice.
This is needed for two reasons:
- support "callImmediates". This is a workaround to bridge the gap in scheduling until microtasks in RN are shipped.
- To block paint in case there is a state update in useLayoutEffect. Used later in this diff stack
Reviewed By: sshic
Differential Revision: D43088186
fbshipit-source-id: 8537234db5f72cbf057ad1861ca2c37a5c3dbd8b
Summary:
the current jsc-android is still built based on ndk r21, and react-native is now built based on ndk r23. the unwinder between r21 and r23 is incompatible (libgcc vs libunwind). if there's exceptions throwing from jsc, other react native libraries cannot catch these exceptions and cause runtime crash.
this pr updates jsc-android to 235231.0.0 which is the same webkitgtk version as 235230.2.1 but only built by ndk r23. the jsc-android pr is from https://github.com/react-native-community/jsc-android-buildscripts/pull/179. note that the jsc is based on ndk r23c and react-native is based on ndk r23b. the reason is that i cannot get jsc building successfully on r23b. hopefully r23b and r23c are abi safe.
there is another crash from libjscexecutor when testing the new jsc-android. to fix the issue, i have to explicitly link libunwind.a from libjscexecutor.so. supposedly ndk r23 should help to link libunwind under the hood, i still not figure out why it doesn't. but after linking libunwind.a, i can get new jsc-android work successfully.
```
E/art ( 2669): dlopen("/data/app/com.test-1/lib/x86_64/libjscexecutor.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_Unwind_Resume" referenced by "/data/app/com.test-1/lib/x86_64/libjscexecutor.so"...
W/System.err( 2669): at java.lang.Runtime.load(Runtime.java:331)
W/System.err( 2669): at java.lang.System.load(System.java:982)
W/System.err( 2669): at com.facebook.soloader.SoLoader$1.load(SoLoader.java:558)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibraryFrom(DirectorySoSource.java:110)
W/System.err( 2669): at com.facebook.soloader.DirectorySoSource.loadLibrary(DirectorySoSource.java:63)
W/System.err( 2669): at com.facebook.soloader.ApplicationSoSource.loadLibrary(ApplicationSoSource.java:91)
W/System.err( 2669): at com.facebook.soloader.SoLoader.doLoadLibraryBySoName(SoLoader.java:1067)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoNameImpl(SoLoader.java:943)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibraryBySoName(SoLoader.java:855)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:802)
W/System.err( 2669): at com.facebook.soloader.SoLoader.loadLibrary(SoLoader.java:772)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.loadLibrary(JSCExecutor.java:24)
W/System.err( 2669): at com.facebook.react.jscexecutor.JSCExecutor.<clinit>(JSCExecutor.java:20)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.getDefaultJSExecutorFactory(ReactInstanceManagerBuilder.java:363)
W/System.err( 2669): at com.facebook.react.ReactInstanceManagerBuilder.build(ReactInstanceManagerBuilder.java:316)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.createReactInstanceManager(ReactNativeHost.java:94)
W/System.err( 2669): at com.facebook.react.ReactNativeHost.getReactInstanceManager(ReactNativeHost.java:41)
W/System.err( 2669): at com.test.MainApplication.onCreate(MainApplication.java:60)
W/System.err( 2669): at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1011)
W/System.err( 2669): at androidx.test.runner.MonitoringInstrumentation.callApplicationOnCreate(MonitoringInstrumentation.java:483)
W/System.err( 2669): at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4518)
W/System.err( 2669): at android.app.ActivityThread.access$1500(ActivityThread.java:144)
W/System.err( 2669): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1339)
W/System.err( 2669): at android.os.Handler.dispatchMessage(Handler.java:102)
W/System.err( 2669): at android.os.Looper.loop(Looper.java:135)
W/System.err( 2669): at android.app.ActivityThread.main(ActivityThread.java:5221)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Native Method)
W/System.err( 2669): at java.lang.reflect.Method.invoke(Method.java:372)
W/System.err( 2669): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:899)
W/System.err( 2669): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:694)
```
fixes https://github.com/facebook/react-native/issues/36052
## Changelog
[ANDROID][FIXED] - Fixed jscexecutor crash on Android which is caused from NDK incompatibility
Pull Request resolved: https://github.com/facebook/react-native/pull/36062
Test Plan: tested on [jsc-android instrumented test](https://github.com/react-native-community/jsc-android-buildscripts/tree/2.26.1/test) (based on react-native 0.71.2)
Reviewed By: cipolleschi
Differential Revision: D43040295
Pulled By: cortinico
fbshipit-source-id: e0e5b8fb7faa8ee5654d4cde5f274bef4b517376
Summary:
This was shipped in D36990986 (df80ed40c7) but backed out last year in D37074879 (59476d06f3), as we want to wait for some performance comparison results to come out.
Remove overflow inset optimization flags as they've been rolled out 100% to public.
Changelog:
[Android][Internal] - Clean up feature flags for overflowInset
Reviewed By: javache
Differential Revision: D43070494
fbshipit-source-id: dbf5aed9b2b5d3db1ad351bc208cb2016dc62e40
Summary:
Both Android and iOS allow you to set application specific user interface style, which is useful for applications that support both light and dark mode.
With the newly added `Appearance.setColorScheme`, you can natively manage the application's user interface style rather than keeping that preference in JavaScript. The benefit is that native dialogs like alert, keyboard, action sheets and more will also be affected by this change.
Implemented using Android X [AppCompatDelegate.setDefaultNightMode](https://developer.android.com/reference/androidx/appcompat/app/AppCompatDelegate#setDefaultNightMode(int)) and iOS 13+ [overrideUserInterfaceStyle](https://developer.apple.com/documentation/uikit/uiview/3238086-overrideuserinterfacestyle?language=objc)
## Changelog
[GENERAL] [ADDED] - Added `setColorScheme` to `Appearance` module
Pull Request resolved: https://github.com/facebook/react-native/pull/35989
Test Plan:
This is a void function so testing is rather limited.
```tsx
// Lets assume a given device is set to **dark** mode.
Appearance.getColorScheme(); // `dark`
// Set the app's user interface to `light`
Appearance.setColorScheme('light');
Appearance.getColorScheme(); // `light`
// Set the app's user interface to `unspecified`
Appearance.setColorScheme(null);
Appearance.getColorScheme() // `dark`
```
Reviewed By: NickGerleman
Differential Revision: D42801094
Pulled By: jacdebug
fbshipit-source-id: ede810fe9ee98f313fd3fbbb16b60c84ef8c7204
Summary:
This is a two step (2/2) fix to a race that could caused a DELETE...CREATE mutations being sent over to the fabric mounting layer. Such combination was assumed not possible from the differ (https://fburl.com/code/kg8z9t4w), yet it happened at least in the existence of layout animation and when certain commits happen while animation is active.
This diff fixes all potential races in the Fabric mounting layer directly. It captures all the `DELETE...CREATE` combinations and stop those from passing down to the native platforms. This should fix all such races should them not captured by the fix in the layout animation.
To help understand other races better, I also logged here to indicate such race so that future crashes will have more context.
Changelog:
[General][Fixed] - Fix edge case when layout animation caused delete and create mutations in the same batch
Reviewed By: javache
Differential Revision: D41900201
fbshipit-source-id: 280502ca32ce87a9e483cd859b11bcd3e5c4a435
Summary:
This is a prototype to add circular dependencies detection on CMake for ReactCommon and ReactAndroid.
It can be enabled per module and works as follows:
```
set(ALLOWED_HEADER_IMPORT_PATHS
react/renderer/graphics
react/debug)
check_for_circular_dependencies("${ALLOWED_HEADER_IMPORT_PATHS}")
```
The allowed header import path must be manually specified as libraries are exposing wrong header search paths (so can't be reused).
The CI will be red till the circular dependency on `graphics` is resolved.
Changelog:
[Internal] [Changed] - Add macro to detect circular dependencies on Cmake
Reviewed By: cipolleschi
Differential Revision: D42927036
fbshipit-source-id: b1393dfd43fd042e2ebf1d5b46b24bd9f5e20d58
Summary:
- Bridgeless is using a deprecated FabricUIManager constructor which bridge doesn't use, and is the only one using it, this diff migrated bridgeless to use the same FabricUIManager constructor as bridge
- Remove static view config check (mShouldDeallocateEventDispatcher), instead use Bridgeless check since SVC is enabled in Bridgeless but not in Bridge.
Changelog:
[Android][Changed] - Align creation of FabricUIManager with bridge
Reviewed By: javache
Differential Revision: D42681489
fbshipit-source-id: b9c7c4a81a98db52e881138cc85be0e85df636d9
Summary:
Changelog: [Internal] Support hovering in/out of root views
Prior to this change, we did not have signal when an input device moved out of the root view and so our internal state would not be aware and we would not trigger enter/leave events.
This diff starts listening to `HOVER_EXIT` events as dispatched from `onInterceptHoverEvent` and assumes that's the right event to signal a cursor has moved out of the root view. We dispatch the relevant leave events for this case and update our internal state to ensure the next `HOVER_MOVE` in our rootview, will properly dispatch the enter events.
## Investigation for creating this diff
Determining the signal for when an inputDevice enters/exits our rootview wasn't straight-forward.
From my understanding Android event dispatching follows a similar capture, bubbling phase as web. With `onIntercept..` handlers to swallow events. See this explanation: https://suragch.medium.com/how-touch-events-are-delivered-in-android-eee3b607b038 and this video talk: https://youtu.be/EZAoJU-nUyI?t=929
However when trying to understand hover enter/exit events on the root view, my understanding of this logic broke down.
Here's what confused me:
* When moving a cursor from inside to outside the root view, I would receive `HOVER_ENTER/EXIT` MotionEvents on `onInterceptHoverEvent` and since we did not swallow them, we'd receive those same events on the bubble up in `onHover`. That makes sense.
* However, when I hovered from the rootview into a child view, I would receive MotionEvents of `HOVER_ENTER/HOVER_EXIT` in the `onHoverEvent` handler of the rootview without having seen them in the `onInterceptHoverEvent` (re: capture phase down). This was confusing, where was the capture down?
* What tips me off that these events (`HOVER_ENTER/EXIT`) don't follow the classic capture, bubbling model as explained in the linked article, is that I don't receive `HOVER_ENTER/HOVER_EXIT` events for each child view in the root view's `onInterceptHoverEvent`.
* Like when a cursor moves from root -> child, I'd expect to motion events 1. exit for the rootview, 2. enter for the child view. But I never receive the 2. from the root view --
* I also wonder if the wording for `HOVER_EXIT` events mean that these events are directly dispatched to the view? Re: ["This action is always delivered to the window or view that was previously under the pointer."](https://developer.android.com/reference/android/view/MotionEvent#ACTION_HOVER_ENTER)
* There also seems to be some optimizations around the dispatch path as mentioned in this video at this timestamp: https://youtu.be/EZAoJU-nUyI?t=929 for the UP gesture.. so maybe there's some optimization happening with hover events? I'm not sure how hover events are account for in gesture handling for Android.
Reviewed By: vincentriemer
Differential Revision: D42817315
fbshipit-source-id: 412c971c1d1e7afc0d67fadcc4417189967fe48c
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. When a ScrollView's content is laid out, onLayoutChange is triggered. This is also fired when the views are hidden, which is not desirable as the layout may not be accurate when the view is hidden. Check that the scroll view is showing before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayoutChange, only scroll if the view is shown and the content view is ready
Reviewed By: sshic
Differential Revision: D42808119
fbshipit-source-id: 0197ae55fa7d80e52c2ea483609e62d512a117f3
Summary:
ScrollViews don't properly maintain position where they are hidden and shown. There is an edge case where on onLayout for a ScrollView, its content may not have been laid out yet. This happens in some cases when a scroll view is hidden via display: 'none' (resulting in setVisibility(INVISIBLE)). Check that the content view is laid out before attempting a scroll.
Changelog:
[Internal][Fixed] - In onLayout, only scroll if the content view is ready
Reviewed By: sshic
Differential Revision: D42794750
fbshipit-source-id: 654a380bcae306da2704d3e190423c8de125833d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35953
DimensionValue is a reserved prop type that can be a number or string (such as '50%'). On Java, it will get converted to a YogaValue (converter added to this diff); on C++ it will get converted to a YGValue (converter already exists as it's used in Fabric).
Changelog:
[Internal][Added] - Add codegen support for DimensionValue for components
Reviewed By: cipolleschi
Differential Revision: D42650799
fbshipit-source-id: 1d2bc30bbd93837dedbbb4c74f814963c8140957
Summary:
We still see crashes for T112157805 and this diff is to add missing information to help diagnose the issue better.
We added a line of log to indicate which `mountItem` triggered the exception.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D42556576
fbshipit-source-id: 4283c34cb18d601ca7b80d3524c9c65cc4ae3f8a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35967
In https://github.com/facebook/react-native/issues/35936 we observed that the presence of AbsoluteSizeSpan may lead to hangs when using the Grammarly keyboard on Samsung.
This mitigation makes it so that we do not emit this span in any case where it is sufficient to rely on already set EditText textSize. In simple cases, tested on two devices, it causes typing into the TextInput to no longer hang.
This does not fully resolve the issue for TextInputs which meaningfully use layout-effecting spans (or at least font size), such as non-uniform text size within the input. We instead just try to reduce to minimum AbsoluteSizeSpan possible.
Testing the first commit was able to resolve hangs in some simpler inputs tested, by me and cortinico.
Changelog:
[Android][Fixed] - Mitigation for Samsung TextInput Hangs
Reviewed By: cortinico
Differential Revision: D42721684
fbshipit-source-id: e0388dfb4617f0217bc1d0b71752c733e10261dd
Summary:
While buildling locally, those two warnings pop up.
- ANDROID_LD being unused by the CMake toolchain. I'm removing it.
- The Download task encountering a weak eTag. I'm updating it:
https://github.com/michel-kraemer/gradle-download-task
Changelog:
[Internal] [Changed] - Fix a couple of warnings in the ReactAndroid:hermes-engine build
Reviewed By: dmytrorykun
Differential Revision: D42738919
fbshipit-source-id: 7bd8785ad5b7431d557e2f8c8876b7c3f7294a43
Summary:
This adds support for `maintainVisibleContentPosition` on Android. The implementation is heavily inspired from iOS, it works by finding the first visible view and its frame before views are update, then adjusting the scroll position once the views are updated.
Most of the logic is abstracted away in MaintainVisibleScrollPositionHelper to be used in both vertical and horizontal scrollview implementations.
Note that this only works for the old architecture, I have a follow up ready to add fabric support.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Added] - Add maintainVisibleContentPosition support on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/35049
Test Plan:
Test in RN tester example on Android
https://user-images.githubusercontent.com/2677334/197319855-d81ced33-a80b-495f-a688-4106fc699f3c.mov
Reviewed By: ryancat
Differential Revision: D40642469
Pulled By: skinsshark
fbshipit-source-id: d60f3e2d0613d21af5f150ca0d099beeac6feb91
Summary: Changelog: [Internal] Infer whether a pointer supports hover or not by presence of events
Reviewed By: vincentriemer, NickGerleman
Differential Revision: D42589958
fbshipit-source-id: aa42affc98ef78ebbf9a6e420684ed098869b905
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35897
Fixes https://github.com/facebook/react-native/issues/35894
Android 11 added native support for querying whether the IME is present along with its size, as part of the WindowInsets API. D38500859 (1e48274223) changed our logic for Android keyboard events to use it when available, fixing a longstanding issues where we could not reliably tell where the keyboard was open depending on softInputMode.
An androidx library WindowInsetsCompat aimed to backport some of the functionality to older versions of Android, with the same API, documenting IME queries to work down to API level 23 (Android 6). I used this, so that we would be able to remove our own logic for detecting keyboard insets once we supported 23+.
From an issue report, WindowInsetsCompat is not accurately returning whether the IME is open on at least Android 9. So this change makes it so we only use WindowInsets methods when they are provided by the OS (a tested golden path), and otherwise use the previously working heuristics on anything older.
Changelog:
[Android][Fixed] - Do not use WindowInsetsCompat for Keyboard Events
Reviewed By: christophpurrer
Differential Revision: D42604176
fbshipit-source-id: da6a0bbc34c36f8e6d4e4ac07bc96da048fd6aa8
Summary:
This removes some unused flags which will cause Yoga to layout every tree twice, then diffing the tree, reporting whether the whole tree is different. This is too expensive to run outside of local experimentation, but we have more nuanced ways to implement the `YGNodeLayoutAffectedByQuirk` I am wanting to add.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D42406917
fbshipit-source-id: b415ed02768f6b59de3a6fa90c60c750d56fd4b0
Summary:
react-native-navigation allows to register React components to be included in the navigation top bar as buttons, the way this work is by using the AppRegistry. When the ViewTreeObserver executes the `CustomGlobalLayout` we are checking for the RootWindowInsets in the `checkKeyboardEvents` which in the case for the top bar component it returns null and the **WindowInsetsCompat.toWindowInsetsCompat** function throws if the insets are null causing the app to crash.
Interestingly in the function `checkForKeyboardEventsLegacy` the null value is being checked, so I guess it was overlooked in the newer function.
## Changelog
[ANDROID] [FIXED] - Fix ReactRootView crash when root view window insets are null
Pull Request resolved: https://github.com/facebook/react-native/pull/35869
Test Plan:
The following videos show how the app crashes as soon as we attempt to pop a screen that contains a react component as a button in the navigation top bar and how it correctly pops to the previous screen after applying the fix
| Crash | Fix |
| -- | -- |
| https://user-images.githubusercontent.com/6757047/213116971-fe693989-f978-438c-b8f9-fc56f2a477c8.mp4 | https://user-images.githubusercontent.com/6757047/213118352-fe258f28-07aa-4d17-98d2-97136464ffd5.mp4 |
Reviewed By: cipolleschi
Differential Revision: D42580156
Pulled By: cortinico
fbshipit-source-id: 4dbd656d7c8148df67668a2a50913206bc35c07f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35857
It seems like there is an incompatibility between NDK 23 (shipped in 0.71)
and the usage of custom `CMAKE_BUILD_TYPE` we do for Hermes.
Specifically the `-DCMAKE_BUILD_TYPE=Release` we specify for the debug
variant of Hermes is partially ignored by the new Android native build toolchain.
See https://github.com/android/ndk/issues/463 for mentions on how the
toolchains requires CMake 3.20+
As AGP 7.3 defaults to use CMake 3.18 unless specified, and NDK 23 unless specified.
AGP 7.4 defaults to use CMake 3.22 unless specified, and NDK 23 unless specified.
See: https://developer.android.com/studio/releases/gradle-plugin#7-4-0
Here I'm:
1. Bumping the docker image to an image that contains the CMake 3.22
2. Updating the logic for building `react-native` & `hermes-engine` to use 3.22
3. Provide fallbacks if the user specified `CMAKE_VERSION`
Template tests will run on AGP 7.3 and will still use CMake 3.18, but I forecast
no problem there as the user is not supposed to specify custom `CMAKE_BUILD_TYPE`.
This is only a problem as we build `hermes-engine` with custom build types.
Changelog:
[Android] [Fixed] - Bump CMake to 3.22.1 to properly honor CMAKE_BUILD_TYPE
Reviewed By: cipolleschi
Differential Revision: D42544864
fbshipit-source-id: efd0f51120370fb808337c201df31d71f4ddfdbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35851
Yoga moved away from fbjni, to use vanilla JNI. This removes fbjni, and proguard annotations (see last stack) as Yoga dependencies from the OSS RN Buck build.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D42538671
fbshipit-source-id: c940d370d9d34bdb905c5dc9331e0bd57b5d49db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35841
X-link: https://github.com/facebook/litho/pull/928
X-link: https://github.com/facebook/yoga/pull/1216
The Yoga JNI bindings use Reflection, so we need to let ProGuard know not to strip certain annotated fields.
This is done internally using a single copy of `com.facebook.proguard.annotations` from fbandroid (sometimes), which is then repackaged externally, and published as its own whole Yoga specific package. We never actually inform the stock Gradle project of the rules for the annotations though, so apps must add these manually.
This simplifies the setup, where Yoga has its own self-contained annotations/rules. The rules are exposed for Gradle/Buck dependencies, but RN and Litho both consume Yoga via dirsync + custom Gradle logic, so we need to duplicate the proguard rules to them instead of them being propagated automatically.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D42406641
fbshipit-source-id: c2b12fd498f93f144e5651917ca878d2a5050e08
Summary:
Fixes https://github.com/facebook/yoga/issues/850https://github.com/facebook/yoga/issues/850 describes a conformance issue where positioning of an absolute child using percentages is not calculated against the correct box size.
This takes the fix for that in https://github.com/facebook/yoga/pull/1028, regenerates tests, and fixes tests so that the experimental feature can be enabled. Goal is to run this as an experiment internally to see if we can enable by default.
Changelog:
[Internal]
X-link: https://github.com/facebook/yoga/pull/1201
Reviewed By: yungsters
Differential Revision: D42282358
Pulled By: NickGerleman
fbshipit-source-id: 57c0dd9b0f1c47cb9335ff6e13d44b4646e5fa58
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35789
Changelog: [Internal]
This diff is reverting D41069547 (fee9510b2d) D41062668 (4c40014d43) D40984397 (05968d16e1)
D40984397 (05968d16e1) has been identified to be causing the following test or build failures:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
allow-large-files
Differential Revision: D42371475
fbshipit-source-id: daa01c9215811c397f5cef958fd4620f36295b60
Summary:
This PR implements logical border-radius as requested on https://github.com/facebook/react-native/issues/34425. This implementation includes the addition of the following style properties
- `borderEndEndRadius`, equivalent to `borderBottomEndRadius`.
- `borderEndStartRadius`, equivalent to `borderBottomStartRadius`.
- `borderStartEndRadius`, equivalent to `borderTopEndRadius`.
- `borderStartStartRadius`, equivalent to `borderTopStartRadius`.
## Changelog
[GENERAL] [ADDED] - Add logical border-radius implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/35572
Test Plan:
1. Open the RNTester app and navigate to the `RTLExample` page
2. Test the new style properties through the `Logical Border Radii Start/End` section
https://user-images.githubusercontent.com/11707729/206623732-6d542347-93f9-40da-be97-f7dcd5f66ca9.mov
Reviewed By: necolas
Differential Revision: D42002043
Pulled By: NickGerleman
fbshipit-source-id: a0aa9783c280398b437aeb7a00c6eb3f767657a5
Summary:
With the current implementation, it's possible to get a reference to the list of view managers while it's being populated, which in some cases results in `ConcurrentModificationException` thrown [here](9c57a7f209/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIManagerModuleConstantsHelper.java (L80)). This PR updates the logic, so the reference to the list is updated (and returned) only when it's ready.
## Changelog
[ANDROID] [FIXED] - Fix possible `ConcurrentModificationException` in `UIManagerModuleConstantsHelper::createConstants`
Pull Request resolved: https://github.com/facebook/react-native/pull/35770
Reviewed By: cortinico
Differential Revision: D42342107
Pulled By: rshest
fbshipit-source-id: 8d799535c811edeefa1903fbf7a46bff22691e59
Summary:
This diff fixes accessibility value setter in BaseViewManager.java when the accessibility value is null. This is needed when we reset the value and would like to make sure the content description reflects the expected state, instead of the stale state when the value is set last time.
Changelog:
[Android][Fixed] - Reset accessibility value when it gets a null value
Reviewed By: NickGerleman
Differential Revision: D42160904
fbshipit-source-id: a8115a268461c8340d38350ab6fd3f21e4b14959
Summary:
- there was a bug when `contentOffset` was set to {x:0, y:0} and there were items lazy loaded in with prop changes- the View would consistently scroll back to the top after loading in new items
- to avoid this, we store the offset value when it's first set, and only run the `scrollTo` logic then
Changelog:
[Internal][Fixed] - Fix contentOffset forcing scroll to top behavior
Reviewed By: fkgozali, mdvacca
Differential Revision: D42089871
fbshipit-source-id: 3968d98341728a45bec28e8783c9977e91dd4d2c
Summary:
Fixes incorrect logging that I found whilst debugging
## Changelog
[Android] [FIXED] - Fixed incorrect logging of `isCatalystInstanceAlive` in exception handler
Pull Request resolved: https://github.com/facebook/react-native/pull/35708
Test Plan: N/A as change is related to logging
Reviewed By: christophpurrer
Differential Revision: D42233178
Pulled By: robhogan
fbshipit-source-id: f48e5abc036393a40f836cf0bf8c1d69f03ca848
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35743
Changelog:
[Android][Added] - For supporting Dev Loading View across multiple platforms, altering the javascript implementation of Loading view of android to also rely on native implementation as iOS instead of Toast, thereby unifying both platforms
Reviewed By: rshest
Differential Revision: D42258041
fbshipit-source-id: 1be56c1e5696b1024ba09a0aa11da96e0a08f210
Summary:
[Changelog][Internal]
Both iOS and Android platforms are at this point using the same native implementation of `performanceNow`, based on `std::chrono` (it used to be different some time ago).
This diff unifies the implementations, so it comes from one place in C++ code for all platforms.
The context is that I am developing event timing instrumentation and need a consistent way to get current timestamp from either JS or native (C++) side. The latter is now possible via calling `JSExecutor::performanceNow()`, which is guaranteed to be the same as called from JS.
Reviewed By: christophpurrer
Differential Revision: D42267898
fbshipit-source-id: dcb592f37d6567340ea59faddbf3b6d2b8507d50
Summary:
changelog: [internal]
This is experimental implementation of `setNativeProps` in Fabric.
This diff brings `setNativeProps` to Fabric to make migration easier. I tried to stay as close as possible to Paper's behaviour, with all of its flaws (ready CAUTION section on https://reactnative.dev/docs/direct-manipulation)
State can't be stored in views because on iOS, eventually on Android, views are not the source of truth, shadow tree is. Fabric's implementation keeps state from setNativeProps in shadow node family in very inefficient data structure folly::dynamic. It is always reconciled with new prop updates. The performance cost is only paid in case node has used `setNativeProps` before.
Reviewed By: mdvacca
Differential Revision: D41875413
fbshipit-source-id: 453a5f7612a6f86a4cece269b13bd2ffd0c0e2d1
Summary:
- Use ThemedReactContext explicitly to reduce confusion, "addLifecycleEventListener()" and "removeLifecycleEventListener" should be forced to call on ThemedReactContext
- Migrate "getNativeModule" and "handleException" calls from ThemedReactContext to ThemedReactContext.getReactApplicationContext
Changelog:
[Android][Changed] - Use ThemedReactContext explicitly to reduce confusion
Reviewed By: mdvacca
Differential Revision: D42101979
fbshipit-source-id: be34b7397ccf4f58477bab6cfa8c58eedd99e225
Summary:
This diff is moving all relevant cxx component classes out of react-native-github, this is necessary to make it easy to iterate on their APIs
We will move them back again to OSS once we make the API stable
changelog: [internal] internal
Reviewed By: arhelmus
Differential Revision: D42018363
fbshipit-source-id: bacf0c667e2e8df57b4b57e257bf937586b8e6f7
Summary:
This diff is fixing a NullPointerException occuring when using Placeholder in TextInput. In some particular scenarios Placeholder is being updated before the TextInput is even layed out.
In this diff I'm setting a defult LayoutParams to avoid NullPointerException to be thrown by android EditTextView. This change should not affect layout for TextInput components because layout will be overriden on the next Fabric commit.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D42078080
fbshipit-source-id: 294376e7f78d6ed58fc9f893553356553accba6c
Lulu Wu
Matthijs Mullender
Samuel Susla
Kudo Chien
Xin Chen
Birkir Gudjonsson
Fabrizio Cucci
Nicola Corti
Luna Wei
gabrieldonadel
Genki Kondo
Nick Gerleman
Janic Duplessis
Elias Nahum
Ruslan Lesiutin
Nick Gerleman
Joshua Selbo
Zhiyao Zhou
Jakub Piasecki
Sharon Zheng
jonathancaley
Arushi Kesarwani
Ruslan Shestopalyuk
David Vacca