Summary:
In this diff I'm shipping and deleting mapBufferSerialization for Text measurement
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348982
fbshipit-source-id: 7336cbe055a55d7d8d4f0a723049842bae1defb5
Summary:
This diff refactors the initialization of MapBuffer so
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D40348981
fbshipit-source-id: 88bbf4f2370373c20f805c3b23d0ecbe8a26bb86
Summary: Changelog: [Internal] Add more properties to PointerEvent, ensure all web platform tests are passing
Reviewed By: mdvacca
Differential Revision: D40314330
fbshipit-source-id: 071683f26f5a1e17d7ea49ac022c0ca23b6f9947
Summary:
Changelog: [Internal] - Add more state to PointerEventState per pointer such that `offset` coordinates and `hitPath` accurately reflect each pointer.
This change eagerly calculates the hitPath of every pointer under a MotionEvent.
Reviewed By: mdvacca
Differential Revision: D39736109
fbshipit-source-id: ef76dc19a86eaf9b26f35c6a55781ece6e43eecc
Summary:
As identified in https://github.com/facebook/react-native/issues/34350, modals do not honor the system's status bar colors because they may not be set by the deprecated `systemUiVisibility` flags. Unless `android:windowLightStatusBar` is set to true, the default flag is a zero-integer (a.k.a. "dark mode", where the icons show as white). Since the `StatusBar` component is using the new `setSystemBarsAppearance` API, the ModalHost should also infer its status bar settings from the same API.
## 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] [Fixed] - Fixed an issue on Android API 31+ where modals would turn status bar icons white by default
Pull Request resolved: https://github.com/facebook/react-native/pull/34899
Test Plan:
- On a screen with the `StatusBar` bar style set to `dark-content`, the modal also uses white icons
- On a screen with the `StatusBar` bar style set to `light-content`, the modal also uses black icons
### Preview
Here, I change the `barStyle` from `light-content` to `dark-content` and demonstrate that the proper attributes are retained. The "Before" is a recording from `main` and the "After" is this branch. Notice how in "Before", the status bar is always turning the icons white when the modal opens.
|Before|After|
|-|-|
|||
## Other considerations
There's some argument towards removing this check entirely--the status bar appearance should be derived from the theming and/or the parent activity's settings, thereby removing the need to apply separate styling
Reviewed By: lunaleaps
Differential Revision: D40243122
Pulled By: lunaleaps
fbshipit-source-id: ffa56c7d6a1906f89658f95a12f6bf1cefd5be8e
Summary:
Add a `DevSupportManager` that can be used for performance testing. This `DevSupportManager` allows the inspector connection to be established, but leaves everything else disabled.
Previously, if Developer Support was enabled on a release build, the application would present an error as it unsuccessfully attempted to use the bridge dev support manager.
With this change, if a developer opts into developer support in a release build (i.e. `enableOnCreate == true && ReactBuildConfig.DEBUG == false` in the `DevSupportManagerFactory`), the `PerfTestDevSupportManager` will be used, allowing use of things like heap size reporting and the sampling profiler.
(`enableOnCrease` indicates the development mode setting: https://www.internalfb.com/code/fbsource/[6b8a941fdf2a0fd58d9db36f5a59fa5fb53ad2df]/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/ReactInstanceManager.java?lines=259)
Changelog: [internal]
Reviewed By: rubennorte
Differential Revision: D39468561
fbshipit-source-id: cb3c82e7a8ee74316b23f57dc8d0cc6e5cdb18a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34927
The changes made in D36902220 (https://github.com/facebook/react-native/commit/a04195167bbd8f27c6141c0239a61a345cac5a88) and D36958882 (https://github.com/facebook/react-native/commit/d8c25ca1b62df2b93f70bbb1f7b379643ab9ccd4) attempted to reduce flickering and consistency issues when using Animated.
In the old renderer, we explicitly reset all animated props, and wait for the subsequent React commit to set the props to the right state, but if `initialProps` are used, the React reconciliation may not be able to identify the prop-update is required and will leave out the value. This behaviour is different in the new renderer, where we do not explicitly `restoreDefaultValues` on detaching the animated node, and instead rely on the latest state being correct(?).
Changelog:
[General][Fixed] Stop styles from being reset when detaching Animated.Values in old renderer
Fixes#34665
Reviewed By: rshest
Differential Revision: D40194072
fbshipit-source-id: 1b3fb1d1f4a39036a501a8a21e57002035dd5659
Summary:
Noticed that we were using a different tag for each pointer event observed (and that weren't clearing these properly when recyling views).
Each of these tags is a hashmap entry and a boxed boolean, so we can do much better by just using a single (boxed) integer.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D40077519
fbshipit-source-id: 130e78c3641eaedfa8787644b98763fd4367bc27
Summary:
Create documentation to write C++ ViewManagers in React AR apps
changelog: [internal] internal
Differential Revision: D40119174
fbshipit-source-id: edce0e6b226a30007c39f924b5896fa2267e98b7
Summary:
Automation tests were hitting issues with view recycling enabled because we use the main tag field to lookup views, and not properly resetting it when recycling.
Changelog: [Internal]
Reviewed By: jehartzog
Differential Revision: D40076594
fbshipit-source-id: 5f518b979a23562f7e7fc8271488678e78f50e91
Summary:
While working on https://github.com/facebook/react-native/pull/34513 I noticed that on main branch the versioning is not really consistent everywhere. So this PR is an attempt at realigning so that on the main branch, RN is 1000.0.0 everywhere - in a way, it's cleaning up the room for the monorepo work to go flawlessly).
It's just a pass of `node scripts/set-rn-version.js --to-version 1000.0.0`.
There's the small chance that some versions where kept to 0.0.0 on purpose (build tools are weird), so we might just have to close this off. No big deal :)
## 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
-->
[Internal] [Changed] - re-align version to be 1000.0.0 on main everywhere
Pull Request resolved: https://github.com/facebook/react-native/pull/34817
Test Plan: CI is green and when imported, nothing breaks.
Reviewed By: cortinico
Differential Revision: D39926953
Pulled By: cortinico
fbshipit-source-id: ff66530382f891e17c00b35edf97c03591b6a9a8
Summary:
Works around a crash identified by Sapienz in D39852058 (https://github.com/facebook/react-native/commit/30411ae1a42e46d0e5a2da494a39ed2767ba8808)
These logs will still be logged to the console, as they were before
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39968830
fbshipit-source-id: 5d7a5d935e85a7d67e7780d95b2253e50888ad90
Summary:
Previously, ViewPropsMapBuffer conversions were hardcoded deep in Android infrastructrue. I've generalized this into a different mechanism to allow any Props struct to support MapBuffer props.
There are still some things that need to be cleaned up and this should be treated as experimental. One thing we likely want to do is remove the hardcoded IDs (fine for codegen'd code; less so for handwritten) and use compile-time-hashed IDs instead with human-readable string names.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708719
fbshipit-source-id: 64603dee7f21828be31346c555d99862dab304ea
Summary:
Instead of having a special flag just for View MapBuffer props, we now use one flag to indicate that MapBuffer should be used for all props; each XShadowNode must set a special trait indicating if that ShadowNode supports MapBuffer props.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D38708718
fbshipit-source-id: b398ec62a0db9c0ff23c0007c5503cf2838c4173
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34819
This is crashing on A12 because of using the regular Context instead of the application context. That said, this probably makes more sense as a log warning.
Reviewed By: javache
Differential Revision: D39852058
fbshipit-source-id: 1ac93f8cc9ecdb14f60baca175c8ecff2ff42ac0
Summary:
when specifying dev server without port, e.g. http://www.example.com/, there are some issues.
1. redbox error
<img src="https://user-images.githubusercontent.com/46429/190540390-8ee420f2-7642-427b-9f2e-e0c6d31015f8.png" width="30%">
2. showing -1 in loading view
<img src="https://user-images.githubusercontent.com/46429/190540727-158f35ad-359f-443a-a4b0-768dd2f7e400.png" width="50%">
the root cause is coming from [`java.net.URL.getPort()` will return -1 when the url doesn't have a port](https://developer.android.com/reference/java/net/URL#getPort()). this pr replaces the parser to [`okhttp3.HttpUrl`](https://square.github.io/okhttp/4.x/okhttp/okhttp3/-http-url/#port) that it will have default port 80 for http or port 443 for https. the two call paths should only serve http/https address, not file:// address. it should be safe to change from java.net.URL to okhttp3.HttpUrl.
not fully related, in the case above, android will connect to `ws://www.example.com/:8097` for react-devtools
we should strip the trailing slash in *setUpReactDevTools.js*
## Changelog
[Android] [Fixed] - Fix port as -1 if dev server without specifying port on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/34705
Test Plan:
test on rn-tester with the following steps
1. `yarn start`
2. open another terminal and run `ngrok http 8081` and it will return a tunnel url, e.g. `71a1-114-36-194-97.jp.ngrok.io`
3. open dev setting in app and change the dev server to `71a1-114-36-194-97.jp.ngrok.io`
5. reload the app
Reviewed By: cipolleschi
Differential Revision: D39573988
Pulled By: cortinico
fbshipit-source-id: 397df90ab30533207bd87a3f069132d97c22c7fd
Summary: Changelog: [Internal] - A refactor to pass the object PointerEventState containing relevant state / and also properties for pointerEvent objects
Reviewed By: vincentriemer
Differential Revision: D39626285
fbshipit-source-id: e2ff5313ef03d7d2d36c35ca459950ec07650df2
Summary:
Changelog: [Internal]
Stop using `TouchEventCoalescingKeyHelper` for tracking and stop making the distinction between traditional touch events (down, up, move) vs hover only events. The only events that currently coalesce are `onpointermove` events. This change uses just one counter now that we increment whenever some non-move event is fired.
Let me know if there's a simpler way to ensure counter doesn't overflow.
This change also ensures we're overriding `getCoalescingKey` which isn't used by Fabric but for old event emitter it might be (which we use for native animations). Part of that requires the `coalescingKey` to be a short so updated to that.
There was also a bug where I forgot to pass `mLastButtonState` to one of the dispatch calls. Will be wrokign on refactor so its less argument soup.
Reviewed By: javache
Differential Revision: D39530927
fbshipit-source-id: 689fa98580b206a480cc08121971cdf96bdbbfaa
Summary:
The previous approach to set a heading in Android required us to trick the accessibility service into thinking that this element was the heading inside of a list, which used to be the only place you could use headings on Android.
This worked for the most part, but could cause problems in specific circumstances, such as if that element actually *was* part of a list. Since we were overriding its CollectionItemInfo, and presenting it as the first item in a single column list, the parent list could have confusing announcements such as announcing this item as "Item 1" even if it was not the first item in the actual list.
Since API 28, there has been an API to set any view as a heading (https://developer.android.com/reference/android/view/View#setAccessibilityHeading(boolean)).
This switches our implementation to use this new API via the AccessibilityNodeInfoCompat class for backwards compatibility to older API versions.
Changelog:
[Android][Changed] - Simplify Accessibility Heading role implementation.
Differential Revision: D39076827
fbshipit-source-id: 583dc1e9d2779a4efa5f98cabef506df2770d892
Summary:
This diff integrates the registration of C++ component into React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725769
fbshipit-source-id: 33eb9ebb93983c4038529748758eac3e43eec3e5
Summary:
CppViewMutationWrapper is a class that will be used to execute operations to mutate C++ Components in React Native Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725765
fbshipit-source-id: 3dfe11deb873750a78f6dbbaee82b62134908de4
Summary:
This diff introduces the APIs that will be used to register C++ components in React Native Renderer for Android
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D38725768
fbshipit-source-id: a7116b787f83544282230666d9d5acbfb1df4047
Summary:
This diff removes the feature flag ReactFeatureFlags.enableSpannableCache and it's already disabled MC
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449840
fbshipit-source-id: 69a514b611c1179f2160a1bfd4c4199538738448
Summary:
Remove feature flag: ReactFeatureFlags.enableScrollEventThrottle
This feature has been disabled for a while
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449184
fbshipit-source-id: c5ad0d43462422d284e14302fb9d7b39aa37da70
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34671
I'm simplifying the template further by:
- Do not expose a configurable dynamic library name. Let's use `appmodules`
and still allow the users to configure it, if needed.
- Move all the initialization logic inside the `JNI_OnLoad` method
- Cleanup the `DefaultReactNativeHost` to don't require a dynamic library
name but just a boolean.
Changelog:
[Android] [Changed] - Further simplify the New App Template by don't requiring the dynamic library name
Reviewed By: cipolleschi
Differential Revision: D39462948
fbshipit-source-id: 737733fc263162a0baf3b7a451e48b8616679d3b
Summary:
PlatformColor should work on all *color style attributes on all platform.
Partially fixes https://github.com/facebook/react-native/issues/32942
## Changelog
[Android] [Fixed] - Support PlatformColor in borderColor
Pull Request resolved: https://github.com/facebook/react-native/pull/33544
Test Plan: Open rn tester (USE_FABRIC=false) platform color api examples. Without the changes to ViewProps.java, it will error out.
Reviewed By: lunaleaps
Differential Revision: D39413519
Pulled By: NickGerleman
fbshipit-source-id: 58962ba2956aa3df45144108eec194aedf23886b
Summary:
This diff reduces the amount of C++ code in user space by:
- Moving all the C++ implementation of the .defaults package inside a `react_newarchdefaults` shared library
- Exposing only the entrypoint logic inside the RN-Tester's `OnLoad.cpp` file.
Changelog:
[Android] [Changed] - Reduce the amount of C++ code in user space for New Architecture
Reviewed By: cipolleschi
Differential Revision: D39381820
fbshipit-source-id: 9c4b5596b67b5a7ee58824319c80e325348ed06c
Summary:
Changelog: [Internal] - Stop dispatching pointer events when a child view has indicated it wants to handle a native gesture.
In discussion and alignment with web standards, we've decided to not dispatch any pointer events during a native gesture.
Currently, on ACTION_HOVER_MOVE, we remove child views of the native gesture handling view and continue dispatching onPointerMove for ancestor views. This change removes this logic and won't dispatch a onPointerMove event at all.
For all other MotionEvent actions, this is already the case.
Also adding an example in RNTester that involves a scrollView (which handles gestures during scrolling)
Reviewed By: javache
Differential Revision: D39377157
fbshipit-source-id: cb0a719f67136e31b68d6f6e794fee10b256bf21
Summary:
With the IDE autocompletion now working \o/ I was able to apply some suggestions
to the Kotlin code I wrote inside the .defaults package (like remove redudant qualifiers and similar).
Changelog:
[Internal] [Changed] - Cleanup the Kotlin code in the .defaults package
Reviewed By: cipolleschi
Differential Revision: D39348983
fbshipit-source-id: b443a6be179c85d2a4f4293051c4f26af93eb5f1
Summary:
Noticed this marker was not properly ended in the case where an early return happens. The fact that that early return is happening there is problematic too, so added a warning to follow-up on.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D39271917
fbshipit-source-id: 86dd5b1a46978629584f7cb0d615f2ad99d5a2f8
Summary:
UIImplementation(Provider) is not compatible with the new renderer (Fabric) and the relevant constructors have been marked deprecated for a while. While ReactInstanceManagerBuilder creates a default instance, it's not even used by CoreModulesPackage.
Changelog: [Android][Removed] Removed deprecated UIImplementationProvider
Reviewed By: NickGerleman
Differential Revision: D39271916
fbshipit-source-id: 20a3b02843ea9a2ba4bfc1352037239febbafc64
Summary:
The `JSDevSupport` module is incompatible with Fabric. Given it's not used internally and it's undocumented in OSS, we decided to remove it altogether.
Changelog: [Internal]
Reviewed By: javache, nlutsenko
Differential Revision: D39305892
fbshipit-source-id: 82455701a0b9ba83e6f971fc774280dceb2b22e0
Summary:
This PR should fix the issues introduced by commit c34659a5d3.
The problem is that `Collections.emptyList` creates a `List<Object>` which is not compatible with the `List<TargetView>` type.
## Changelog
[Android] [Fixed] - Make Android CI build again.
Pull Request resolved: https://github.com/facebook/react-native/pull/34573
Test Plan: test_buck and the "test Docker android" must be green.
Reviewed By: cipolleschi
Differential Revision: D39235674
Pulled By: cortinico
fbshipit-source-id: 574338e74aeb4635c67d91de28780fb784c9f405
Summary:
Changelog: [Internal] - Key cached values between different MotionEvents by pointerId.
Currently the implementation uses one cached list and array to store the last hitPath and event coordinates. We use these to determine if we've entered or left any views.
With more pointers, we need to be tracking these values for each pointer.
As well, clean up usage of `mLastTargetCoordinates`. This doesn't need to be a global as its an array that's updated by reference in `findTargetPathAndCoordinatesForTouch`
Reviewed By: vincentriemer
Differential Revision: D39152528
fbshipit-source-id: 28c18629bf974f41950401c7726a4757ad43ac28
Summary:
Changelog: [Internal] - Fix more pointer event platform tests.
* Fix the coordinate system to use DIP
* Set some properties for when pointerType="mouse"
Reviewed By: vincentriemer
Differential Revision: D39184713
fbshipit-source-id: d86f798f3e0a377ff1c159fb308329a2c9ae03ff
Summary:
Changelog: [Internal] - Refactor JSPointerDispatcher to group secondary actions (pointer_up, pointer_down) to use same logic and emit non-direct events
This diff re-arranges some code and re-uses some logic for different MotionEvent types.
Specifically, before our code for handling a motionEvent looked like
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) {
handleHoverEvent(event)
}
if (event is ACTION_DOWN) {
// logic for dispatching down, enter, over
}
if (event is ACTION_POINTER_DOWN) { // this represents any secondary pointer going down
// logic for dispatching down
}
if (event is ACTION_MOVE) {
// logic for dispatching touch move
}
if (event is ACTION_UP) {
// logic for dispatching up, out, leave
}
if (event is ACTION_POINTER_UP) { // this represents any secondary pointer going up
// logic for dispatching up
}
....
}
```
now, we've refactored it to be like:
```
func onMotionEvent(event) {
if (event is HOVER_MOVE) { // Still keep this as separate because it does some special things. Will refactor in follow-up diff
handleHoverEvent(event)
}
switch() {
case ACTION_DOWN or ACTION_POINTER_DOWN:
// do same logic
break;
case ACTION_UP or ACTION_POINTER_UP:
// do same logic
break;
case ACTION_MOVE:
// do same logic, we will want to converge this logic with HOVER_MOVE, todo in a follow-up
break;
...
}
....
}
```
This refactor adds the functionality of `enter, over, out, leave` to secondary pointer events in which they weren't fired before.
Reviewed By: vincentriemer
Differential Revision: D39142820
fbshipit-source-id: 8b89db6dc22f24583f8c14dbb8392d4dc8ff6e4d
Summary:
Changelog: [Internal] - Make sure `onChildEndedNativeGesture` is called for view managers that call `onChildStartedNativeGesture`
This affects `JSTouchDispatcher`, `JSPointerDispatcher` as they track what view is reporting native gesturing handling.
This is a bug that view managers never shared the fact that they've stopped managing a native gesture. Both `JSTouchDispatcher`, `JSPointerDispatcher` get around this by manually resetting their internal flag on ACTION_DOWN event (we will get rid of this in a later diff)
Reviewed By: javache
Differential Revision: D38850609
fbshipit-source-id: ef4afb591249bb621f42667608dc1ef20424b65c
Summary:
When the webview is updated by play store, all apps that has loaded webview gets killed. For background see https://issuetracker.google.com/issues/228611949?pli=1
We have a long-running app and don't want this to happen and while we are not using webview anywhere, we are using websockets that loads it for reading cookies, however we are not using cookies to authenticate the websocket and thus want to disable the webview to avoid loading it unnecessarily and then getting killed unnecessarily.
The webview has support for beeing disabled https://developer.android.com/reference/android/webkit/WebView#disableWebView() however as-is this crashes React Native. It seems to me like this case is very similar to not having web view installed and should be handled in the same way.
## 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] [Fixed] - Avoid crash in ForwardingCookieHandler if webview is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/34483
Test Plan: Add `WebView.disableWebView();` as the first line in `MainActivity.onCreate`.
Reviewed By: christophpurrer
Differential Revision: D38981827
Pulled By: cipolleschi
fbshipit-source-id: 335a8420568ad0c80b834ae8a3b164e55ebe26f3
David Vacca
Samuel Susla
Luna Wei
Peter Abbondanzo
Matt Blagden
Pieter De Baets
Joshua Selbo
Lorenzo Sciandra
Ruslan Shestopalyuk
Christopher Jones
Rachit Mishra
Kudo Chien
Luna Wei
Brett Lavalla
David Vacca
Nicola Corti
Danilo Bürger
Samuel Susla
Pieter De Baets
Rubén Norte
Riccardo Cipolleschi
Rasmus Eneman
