Summary:
Platforms like visionOS require explicit framework dependencies to be set in pods to build properly. For some reason linking on visionOS is more strict than on iOS but this might change in some future OS versions so it's good to have pods having exact dependencies.
I've discussed that earlier with Saadnajmi and cipolleschi. Let me know if you are okay with this change.
## Changelog:
[IOS] [FIXED] - set proper framework dependencies for built-in pods
Pull Request resolved: https://github.com/facebook/react-native/pull/45104
Test Plan: CI Green
Reviewed By: dmytrorykun
Differential Revision: D58943593
Pulled By: cipolleschi
fbshipit-source-id: 3d2df4f3bbdf36704e09f5e39bfb838b2e0f3c99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45111
Spent time debugging this issue today:
https://fb.workplace.com/groups/1700234700326965/posts/2197109080639522
The problem is described here:
https://perfetto.dev/docs/concepts/buffers
But basically we're writing too much data, too fast and the traced process can't read it fast enough. Perfetto is doing data drop.
This diff tries to use the `kStall` mode. It doesn't seem to do much but I'll leave it in for now because it shouldn't hurt too much. It's designed for our use case.
The main fix comes from increasing the buffer size to 20MB. Since it's not on by default I think it's fine to have a really large buffer for now to unblock tracing.
Reviewed By: javache
Differential Revision: D58832598
fbshipit-source-id: 101b364e2e9e28aa6a041ded1df82d5fec1f42e1
Summary:
This PR changes the call from `RCTSharedApplication()` to retrieve the status bar size using the `RCTUIStatusBarManager()` method, a way which supports multi-window apps.
## Changelog:
[IOS] [FIXED] - Retrieve status bar size using RCTUIStatusBarManager
Pull Request resolved: https://github.com/facebook/react-native/pull/45103
Test Plan: Check if the perf menu pops up in the correct spot.
Reviewed By: javache
Differential Revision: D58868503
Pulled By: cipolleschi
fbshipit-source-id: db5fc80a712a8a18a2863cdfbbe44f48bafe9fc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45091
Changelog: [internal]
We're currently logging when we execute timers in Systrace/Perfetto, but we have no information about them whatsoever.
This adds some additional information:
* What kind of timer it is
* It's ID
* And most importantly, when it was created (including the ID as well).
This allows us to know where was a specific timer scheduled and with what API.
Reviewed By: bgirard
Differential Revision: D58832112
fbshipit-source-id: 1bc11759b6c8296acf63ff3533ca1dc3428360a7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45090
Changelog: [internal]
The definition of these methods is redundant when using microtasks, so it's better to avoid defining them in the first place (to also detect issues if the setup is not what we expect).
Reviewed By: sammy-SC
Differential Revision: D58816582
fbshipit-source-id: dd1b07f8b11069605e3184b1272a9bbc3b44ca75
Summary:
After upgrading my project to the latest version of react native i.e, 0.74.2, i was getting an error when running `pod install` an the error was coming from the post install hook. Going deeper into the file tree, i found that some of the things are Nil and react native is trying to use some methods on them, so fixed those issues by using chaining operators to conditionally apply the path method on them.
## Changelog:
[Internal] - fixes the post install issue when running pod install with react native version, 0.74.2
Pull Request resolved: https://github.com/facebook/react-native/pull/45095
Test Plan: Manually tested the fix. Works perfectly fine in both debug and production mode.
Reviewed By: cortinico
Differential Revision: D58863666
Pulled By: cipolleschi
fbshipit-source-id: 64459711dcf926b7544b99b542e9861c1c0f05ca
Summary:
This PR uses a suggested solution from here: https://github.com/facebook/react-native/issues/42698 to allow users to use Cocoapods 1.15.2 which fixed issues regarding RN builds.
## Changelog:
[IOS] [FIXED] - Bump cocoapods version to 1.15.2 excluding 1.15.0, 1.15.1
Pull Request resolved: https://github.com/facebook/react-native/pull/45099
Test Plan: CI Green
Reviewed By: blakef
Differential Revision: D58863685
Pulled By: cipolleschi
fbshipit-source-id: 0128eb0cbf83e4a3d35addbae4c31e349775688c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45101
This test broke after I merged
https://github.com/facebook/react-native/pull/34785
yesterday.
Just fixing it in a similar way as the test above.
Changelog:
[Internal] [Changed] - Fix broken unableToAddHandledRootView
Reviewed By: rubennorte, blakef
Differential Revision: D58864166
fbshipit-source-id: 4f48dbfd5238a2811564ce02199af7fc284d39b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44832
I'm renaming this folder as now we have 2 gradle plugins + we currently have
`package/react-native-gradle-plugin/react-native-gradle-plugin/` which is confusing so we can just call this folder `packages/gradle-plugin/`
to be consistent with the NPM package name
Changelog:
[Internal] [Changed] - packages/react-native-gradle-plugin/ -> packages/gradle-plugin/
Reviewed By: blakef
Differential Revision: D58284883
fbshipit-source-id: 5a7bb40a5d80f6fbab4ffb29e44107453f1013ec
Summary:
Follow the same solution (do not throw a crash when view ID is set already) used in `ReactAndroid/src/main/java/com/facebook/react/ReactRootView.java` for `ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.java`
## Changelog
[Android] [Changed] - Log a SoftException on SurfaceMountingManager.addRootView
Pull Request resolved: https://github.com/facebook/react-native/pull/34785
Test Plan: None
Reviewed By: cipolleschi
Differential Revision: D40022263
Pulled By: cortinico
fbshipit-source-id: d565d2831e2833ccea55f28ea16083b7bae0ed32
Summary:
Adds an overload for `createLayout` method that also handles extracting paragraph attributes and scaling font size if necessary.
## Changelog:
[ANDROID] [CHANGED] - Extracted common parts related to calculating text layout to a helper
Pull Request resolved: https://github.com/facebook/react-native/pull/45083
Test Plan: Tried out on RNTester
Reviewed By: robhogan
Differential Revision: D58818560
Pulled By: cortinico
fbshipit-source-id: a42b5de04c4a70edb88cdd734387d7e4cee94032
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45076
> **start**: The same as left if direction is left-to-right and right if direction is right-to-left.
This is equivalent to `auto`, which is not actually a valid CSS value.
Changelog: [General][Added] Add support for `texAlignment: 'start'`
Reviewed By: sammy-SC
Differential Revision: D58791937
fbshipit-source-id: 09622d814212a7055f94b1f091c71edae5db117c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45060
Currently, `j`, (i.e., `/open-debugger` with no parameters), connects the "first available" target, which in practice is the first page of the first connected device still connected.
In the absence of a target selection UI, a better guess at user intent is to use the *latest* target (most recently added page of most recently connected device).
Also slightly reduces CLI noise by not claiming that we're launching a debugger when there's no target, and not qualifying which target when there's only one.
Changelog:
[General][Changed] Debugger: `j` opens most recent (not first) target.
Reviewed By: huntie
Differential Revision: D58736151
fbshipit-source-id: 3d106a1fa958f9e5c91b16e04075609e1abf6e97
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45069
Currently, `/json/list` returns pages within each device in the iteration order of a C++ `unordered_map`, which doesn't tell us anything useful. Page IDs happen to be sequential, but only as an implementation detail.
Change this contract so that we guarantee ordering reflects addition order, allowing clients to consistently select e.g. most recently added page for a given device.
The implementation of this is as simple as switching from an `unordered_map` to a key-ordered`map`, because we already assign keys (page IDs) with an incrementing integer. Within the inspector proxy, devices already use an insertion (connection)-ordered JS `Map`, so we just document this guarantee.
Changelog:
[General][Changed] Debugger: Make `/json/list` return connection-addition-ordered targets.
Reviewed By: huntie
Differential Revision: D58735947
fbshipit-source-id: 7a132cc5e750475792a2b845afc9a42424690bf1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44840
Changelog: [Internal]
Introduce a simplified and minimal tracing backend for Fusebox. This backend is sufficient to implement a pretty usable performance panel.
Although the more I see how easy this is and how annoying working with Perfetto is, the more I think we should just maintain this going forward. Anyways we can figure that out incrementally. For now the plan is still for this to be temporary.
Reviewed By: motiz88
Differential Revision: D57981944
fbshipit-source-id: b3d8c6e8c5a18311bbe98254f8ddf3810fa1334b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45068
changelog: [internal]
In D58672844 I added gating to module.exports.
This gating is sensitive to when feature flags are initialised and causes test failures and regressions for developers. Let's move the feature flag check to component's render function. It introduces extra spread operator but it is good enough to compare new and old <Text /> component.
Reviewed By: GijsWeterings
Differential Revision: D58783941
fbshipit-source-id: f89f4f48e6aeb774ed4a84483a9f4ad59d5bc045
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45026
All callsites for these containers already explicitly synchronize using these objects, so there's no need to use a synchronized collection wrapper here.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D58724044
fbshipit-source-id: 5151ebb0ceda8656b6039d9984cc32a843051abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45025
This API just passed through the `enableArchitectureIndicator` prop to a custom WrapperComponent, as there is no default consumer of it. Instead, each provider of a custom WrapperComponent can capture the required value of itself.
Changelog: [General][Removed] Removed enableArchitectureIndicator API which is only used internally.
Reviewed By: cortinico
Differential Revision: D58723922
fbshipit-source-id: 0c52a904424382f33caab92ac50b316ae161f877
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45059
Changelog: [internal]
By moving the command to a code block it's going to be easier to see it when quickly reading the README.
Reviewed By: cortinico
Differential Revision: D58779883
fbshipit-source-id: e912a58641245c6d7dc158f7af0a722e438a0cc3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D58705515
fbshipit-source-id: 74e9a68fc0e3d1e88b8eebbb34a1ca8c29052c21
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45035
Changelog: [General][Fixed] Avoid a zombie state when opening a second debugger frontend concurrently.
The problem here was that we were sending proxy-protocol messages to the device in the wrong order (`disconnect` *after* `connect`):
{F1701266597}
The root cause was that we were depending on the outgoing debugger socket's async `close` event to trigger sending the `disconnect` message to the device. This would happen after we'd already (synchronously) sent the `connect` message.
With this diff, we send the `disconnect` message synchronously with calling `close()` on the debugger socket, which fixes the ordering problem at the source. To avoid sending duplicate `disconnect` messages (e.g. one before calling `close()` and one from the `close` event handler), we store some extra state on `Device` (`#connectedPageIds`).
Reviewed By: robhogan, huntie
Differential Revision: D58730634
fbshipit-source-id: 0f54af2e4f8071a8f6d97cc9e3d8a4ea89a46f43
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45027
Changelog: [Internal]
Changes the device ID collision handling logic to reuse `Device` instances instead of creating new ones. This enables further refactoring of `Device` to improve session state isolation.
Reviewed By: hoxyq
Differential Revision: D58724884
fbshipit-source-id: bc11ce45ce8c80c58c32dcd1b07b28f1d1753a62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45032
Those tests haven't been running since ~1 year now.
I know it's not ideal but I'd rather remove them instead of keeping them around not executing.
We can still revert them back from the history once we decide to revive the E2E testing effort.
Changelog:
[Internal] [Changed] - Remove unused rn-tester e2e tests
Reviewed By: cipolleschi
Differential Revision: D58729123
fbshipit-source-id: f0f47e3c2e087141fdff506b7c5c9b460263721b
Summary:
Fixes https://github.com/facebook/react-native/issues/41988
Hopefully even if this isn't the right way to go about solving this, it at least points in the right direction for a different fix!
Currently - both on Paper and Fabric - the `selectTextOnFocus` prop does not work as expected on a single line text input. It seems that if the `UITextField` has not yet become the first responder, the text will be briefly selected but then deselected immediately afterward.
This can be seen in the tester when running for either Fabric or Paper (video using Fabric)
https://github.com/facebook/react-native/assets/153161762/aa9c609e-6eb8-4177-a41f-32aae53c06ac
Instead, we can move the `selectAll` call to `reactFocus` in `RCTBaseTextInputView` or `focus` `RCTTextInputComponentView` - both of which first call `becomeFirstResponder` - to get the expected result.
## Changelog:
[IOS] [FIXED] - fix selectTextOnFocus in Fabric and non-Fabric by calling selectAll after becomeFirstResponder
Pull Request resolved: https://github.com/facebook/react-native/pull/44307
Test Plan:
* Test changes on RN Tester (iOS)
https://pxl.cl/55kDc
Reviewed By: cipolleschi
Differential Revision: D56699773
Pulled By: fabriziocucci
fbshipit-source-id: ed092835f3c602e2c50a4198357653a9cef942d9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45013
Changelog: [internal]
## Context
We recently realized that in the majority of events dispatched to React from Fabric, passive effects were being mounted synchronously, blocking paint instead of in a separate task after paint.
The reason for that is that in React, passive effects for discrete events are mounted synchronously by design (see https://github.com/reactwg/react-18/discussions/128), and Fabric is currently assigning the discrete event priority to most current events (including things like layout events).
## Changes
This creates a feature flag to opt into a more granular control over event priorities in React Native. Instead of assigning the discrete event priority to events by default, this would assign the "default" event priority by default, except for events dispatched during continuous events that would also be considered continuous.
This would also fix the priority for continuous events, that it was currently being assigned as "default" incorrectly.
Reviewed By: christophpurrer, javache, sammy-SC
Differential Revision: D58677191
fbshipit-source-id: c65a8dc2118ed028e1e895adec54f9072b7e55a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45011
Changelog: [Internal]
Fixes an inspector-proxy test case that was (silently) incorrect. This is in preparation for an upcoming rewrite of the core of inspector-proxy to more strictly isolate session state, which causes the incorrect test to fail.
Reviewed By: hoxyq
Differential Revision: D58193527
fbshipit-source-id: bdc27179210117ca9249b272f2e4aff19ba8a06c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44962
Add a short term fork of `Text` for the purpose of performance testing.
Specific differences from `Text`:
- Lazy init Pressability via a nested component.
- Skip children context wrapper when safe.
- Move props destructuring to function param.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D58601810
fbshipit-source-id: 988bac6100287705fb1bf8dc48cb2cfae56343df
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44964
Testing property priority and correct setting percentages for business logic of `BorderRadiusStyle.kt`
To prevent issues like the one fixed by D57473482
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D58602799
fbshipit-source-id: 605bc384267d9f4ae5a051e76c1a4d862fe54039
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44884
Removing JavaScript error handler supplied to ReactHostImpl.java which is just a stub and creating a default handler in ReactInstance.java which uses NativeExceptionHandler TurboModule to handle error.
Changelog: [Android][BREAKING] Removing `ReactJsExceptionHandler` param from ReactHostImpl() constructor and providing a default private implementation
Reviewed By: javache, cortinico
Differential Revision: D58385767
fbshipit-source-id: 46548677df936b7c2f584084a2c9769c27e6a963
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45010
D46482492 added logic for handing off state across "device" connections that have the same ID. This logic currently has no test coverage. It also contains a bug whereby the new device's pages are removed from the target listing endpoint (`/json`) when the *old* device's socket is closed.
This diff adds tests and fixes the bug.
Changelog: [General][Fixed] inspector-proxy no longer accidentally detaches connected devices.
## Next steps
It seems that the device ID handoff logic exists to paper over a deeper problem with the inspector proxy protocol (or its implementation in React Native): The React Native runtime should not routinely be creating new "device" connections without tearing down previous ones.
In followup diffs, I'll explore changing this behaviour for Fusebox, based on the new test coverage.
Reviewed By: robhogan
Differential Revision: D51013056
fbshipit-source-id: e0c17678cc747366a3b75cef18ca2a722fc93acd
Summary:
Qhile landing the changes for React19 in 0.75, we missed one test that needs to be updated
## Changelog:
[Internal] - Fix Jest tests in React 19
Pull Request resolved: https://github.com/facebook/react-native/pull/45007
Test Plan: CircleCI is green
Reviewed By: robhogan
Differential Revision: D58671824
Pulled By: cipolleschi
fbshipit-source-id: 48a72f5cdc4d03201cb1778915ed3519759cf017
Summary:
After updating my project to 0.73.2 I noticed that even though I had a specific port set in my `metro.config.js`, every time I'd start my project, it was running on port 8081. Passing the `--port` argument would allow me to change the port, but the config from metro did not. I checked if the metro config was being properly applied, using `--verbose` and it was.
So I dug a bit, trying to figure out what had changed and noticed the coalescing of the value, whenever the argument `--port` is not present. That seemed odd since it meant that there's always a port defined for the `options` of `loadMetroConfig`, which would always be used in the `loadConfig` step.
To confirm I was on the right track I went to the [cli-plugin-metro](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro) repo, to the last release before the move here, and noticed that there was [no coalescing in the same method](https://github.com/react-native-community/cli/blob/v11.3.10/packages/cli-plugin-metro/src/commands/start/runServer.ts#L60).
In this PR, I remove the coalescing of the port from `runServer.js` from the `community-cli-plugin`, to allow the port configuration through `metro.config.js`.
## Changelog:
[INTERNAL] [FIXED] - Fix server port configuration via `metro.config.js`
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/44957
Test Plan:
Running `yarn start` and verifying that:
- it would listen to port `8081` if no argument nor a custom port was set in `metro.config.js`
- it would listen to port `8082` if that one was defined in `metro.config.js`
- it would listend to port `8083` if that port was passed as an argument to the command (i.e. `yarn start --port 8083` even though port 8082 was defined in `metro.config.js`
Reviewed By: cortinico
Differential Revision: D58605152
Pulled By: robhogan
fbshipit-source-id: 9cf7a8b6a0d9de3af1ca4092906b4c648acee373
Summary:
Implements `requestIdleCallback` and `cancelIdleCallback`
### Notes
Proposed implementation does yet cover all WHATWG eventloop requirements.
- Deadline computation is not implemented and is polyfilled by giving each callback `50ms`, rather than it being shared between other idle callbacks.
- The requested callbacks are called with lowest priority by the scheduler as of now, but the execution is not as described in the standard.
## Changelog:
- [GENERAL] [ADDED] - Implemented `requestIdleCallback` and `cancelIdleCallback`
Pull Request resolved: https://github.com/facebook/react-native/pull/44759
Reviewed By: javache, sammy-SC
Differential Revision: D58415077
Pulled By: rubennorte
fbshipit-source-id: 46189d4e3ca1d353fa6059a904d677c28c61b604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44991
Updates the open source renderers for React 19. This is in preparation for React Native 0.75.
Notable, this incorporates the feature flag changes from [facebook/react#29903](https://github.com/facebook/react/pull/29903).
Changelog:
[General][Changed] - Upgrade Renderers for React 19
Reviewed By: robhogan
Differential Revision: D58632199
fbshipit-source-id: 674bb47554e4b0c6ab5127fb9683ed8284b7a4ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44990
Upgrades React Native and Relay to depend on React 19, which is currently published as release candidates. This is in preparation for React Native 0.75.
This will depend on updating open source renderers after [facebook/react#29903](https://github.com/facebook/react/pull/29903) is merged.
Changelog:
[General][Changed] - Upgrade to React 19
Reviewed By: robhogan
Differential Revision: D58625271
fbshipit-source-id: f9ad95b18716a9ce02f7cfbcc7248bdfb244c010
Oskar Kwaśniewski
Benoit Girard
Rubén Norte
Irfanwani
Nicola Corti
psionic12
Blake Friedman
Jakub Piasecki
Alan Lee
Pieter De Baets
Edmond Chui
Rob Hogan
Samuel Susla
Jorge Cabiedes Acosta
Moti Zilberman
Hailey
Josh Katz
Blake Friedman
Pieter Vanderwerff
Riccardo Cipolleschi
Afonso
Robert Pasiński
Tim Yung