Summary:
Changelog: [Internal]
making these imports a little more optimal & clean
Reviewed By: javache
Differential Revision: D31594240
fbshipit-source-id: 076610454a6f3c35ac58e97bd9f887b05b86f5bb
Summary:
Noticed we were sometimes receiving incorrect paths through the view hierarchy. This was largely harmless, as the hover events generated from this would still be correct. We just sometimes send more onExit/onEnter events than necessary.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D31434300
fbshipit-source-id: 3888270eaa16edf48f5d894a1e6daeca1ecfed1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32403
As the title says, we should cleanup issues that are really stale (i.e. more than one year inactive).
I ended up using actions/stale which is the first party solution for this.
Changelog:
[Internal] [Changed] - Add stale GitHub action
Reviewed By: hramos
Differential Revision: D31653083
fbshipit-source-id: 48538a571183f9ff28a23e7d1fdd01980581de35
Summary:
These dynamic_casts aren't really giving us much (they have never fired once in dev! and don't run in prod anyway). They also prevent us from disabling RTTI. So, let's get rid of them.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D31634895
fbshipit-source-id: 4a9b259837127feb324f64fa3e9e23eb1cc481a6
Summary:
Using `WriteableNativeArray` directly in common code is breaking unit tests on CircleCI.
Changelog:
[Android][Internal] - Use mock of native array for sending touches
Reviewed By: mdvacca
Differential Revision: D31665842
fbshipit-source-id: 886418ff6a3f07046e8e17d4743060d80c26b288
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Centralize C++ compiler flags in rn_defs.bzl.
There is really no reason for these Cxx libraries to specify their own compiler flags: nearly 100% of them are identical, and the copypasta makes it difficult to make repo-wide changes (like upgrading C++ versions, etc).
This is now causing build failures until everything is migrated properly, and there are two flags (enable_rtti and enable_exceptions) that MUST have the same value and can be configured per-module, as needed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631767
fbshipit-source-id: 84f0441eb0ad09219e97d13babe0707d25f08472
Summary:
This seems like a remnant of an old refactor. This is passed in, we wrap it with a JMessageQueueThread and then never use it again.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31506280
fbshipit-source-id: aca01439dcddbe2b44ce80342fa8664f827919c9
Summary:
Updates touch events in Fabric to be dispatched through the same pipeline as the rest of events, instead of relying on custom dispatch behavior.
Previous method of handling touches was reusing Paper behavior which required:
1. Transform event into a Paper-compatible form of WritableArray and dispatch it to `RCTEventEmitter.receiveTouches`.
2. Intercept `receiveTouches` for Fabric and redirect it to `FabricEventEmitter`
3. Perform transformations copied from Paper JS renderer in Java, transform it to the final form and dispatch this event as usual after.
The new behavior uses emitter's `receiveEvent` method directly to dispatch events. Additionally, it should decrease allocations done when transforming events during step 3 above, as `WritableNativeMap`-based operations performed many re-allocations when reading/re-creating arrays.
Changelog:
[Android][Changed] - Added an experimental touch dispatch path
Reviewed By: JoshuaGross
Differential Revision: D31280052
fbshipit-source-id: 829c2646ac6b0ebff0f0106159e76d84324ac732
Summary:
Simplifies logic of touch dispatch by retrieving surface id and other require info from the event directly.
Changelog: [Android][Internal] - Simplify logic of dispatching touches
Reviewed By: cortinico
Differential Revision: D31583314
fbshipit-source-id: c6b6e131a759c2ebe0cf4441c3aeb1a8b9f5781e
Summary:
Ref https://github.com/facebook/react-native/issues/25601#issuecomment-510856047.
From https://github.com/facebook/react-native/pull/31040.
The `hermesFlagsRelease` option only works with the release build type, but not with other build types.
This PR allows hermes flags on a per variant basis to be specified using the `hermesFlagsForVariant` lambda.
It also allows the hermes debugger cleanup to be run on a per variant basis using the `deleteDebugFilesForVariant` lambda.
## 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] - Fix hermesFlags not working with multiple variants
Pull Request resolved: https://github.com/facebook/react-native/pull/32281
Test Plan:
Set the following options in `android/app/build.gradle` and ensure warnings are hidden when running `./gradlew assembleRelease` and `./gradlew assembleLive`.
```
hermesFlagsForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live') ? ['-w'] : []
},
deleteDebugFilesForVariant: {
def v -> v.name.toLowerCase().contains('release') || v.name.toLowerCase().contains('live')
},
```
Reviewed By: cortinico
Differential Revision: D31234241
Pulled By: ShikaSD
fbshipit-source-id: 2cb3dd63adbcd023061076b5a3b262a87b470518
Summary:
Propagate event category definition to every event that is using `dispatchModernV2` (gated in production), providing opportunity to override categories of some events if needed. No events are meaningfully affected by this change, as coalesced events (e.g. scroll) are always dispatched as continuous and touch events are handled separately.
Changelog:
[Internal] Expose event category in Event class
Reviewed By: cortinico
Differential Revision: D31276249
fbshipit-source-id: f9a756b3a5cf5897e17209f3d0aed6a1c16cbd2e
Summary:
This Diff is restricting the scope of `mavenCentral` to do not
include react-native packages. This will make us sure we don't pickup older
versions of react-native.
This specifically is a problem if you're building on a nightly as the version
of RN nightly is `0.0.0.xxx` which is lower than then version on maven central.
More on this here https://github.com/facebook/react-native/pull/32326#issuecomment-933368880
Changelog:
[Internal] [Changed] - Restrict mavenCentral to exclude react-native older packages
Reviewed By: ShikaSD
Differential Revision: D31571803
fbshipit-source-id: d7ce7e82825cbebda2e4e534565d7ab15dba2624
Summary:
https://reactnative.dev/docs/view.html doesn't work, this diff replaces the url for the new link
[Changelog]
[General][Fixed] - Updated documentation link in `View`.
Reviewed By: yungsters
Differential Revision: D31519836
fbshipit-source-id: c93feee4652caf4ef8390a047599149fc547db48
Summary:
This issue is found when investigating T101563978 with IOS platform. When animation is off, the x position measurement is off after `scrollToItem` is called.
The android fix is checked in at D31492685 (https://github.com/facebook/react-native/commit/1a9e2d5d5589ce5cee92868ea5bccceb6e161eff). For IOS, the correct state data is updated only for animated cases, but not for instant scroll cases. This diff unified them.
Changelog
[IOS][Fixed] Fixed an edge case when scroll to item/index is called without animation, the offset position is not updated. This caused the measurement of the position to be wrong.
Reviewed By: sammy-SC
Differential Revision: D31564169
fbshipit-source-id: 89f47d8054afb03c2ace1d595163b160e5bb2036
Summary: Changelog: [Internal] - Change accessibilityValue.text type to allow for Stringish type
Reviewed By: yungsters
Differential Revision: D31577860
fbshipit-source-id: af12505794037a68850a16ce139359e2f8a879e4
Summary:
Added more logs to understand what's the root cause for https://fburl.com/logview/kgknonri
```java.lang.IllegalStateException: Message queue threads already initialized
at X.5y2.A0I(:64)
at com.facebook.venice.ReactInstance.<init>(:112)
at X.PrB.EgB(:33)
at X.2pN.run(:4)
at X.2pA.execute(:32)
at X.2p6.A00(:30)
at X.2p6.A08(:2)
at X.PrC.EgB(:26)
at X.Pr7.run(:4)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
```
Changelog:
[Android][Changed] - Add some logs
Reviewed By: RSNara
Differential Revision: D31584264
fbshipit-source-id: 11b8bb2c6c9af2266688e3dae95e09f0160de79a
Summary:
This is a proposal to adjust the in-code documentation to clarify the semantics of the `enableHermes` variable.
This fixes https://github.com/facebook/react-native-website/issues/2813.
## 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] - Clarified in-code documentation in the template's `android/app/build.gradle`.
Pull Request resolved: https://github.com/facebook/react-native/pull/32382
Test Plan: This is just an update to documentation, no need for tests.
Reviewed By: yungsters
Differential Revision: D31550133
Pulled By: Huxpro
fbshipit-source-id: d60e5d256e1ffaf8556710b75582f1ae1c0f1fd3
Summary:
The elevation barriers that limited view reordering were applied incorrectly, disabling elevation completely for some combinations of views. This change ensures the order of barriers is correct and only disables elevation reorder between the children and not on them.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D31541961
fbshipit-source-id: 2fa4dc6906790053bd4445c841aeda0e2b3830e5
Summary:
The test_docker_android job on Circle CI has a simple function: verify the base community RN Android image can be downloaded, and verify that we can use it to build a container with a compiled Android test app.
Since the job is not strictly running a suite of tests, it can be moved to GitHub Actions. It will run on GitHub Actions as a Check on commits to main and pull requests.
As building the test image requires the use of the base React Native Android image, we can skip downloading the base container and go straight to building the test image.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31521978
fbshipit-source-id: ca8372a1464054e37f2da28a3ecfbc8f84db0408
Summary:
The `scrollTo` method in ScrollViews are using the `(x, y)` position they got from upperstream to scroll, and to set the state for Fabric. This diff fixes an edge case where the scroll result is not ended up to `(x, y)`. For example, if we are going to scroll to the last item in the list, the item may not scroll to the `(x, y)` position, but stay at the end position of the view.
- Change `scrollTo` method to use the actual `scrollX` and `scrollY` position after scrolling to set current state.
Changelog:
[Android][Fixed] - scrollTo API in ScrollView will check the actual scroll position before setting the scroll state
Reviewed By: JoshuaGross
Differential Revision: D31492685
fbshipit-source-id: e5513fb735ea68c5014b5c47fadffe461cad5c94
Summary: Changelog: [Internal] Configure circleCI to comment on PR after building tarball
Reviewed By: hramos
Differential Revision: D31387660
fbshipit-source-id: 28902148cf5e2ea15320333b90a6a7fa9d553c3b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32247
I don't think we need both libc++ and libstdc++.
allow-large-files
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30950943
fbshipit-source-id: d0669815ff59c3e9ac45954a4a11930d1bc3959f
Summary:
changelog: [internal]
calling `setEnabled(true)` needs to have a matching `setEnabled(false)` in order for `eventTarget_` to be deallocated correctly.
Also, retaining `eventTarget_` longer, does not mean instanceHandle will be available later on.
Reviewed By: p-sun
Differential Revision: D31503119
fbshipit-source-id: 324e16fe0f6ad937ab2c38be9a536bdf14851172
Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This module is imported by all flavors of the React Native renderers (dev/prod, Fabric/Paper, etc.), which itself imports `InitializeCore`. This is effectively a no-op in most React Native apps because Metro adds it as a module to execute before the entrypoint of the bundle.
This import would be harmless if all React Native apps included all polyfills and globals, but some of them don't want to include everything and instead of importing `InitializeCore` they import individual setup functions (like `setupXhr`). Having this automatic import in the renderer defeats that purpose (most importantly for app size), so we should remove it.
The main motivation for this change is to increase the number (and spec-compliance) of Web APIs that are supported out of the box without adding that cost to apps that choose not to use some of them (see https://github.com/facebook/react-native/pull/30188#issuecomment-929352747).
Changelog: [General][Removed] Breaking: Removed initialization of React Native polyfills and global variables from React renderers.
Note: this will only be a breaking change for apps not using the React Native CLI, Expo nor have a Metro configuration that executes `InitializeCore` automatically before the bundle EntryPoint.
Reviewed By: yungsters
Differential Revision: D31472153
fbshipit-source-id: 92eb113c83f77dbe414869fbce152a22f3617dcb
Summary:
We are defining an alias for the global variable in React Native called `GLOBAL`, which is not used at all at Facebook and it doesn't seem it's used externally either. This alias is not standard nor common in the JS ecosystem, so we can just remove it to reduce the pollution of the global scope.
Changelog: [General][Removed] - Removed unnecessary global variable `GLOBAL`.
Reviewed By: yungsters
Differential Revision: D31472154
fbshipit-source-id: 127c3264848b638f85fb2e39e17ed2006372d2dd
Summary:
The Modal's mock always render its children (whether it is visible or not), whereas in reality the Modal renders `null` when the Modal is not visible.
This causes troubles when trying to test whether the Modal is visible or not. Instead of testing if the children are rendered (using getByText from React Native Testing Library for instance), we are forced to test the value of the visible prop directly (see https://github.com/callstack/react-native-testing-library/issues/508 and https://github.com/callstack/react-native-testing-library/issues/659).
This is not ideal because we are forced to test implementation detail and can't test from the user perspective. I also believe the mock should be closest as possible from reality.
I had 2 options:
1. Rendering the Modal without its children
2. Not rendering the Modal at all
The latter has the advantage of being closer to the reality, but I chose the former to still be able to test the Modal through the visible prop, so there is no breaking change (only snapshots update will be required).
## Changelog
[General] [Changed] - Update Modal's mock to not render its children when it is not visible
Pull Request resolved: https://github.com/facebook/react-native/pull/32346
Test Plan:
I added a test case when visible is false, then updated the mock so the children are not rendered. The before / after is here:
Reviewed By: yungsters
Differential Revision: D31445964
Pulled By: lunaleaps
fbshipit-source-id: 08501921455728cde6befd0103016c95074cc1df
Summary:
changelog: [internal]
Catch JavaScript errors and forward them to `ErrorUtils` in *RuntimeScheduler*. This makes sure that JS errors are handled by ErrorUtils and do not bubble up to bridge.
Reviewed By: philIip
Differential Revision: D31429001
fbshipit-source-id: 50f865872e4cd3ba180056099ff40f5962ee7a77
Summary:
We noticed that by default when the RootView / ReactView calls runApplication, we're logging at an info level any props ("params") passed to that component. In our case, one of these props was sensitive in nature, causing the value to leak out in logs for our release builds. This is especially problematic on Android where device logs can be accessed by any app which requests that permission.
This is probably more of a concern for brownfield react-native apps, but it seems worthwhile locking this down in non-dev builds.
## 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
-->
[General] [Security] - Avoiding logging root view params outside of dev / debug mode builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31522
Test Plan: * build app in release mode on Android and verified I could not see: `Running "my app" with { sensitive: 'thing' }` in logcat in Android Studio with a tethered device
Reviewed By: yungsters
Differential Revision: D31064902
Pulled By: charlesbdudley
fbshipit-source-id: 8b10a46d92a9ec44243dd74384299087260c7d83
