Summary:
Follow up from https://github.com/facebook/react-native/issues/48271 and https://github.com/facebook/react-native/issues/48254, I noticed that the Modal component also doesn't map the `resource-id` from the `testID` on Android. This PR addresses that.
## Changelog:
[ANDROID] [FIXED] - Modal: Setting `resource-id` from `testID` prop
Pull Request resolved: https://github.com/facebook/react-native/pull/48313
Test Plan:
Alternatively do:
```
$ adb shell uiautomator dump
UI hierchary dumped to: /sdcard/window_dump.xml
$ adb pull /sdcard/window_dump.xml
/sdcard/window_dump.xml: 1 file pulled, 0 skipped. 1.1 MB/s (3505 bytes in 0.003s)
```
and check in XML: ` resource-id="playground-modal" class="android.view.ViewGroup" `
-------
Using Appium, check that the `testID` prop passed from JS is mapped as `resource-id` in the rendered view group of the Modal.
<details>
<summary>Example of the code implementation in the RNTester Playground:</summary>
```tsx
function Playground() {
const [modalVisible, setModalVisible] = React.useState(false);
return (
<>
<Modal
visible={modalVisible}
testID="playground-modal">
<Text testID="inner-text-test-id">Hello World!</Text>
</Modal>
<Button
title="Open Modal"
onPress={() => {
setModalVisible(true);
}}
/>
</>
);
}
```
</details>
<details>
<summary>Output in Appium Inspector:</summary>
<img width="913" alt="image" src="https://github.com/user-attachments/assets/514ae2b3-35a8-4a1a-8efc-1ca6bd73f189" />
</details>
Reviewed By: javache
Differential Revision: D67369350
Pulled By: alanleedev
fbshipit-source-id: a799ad5b974895a39d9287e3d76d1139a6ef6a83
Summary:
If 3rd party libs are using `inputAccessoryView` - the current code can easily break it. Whenever props gets changed we call `setDefaultInputAccessoryView` which will simply overwrite the current `inputAccessoryView` (which is highly undesirable).
The same fix on paper was made ~7 years ago: https://github.com/facebook/react-native/commit/bf3698323d81508fc77174df2b1ffe5fb03224e7
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[IOS] [FIXED] - Fixed problem with accessory view & 3rd party libs
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/48339
Test Plan: Make sure `inputAccessoryView` functionality works as before
Reviewed By: javache
Differential Revision: D67451188
Pulled By: cipolleschi
fbshipit-source-id: bc3fa82ae15f8acedfd0b4e17bdea69cbd8c8a8d
Summary:
All newly generated react native apps are still showing warnings to use react in the jsx scope. That is not needed anymore as of react 18 with built-in jsx transform plugin.
Reproduction: https://github.com/matinzd/react-in-jsx-warning-repro
Run `npm run lint` in this repo.
## Changelog:
[GENERAL] [FIXED] - Disable `react-in-jsx-scope` rule in eslint config
Pull Request resolved: https://github.com/facebook/react-native/pull/46587
Test Plan: Initiate a new template with community CLI and you should not see this warning anymore.
Reviewed By: christophpurrer
Differential Revision: D67394923
Pulled By: cipolleschi
fbshipit-source-id: cfe8e44e33e1b3ae9fe17ca56dd3c7258b7bff69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48250
LLVM-15 has a warning `-Wunused-variable` which we treat as an error because it's so often diagnostic of a code issue. Unused variables can compromise readability or, worse, performance.
This diff either (a) removes an unused variable and, possibly, it's associated code or (b) qualifies the variable with `[[maybe_unused]]`.
- If you approve of this diff, please use the "Accept & Ship" button :-)
Reviewed By: palmje
Differential Revision: D66839601
fbshipit-source-id: dfba4aab6d73a2fd805ad2761a49c23612c28ccd
Summary:
Originally with https://github.com/facebook/react-native/commit/5cf8f43ab182781ea82e88077df425c3efbfc21f , we added a call to a new Apple API `JSGlobalContextSetInspectable` to ensure that our Javascript running with JSC is debuggable. That change was guarded with a `__builtin_available(macOS 13.3, iOS 16.4, tvOS 16.4, *)` check to make sure it only ran on OS'es where to function existed. Later, in https://github.com/facebook/react-native/commit/3eeee11d7ac4075d0917233d3be4a9469f802d35 we did an extra guard in the way of a macro to check we were compiling against a new enough version of Xcode (so that Xcode knows about the symbol).
Between the runtime check and the compile time check, we should be good right? Wrong! As it turns out, this bit of code still caused crashes on iOS 15 devices (See this [Apple Forum Thread](https://forums.developer.apple.com/forums/thread/749534)). To address this, https://github.com/facebook/react-native/pull/44185 was added which added a new compiler guard (`__OSX_AVAILABLE_STARTING(MAC_NA, IPHONE_16_4)` was added. Unfortunately, this guard is incorrect: It is basically checking if our minimum iOS deployment target is 16.4 (It's not, as of writing it is iOS 13.4), which effectively means this code is never compiled and one can never direct debug with JSC on iOS 16.4+ 😨!
So what went wrong, and why were the first two guards not good enough? Three main reasons..
Firstly, this is a device only crash, and not reproducible on simulator. This is probably why the crash was not caught earlier. Secondly, It's because system frameworks (like JavascriptCore) are _dynamically_ linked: the linker doesn't look for the symbol till runtime (and crashes when doing so). Thirdly, It's because we are _strongly_ linking the framework, so every symbol must be present and the macros / guard Apple provides with `AvailabilityMacros.h` don't work.
What we want to do is link JavascriptCore as a `weak_framework`, more info here: https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html
From that link:
> One challenge faced by developers is that of taking advantage of new features introduced in new versions of OS X while still supporting older versions of the system. Normally, if an application uses a new feature in a framework, it is unable to run on earlier versions of the framework that do not support that feature. Such applications would either fail to launch or crash when an attempt to use the feature was made. Apple has solved this problem by adding support for weakly-linked symbols.
>When a symbol in a framework is defined as weakly linked, the symbol does not have to be present at runtime for a process to continue running. The static linker identifies a weakly linked symbol as such in any code module that references the symbol. The dynamic linker uses this same information at runtime to determine whether a process can continue running. If a weakly linked symbol is not present in the framework, the code module can continue to run as long as it does not reference the symbol. However, if the symbol is present, the code can use it normally.
This seems to be exactly what we want, and the Apple provided method for using new APIs in system frameworks!
Let's update our podspecs so we link JavascriptCore weakly. As a bonus (and admittedly, the original purpose of this PR) let's add macOS support to the `JSC_HAS_INSPECTABLE` macro (This file `JSCRuntime.cpp` used to have more explicit macOS support in it's macros, but I had removed it with https://github.com/facebook/react-native/commit/fb30fcaa2f526cc1f7c2d4189ec9c57f9cf9b3c5).
## Changelog:
[IOS] [FIXED] - Fix Direct Debugging with JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/39549
Test Plan:
Tested that RNTester doesn't crash on boot running on an iPad Air 2 running iOS 15.8., and that an iOS 17.2 simulator is debuggable.
Built RN-Tester and RN-Tester-macOS and verified both show up in Safari Web Inspectors' debug menu:
<img width="1316" alt="Screenshot 2023-09-19 at 10 48 43 PM" src="https://github.com/facebook/react-native/assets/6722175/c642e6e0-36af-4c9f-845a-7e491489f419">
macOS screenshot small bc I got some internal stuff I gotta crop 😅
<img width="347" alt="Screenshot 2023-09-19 at 10 53 46 PM" src="https://github.com/facebook/react-native/assets/6722175/1e802c88-02b8-49e1-8fd2-d91726ca1e93">
Reviewed By: huntie
Differential Revision: D67338150
Pulled By: cipolleschi
fbshipit-source-id: 620c3b3cc1e37e54de7fa4dc9956a02c8f3c09f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48312
I figured out how to fix these FlowFixMes
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D67313962
fbshipit-source-id: 21b109824411c1537f397aca45b7cdc2495f5e11
Summary:
This is an automatically generated fixup patch to bring fbsource back into sync with
facebook/react on GitHub. Please land this patch as soon as possible, as the difference
reflected on here is already on GitHub and future changes may depend on these
changes!
<< DO NOT EDIT BELOW THIS LINE >>
diff-train-skip-merge
bypass-react-native-oss-changelog
Generated by: https://www.internalfb.com/intern/sandcastle/job/36028798618339642/
GitHub Repo: facebook/react
Reviewed By: kassens
Differential Revision: D67286468
fbshipit-source-id: 66632a2524e80bca065d0a0f94342c4ec2d2a7b9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48307
Changelog:
[General][Fixed] - Fix a bug when fantom tests could not be run in parallel, e.g. in a stress-test.
Reviewed By: rubennorte, danalex97
Differential Revision: D67334828
fbshipit-source-id: 3db18f6a100925480dbf8385f9ea414187406f4a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48306
Extract a constant for SoftAssertions so they can be logged appropriately
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D67296589
fbshipit-source-id: c8823fd5dfa09a771bb8fbf498edb8d9264f053f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48303
## Context
If a component is re-rendered/committed multiple times before mount, Android mounting layer creates and executes mounting instructions for every commit. Component's native representation is updated multiple times, potentially triggering expensive computations (e.g. recreating boxShadows) for a single draw.
A more efficient way would be to create mounting instructions to update the component from the initial state (before the first render) to the final state (after the last render) in one go.
iOS does that.
This diff is an attempt to experiment on achieving such behaviour for Android.
## Implementation Details
1. When cloning a ShadowNode, accumulate all the updates in `Props.rawProps`.
2. For calculating prop update payloads to be sent to the Android mounting layer, diff old and new `rawProps` by calling `newProps->getDiffProps(oldProps)`.
3. Most importantly, move computing of the mounting instructions from `schedulerDidFinishTransaction`, which is called after every commit, to `schedulerShouldRenderTransactions` which happens only once, after the final commit.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63457028
fbshipit-source-id: 991727838a4e11628cb696d66d41e1d441a5ef4f
Summary:
Fixes https://github.com/facebook/react-native/issues/45810
Upgrading `typescript-config` module version from `es2015` to `esnext`, in order to support dynamic imports.
## Changelog:
[GENERAL] [CHANGED] - Upgrading `typescript-config` module version to `esnext`
Pull Request resolved: https://github.com/facebook/react-native/pull/48230
Test Plan:
Create a new React Native project:
```bash
npx react-native-community/cli@latest init AwesomeProject
```
Copy the changes in the reproducer from the linked issue and add a lazy import:
```tsx
const LazyAssetExample = React.lazy(() => import('./components/AssetExample'));
```
See the error when running `yarn tsc`:
<img width="739" alt="image" src="https://github.com/user-attachments/assets/99989cd1-e11a-4b23-b178-f221d8cdd8ca" />
---
To fix the error, apply the following patch:
```patch
diff --git a/node_modules/react-native/typescript-config/tsconfig.json b/node_modules/react-native/typescript-config/tsconfig.json
index d5e1bce..51f54c1 100644
--- a/node_modules/react-native/typescript-config/tsconfig.json
+++ b/node_modules/react-native/typescript-config/tsconfig.json
@@ -3,7 +3,7 @@
"display": "React Native",
"compilerOptions": {
"target": "esnext",
- "module": "es2015",
+ "module": "esnext",
"types": ["react-native", "jest"],
"lib": [
"es2019",
```
Verify it is fix by running `yarn tsc` again
Reviewed By: cipolleschi
Differential Revision: D67334277
Pulled By: NickGerleman
fbshipit-source-id: d26525023ff6fcfff651d1e4cee48ab2854b8d83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48286
This change bumps the specs for the Android E2E tests. This has been reported to improve the stability of the tests.
We need to keep part of the `flatlist.yml` commented as it creates an issue with Maestro as it takes too much memory.
I'll reach out to the people working on Maestro to try and understand what's going on there.
## Changelog:
[Internal] - Improve android Stability and reenable E2E tests on main
Reviewed By: fabriziocucci
Differential Revision: D67276601
fbshipit-source-id: 7cca253547063a0ec39da7de58806286c6632b07
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48279
The text tests has 2 issues:
* on iOS, the Text cell was sometimes rendered below the tabbar, with a small percentage visible. When this happens, the test was actually moving to a different tab rather then navigating to the Text screen
* on Android, sometimes navigation took too long and a scroll command was issued. This moved the screen away from the right screen we wanted to test.
This change fixes both issues by ensuring that the Text cell is 100% visible (not behind the tabbar) and by ensuring that the title "Text" is visible in Android, so the navigatin has actually happened
## Changelog:
[Internal] - Fix Text tests
Reviewed By: fabriziocucci
Differential Revision: D67274009
fbshipit-source-id: ed12f096788e7e6e74ee8d336dba350b35b85e81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48280
In an attempt to improve times and stability, I bumped the android machine to an ubuntu with 4 cores.
Sometimes the emulator can hang, so i set a timeout for the E2E tests executions of 1 hours to avoid wasting money in CI
## Changelog
[Internal] - Bump Android machine and add timeout
Reviewed By: fabriziocucci
Differential Revision: D67273842
fbshipit-source-id: b7212f52016f8ead1dbb2b4da03cb6f564222893
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48281
While working on Maestro E2E I realized that we were waiting for Metro to start even when metro was not running.
This moves the waiting only when metro is actually started.
I also added another waiting point as it takes several seconds for the app to load the bundle from metro the first time. Subsequent attempts are faster as the metro cache is warm.
## Changelog:
[Internal] - Improve metro waiting times in E2E
Reviewed By: fabriziocucci
Differential Revision: D67273648
fbshipit-source-id: 912be4d14869c8ce87d7c4e4f7ee37b643f5845c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48282
This change bump maestro to the latest version as it present better reporting.
## Changelog:
[Internal] - Bump maestro to 1.39.5
Reviewed By: fabriziocucci
Differential Revision: D67273486
fbshipit-source-id: da41a002528a3b3c0934f86888da2bb53ae131b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48289
Provide a mechanism to register specific category constants, which can be used by individual `ReactSoftExceptionListener`s to differentiate behavior, if desired.
Changelog: [Android][Added] SoftException categories
Reviewed By: makovkastar
Differential Revision: D66785403
fbshipit-source-id: cb2c8861bb1dce29a6787d328b814cee09f36464
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47749
Migrate ReactPointerEventsView to kotlin
changelog: [Android][Breaking] Mikgrating pointerEvents API breaks compatibility for kotlin usages of this api as a val
Reviewed By: cortinico
Differential Revision: D66217250
fbshipit-source-id: ff192c9f92d1df93c082b563937eb3f37176f144
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48269
# Changelog: [Internal]
I've noticed that our definition of Trace Event is different from the one that is defined in Google's doc / V8 / Chrome. This has some flaws:
* It creates fragmentation, like with custom track ids or with mocked process ids.
* Current implementation is strict the relationship between `performance.mark()`, `performance.measure` APIs and Instant, Complete Trace Events. Basically only something recorded with `performance.mark` can be an instant trace event.
This should unblock recording custom trace events inside `PerformanceTracer`, such as when tracing started and others. Same could be said about events related to CPU profiling from Hermes, which will be based on these APIs.
This is the pre-requisite for next diff that will add emitting `TracingStartedInPage` event. With this event, the trace should look similar to the one recorded in the browser, and Timings / Main tracks no longer should be registered manually.
Reviewed By: huntie
Differential Revision: D67207107
fbshipit-source-id: fd7f55dd82167c14a63c2d93aaa649072c5a2a2c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48292
These dependencies are making the CI on main to fail.
## Changelog:
[General][Fixed] - Fix peer dependencies on React types
Reviewed By: javache, hoxyq
Differential Revision: D67283609
fbshipit-source-id: b325246f5de654a9ccbf7f96eec24434047a38ee
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48160
Shift to mockito-kotlin and fix ReactCookieJarContainerTest so it's not just testing a mock.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66898956
fbshipit-source-id: 5ccc652b86e5a80b81d257d3ec645d7bc813301b
Summary:
When building a react native app from Xcode and ccache has been set to be used, the `ccache-clang.sh` and `ccache-clang++.sh` scripts cannot find `ccache`, because Xcode PATH does not include ccache binary.
What I've done is setting a `CCACHE_BINARY` user-defined Xcode setting containing the result of executing `command -v ccache` during pod install execution and directly calling it in ccache scripts, set by ReactNativePodsUtils when ccache is enabled.
Fixes https://github.com/facebook/react-native/issues/46126
## Changelog:
[IOS] [FIXED] - fix ccache not found error exporting ccache binary path as Xcode user-defined setting to be used by ccache scripts
Pull Request resolved: https://github.com/facebook/react-native/pull/48257
Test Plan: Correctly builds helloworld and RNTester apps using ccache by enabling it at pod install time: `USE_CCACHE=1 pod install`.
Reviewed By: christophpurrer
Differential Revision: D67280700
Pulled By: cipolleschi
fbshipit-source-id: 5478a191f9bd77606a56ccd340fea225ab62d4bc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48291
Changelog: [internal]
`react-native-fantom` was added to `.eslintignore` when we upgraded to React 19 because we wanted to reduce the amount of warnings to ease the migration.
This re-enables ESLint for that directory and removes the warnings.
Reviewed By: cipolleschi
Differential Revision: D67283104
fbshipit-source-id: 4ec2363ceaff3cd7bd6e5d70e9588c3dd22d7d85
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48263
Changelog: [internal]
Customize log level in Fantom based on flag in runner.js.
Reviewed By: javache
Differential Revision: D67199970
fbshipit-source-id: 31cdd2eaeee8e7ab4c8985661b35822d78d0457b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48262
Changelog: [internal]
At the moment, we can't start surfaces in Fabric without calling `AppRegistry.runApplication`.
This is completely unnecessary in cases like Fantom, where the creation of the surface is done manually from JS and we render to it immediately after (so we don't need to call into JS again to run AppRegistry).
Reviewed By: javache
Differential Revision: D67199971
fbshipit-source-id: e6402686b6f544a4a7651f6a21a57891ca6be3d1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48268
No need to store and compare strings here when a simple boolean will do.
Changelog: [Internal]
Reviewed By: NickGerleman, mdvacca
Differential Revision: D67204387
fbshipit-source-id: c78cc758797980c2bce11875e0f6ea1961058f05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48267
`parentShadowView.tag` was renamed to `parentTag` in D66656411. This one callsite is hidden behind an `#ifdef`, so it didn't produce a compile error.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D67203413
fbshipit-source-id: 8c1b1af616165b9a80bd38ab4d7376cb2f27cce5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48284
Changelog: [internal]
We recently prevented tasks that run via `runTask` to synchronously call `runTask` because the execution is synchronous and we can't nest tasks in the event loop (D67107664 / https://github.com/facebook/react-native/pull/48235).
This adds `scheduleTask` to schedule tasks (also within tasks) with the right expectations (the task will not run synchronously on that call but at the right time).
It also adds `runWorkLoop` so we can run scheduled tasks if they're not scheduled from an already running task.
Reviewed By: javache
Differential Revision: D67275518
fbshipit-source-id: acde0093802fbcb7083334f2c0247b37b759a6b1
Thomas Nardone
Pieter De Baets
Mateo Guzmán
zhongwuzw
kirillzyusko
Matin Zadeh Dolatabad
Pieter De Baets
Sam Zhou
Richard Barnes
Zeya Peng
Saad Najmi
Oskar Kwaśniewski
Eli White
generatedunixname499836121
Alex Hunt
Mitya Kononchuk
Dmitry Rykun
Riccardo Cipolleschi
David Vacca
Ruslan Lesiutin
Stefano Formicola
Rubén Norte