Summary:
This PR fixes the retrieval of react native package name to retrieve it from package.json.
This fixes the annoying message in codegen that poped up when installing pods:
```
[Codegen] Found react-native-macos
[Codegen] CodegenConfig Deprecated Setup for react-native-macos.
The configuration file still contains the codegen in the libraries array.
If possible, replace it with a single object.
BEFORE:
{
// ...
"codegenConfig": {
"libraries": [
{
"name": "libName1",
"type": "all|components|modules",
"jsSrcsRoot": "libName1/js"
},
{
"name": "libName2",
"type": "all|components|modules",
"jsSrcsRoot": "libName2/src"
}
]
}
}
AFTER:
{
"codegenConfig": {
"name": "libraries",
"type": "all",
"jsSrcsRoot": "."
}
}
```
## Changelog:
[GENERAL] [CHANGED] - get react-native package name from package.json in codegen script
Pull Request resolved: https://github.com/facebook/react-native/pull/46604
Test Plan: Install pods
Reviewed By: cortinico
Differential Revision: D63335543
Pulled By: arushikesarwani94
fbshipit-source-id: 0470e54f0fc7aa962918c889855c52648d11e32d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46634
The PointerEventPointerOverOut.js test case is broken due to a changed assumption about the name of the native tag property (`_nativeTag` vs. `__nativeTag`). This fixes the broken assumption.
## Changelog
[General][Fixed] Fixed issue with W3C PointerEvents tests
Reviewed By: NickGerleman
Differential Revision: D63336621
fbshipit-source-id: b54270f1c1232de6845ef73cac52f06b9a85539c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46617
This changes fixes the Increment/Decrement accessibility actions on iOS with the New Architecture.
## Changelog
[iOS][Fixed] - Make sure that the Increment and Decrement accessibility actions works on iOS
Reviewed By: javache
Differential Revision: D63263830
fbshipit-source-id: 99dca14a002e098db2d3b0e268af32cdab6ce786
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46603
Was debugging this test for the mounting instruction changes, and found some opportunities to clean this up.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63258342
fbshipit-source-id: f7e6be58474f112993232ce5859ccb160f050ae8
Summary:
A typo means TextLayoutManager will incorrectly measure text as if `LineBreaker.HYPHENATION_FREQUENCY_NORMAL` is set, instead of the correct default of `LineBreaker.HYPHENATION_FREQUENCY_NONE` which we use to display the `TextView`. This causes truncation if hyphenation would have caused text to be shorter than if not hyphenated. Fix the typo.
Changelog: [Android][Fixed] - Fix measuring text with incorrect hyphenationFrequency
Reviewed By: mellyeliu
Differential Revision: D63293027
fbshipit-source-id: baaf2ae2676548cf0815ae96e324af273be6f99e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46586
When Paint.strokeWidth is set to 0 its not actually 0 but "hairline mode" so the fix is just to make outline not draw at all when outlineWidth = 0 {F1879399325}
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D63136220
fbshipit-source-id: 81ef7ce0b72158c6b7c332191d332008c5a919b4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46598
Changelog: [General][Changed] - Bring back shouldSkipStateUpdatesForLoopingAnimations feature flag
Facebook
Also bring back `skip_state_updates_for_looping_animations` MC. This will allow the experiment to participate in a holdout properly.
Reviewed By: GijsWeterings
Differential Revision: D63252185
fbshipit-source-id: 89bc9321b12f07bd9b3b52c4fc1021d34594ebc0
Summary:
On iPadOS, users can change the kind of keyboard displayed onscreen, going from normal keyboard, to split keyboard (one half on the left of the screen, one half on the right), or a floating keyboard that you can move around the screen.
When a non-normal kind of keyboard is used, `<KeyboardAvoidingView>` calculations are all wrong and, depending on the `behavior` prop, can make your screen completely hidden.
This PR attempts to detect that the keyboard is not the "normal displayed-at-bottom-of-screen" keyboard, and forces `enable={false}` if this happens.
The approach of comparing the keyboard width with the window width comes from this comment: https://github.com/facebook/react-native/issues/29473#issuecomment-696658937
A better fix might be to detect the kind of keyboard used, but this involves native code changes and I do not know iOS enough to do that. In addition, I have not found an easy way to do it using iOS APIs after a quick search.
I also chose to cache the window width as a class attribute. Maybe this is not needed as `Dimensions.get('window').width` is very fast and can be called on every keyboard event?
This fixes https://github.com/facebook/react-native/issues/44068 and https://github.com/facebook/react-native/issues/29473
## Changelog:
[IOS] [FIXED] - Fix `<KeyboardAvoidingView>` with floating keyboard on iPadOS
Pull Request resolved: https://github.com/facebook/react-native/pull/44859
Test Plan:
Tested using RNTester and the "Keyboard Avoiding View with different behaviors" example.
Before:
https://github.com/facebook/react-native/assets/42070/111598a3-286c-464d-8db8-73afb35cd7f9
After:
https://github.com/facebook/react-native/assets/42070/0b3bc94f-8b67-4f42-8a83-e11555080268
Reviewed By: cortinico
Differential Revision: D62844854
Pulled By: cipolleschi
fbshipit-source-id: 577444be50019572955a013969d78178914b5b8d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46590
This API should not be part of the ShadowView header, since the class is only used by Differentiator. The ShadowView header should contain public API's that the mounting layer can consume.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63148522
fbshipit-source-id: 0545777fd311424ccd2d66de8b47b5591e8175f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46589
This is a useful too for debugging ShadowTree mutations, but was broken due to some recent build changes.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63099720
fbshipit-source-id: 9ae5ee062ef9a6a99b2517e4eedd286cd6259fbe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46597
Changelog: [internal]
Adding explicit metadata to feature flags so they're easier to manage:
* Purpose: to indicate why the feature flags are added.
* Release: gating features we don't want to expose in certain environments yet (e.g.: Fabric).
* Experimentation: changes that we want to test before enabling them broadly. Should generally be short lived.
* Operational: flags that enable certain behaviors in certain environments (e.g.: debugging logs).
* Date added: only for experimental flags, so we know how long we've been waiting to fully roll out the change (without having to go through the repository history, which could've been changed due to refactors).
Reviewed By: javache
Differential Revision: D62972237
fbshipit-source-id: ab51e989a2cddb8dc52197238b638609d30002f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46567
Switch to a simpler data structure which avoids locking and doesn't require copies when iterating. This is more consistent with other listener arrays in React Native.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62872893
fbshipit-source-id: b0ce6a904d25057f0217f7de7ec2928c8b2d1f34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46542
If `bufferedRuntimeExecutor_` is referenced beyond the lifetime of the ReactInstance, it may point to invalid memory. RuntimeScheduler already holds weak references to the actual runtime, so it's safe to retain that instead.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D62748768
fbshipit-source-id: 1cd8fcb050dd561e7d54a11d91c89eda3a5ddaaa
Summary:
This PR is a quality-of-life improvement, adds colors to codegen output:
Makes it a lot easier to grasp what's going on in the actions taken by codegen.
## Changelog:
[GENERAL] [ADDED] - Add color formatting to codegen output
Pull Request resolved: https://github.com/facebook/react-native/pull/46557
Test Plan:
1. Run codegen
2. Expect colored output
Reviewed By: christophpurrer
Differential Revision: D63031248
Pulled By: cipolleschi
fbshipit-source-id: e86bc72f16582562dc9f1e3b55dc69af4c7838f5
Summary:
Add tests to simplify running Maestro e2e tests locally.
Thanks to these scripts, users can just, from the root folder:
```sh
yarn install
cd packages/rn-tester
# build android for testing
yarn e2e-build- android
# run tests on android
yarn e2e-test-android
# build iOS for testing
yarn e2e-build-ios
# run tests on iOS
yarn e2e-test-ios
```
This is a preliminary step for a future umbrella issue. We can also use these command in CI to simplify the scripts.
## Changelog:
[Internal] - add script to simplify e2e testing
Pull Request resolved: https://github.com/facebook/react-native/pull/46545
Test Plan: Tested the command locally
Reviewed By: cortinico
Differential Revision: D62879105
Pulled By: cipolleschi
fbshipit-source-id: 6f68aebb3f8112302a458ca9e118180d3dbaf180
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46576
We automatically add this handler in `addAnimatedEventToView` but we do not remove it in `removeAnimatedEventFromView`, which causes us to leak it. This is especially bad as we attach and detach the event handler multiple times while rendering.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D63029768
fbshipit-source-id: 9ef2bc6887fecb7ab448af4dee94463f8be27768
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46544
Experiments with `completeReactInstanceCreationOnBgThreadOnAndroid` have shown a native crash in this code path, but it also existed previously.
I believe this is due to the ordering of ReactInstance teardown: we first destroy the ReactInstance, and only then destroy the reference to it in mCreateReactInstanceTaskRef. When using the immediate executor and completeReactInstanceCreationOnBgThreadOnAndroid, we read the react instance from the task, which may no longer be valid at this point. Resetting the task at the earliest point should mitigate the issue.
Changelog: [Internal]
Reviewed By: markv
Differential Revision: D62872625
fbshipit-source-id: 5aaccd53433ca806d2b93f7e3dd2bcf9bf8c09a8
Summary:
This change setups homebrew on Ubuntu. Due to https://github.com/actions/runner-images/issues/6283, brew is not in the PATH anymore.
## Changelog:
[Internal] - Setup homebrew in ubuntu machine
Pull Request resolved: https://github.com/facebook/react-native/pull/46575
Test Plan: Can't test before it lands. :(
Reviewed By: cortinico
Differential Revision: D63027253
Pulled By: cipolleschi
fbshipit-source-id: e0b3a3c1a2a7b0659f0c1f57c45d8d42a74734a1
Summary:
This change configure the Test All job to enable the E2E tests with an input parameter.
Then it adds another workflow that is triggered on PRs when someone posts the "/test-e2e" comment.
## Changelog:
[Internal] - Let users run E2E tests on a specific PR comment
Pull Request resolved: https://github.com/facebook/react-native/pull/46572
Test Plan: This kind of things can only be tested once the PR lands, as workflows that are triggered by comments runs only from the main branch.
Reviewed By: cortinico
Differential Revision: D63021786
Pulled By: cipolleschi
fbshipit-source-id: 95b271f6de658ca208c773429fedef2a36417752
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46559
There is an edge case when we navigate away from a screen that contains a scroll view where one of the UISCrollViewDelegates does not implement the scrollViewDidEndDecelerating method.
This happens because the Macro used assumes that the event that we are forwarding is the actual method from where the macro is called. Which is not true when it comes to `didMoveToWindow`.
This change fixes that by explicitly expanding the macro in this scenario and passing the right selector.
## Changelog:
[iOS][Fixed] - Fixed a crash when navigating away from a screen that contains a scrollView
## Facebook
This should fix T201780472
Reviewed By: philIip
Differential Revision: D62935876
fbshipit-source-id: e29aadf201c8066b5d3b7b0ada21fa8d763e9af0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46560
The `init` command should still keep on working till 2024-12-31
This handles this scenario as currently `npx react-native@next init` is broken.
Changelog:
[Internal] [Changed] - Clarify init behavior for 0.76
Reviewed By: huntie, cipolleschi
Differential Revision: D62958747
fbshipit-source-id: ce3d974df55162720d59a7ece7fcb816e257185d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46540
changelog: [internal]
avoid calling `runEventLoopTick` and execute task directly. runEventLoopTick is not designed to be called on re-entries.
Reviewed By: rubennorte
Differential Revision: D62871782
fbshipit-source-id: 259514d05eebed2e09d54233729994e56f2aa1a4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46551
We crash if we pass a shadow color with 0 alpha due to some divide by 0 logic. This fixes that for inset and outset shadows and adds a test for that case.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D62899047
fbshipit-source-id: 2aff1d016dd97bed024df1c3f89bcc62e49f0306
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46563
Changelog: [internal]
Our current implementation of view preallocation on Android runs very early in the frame (during the `animation` stage, after `input` and before `traversal`). In that implementation, we check the remaining time in the frame and we allocate half of that time for view preallocation.
This logic can make us drop frames unnecessarily, if the work that we need to do after this allocated time is longer than we expect. Because we don't know how long the `traversal` stage will be, we don't account for that time at all (or, at best, we do only use half of the remaining time).
This creates a feature flag to move view preallocation outside of the choreographer, so we can compute the remaining time considering all the work we did in the frame, and not just the work we did in the input stage.
Reviewed By: javache
Differential Revision: D62962341
fbshipit-source-id: 69aaeecc8596906e61b47af9adad23c1075a091a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46565
UIManager is initialized elsewhere in NativeAnimatedNodesManager so this is no longer required
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D62958646
fbshipit-source-id: af77ddbbc65124ed29d301340ad339d2a916f58c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46564
Changelog: [internal]
I incorrectly set up an experiment to fix reported scroll position during smooth scroll animations on Android in D59233069. It was incorrect because I fixed the issue in "control", and I re-enabled the bug in "test".
That means we actually shipped the fix the moment we set up the experiment.
We can just apply the fix ungated.
Reviewed By: Abbondanzo
Differential Revision: D62965254
fbshipit-source-id: edf855619ff9ede6fd406f7f19b3c504ce89f1d6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46561
Changelog: [internal]
We have some logic in `MountItemDispatcher.tryDispatchMountItems` to recursively call itself for as long as there are new items to mount in the general queue. This queue is copied and processed every time `tryDispatchMountItems` is called, but it's possible that during this time new mount operations are added (either from JS or from the mount operations themselves).
This logic can cause frame drops, as we could be finish processing the current frame without processing new mount items (we could do that in the next frame, and in many cases it's just pre-rendering work and state updates that the user can't perceive anyway).
This creates a feature flag to test disabling this behavior and only process whatever mount items are queued at the start of the frame.
Reviewed By: sammy-SC
Differential Revision: D62958009
fbshipit-source-id: ca038c827715411375410215deb5d5e374f5fdb4
Summary:
Regarding the [issue](https://github.com/facebook/react-native/issues/44755) where the app sometimes crashes due to race condition when two reloads overlap in unfortunate way. This PR fixes it in some way by introducing throttling on reload command. For now I set it to 700ms as I was still able to reproduce it on 500-550ms for provided repro in the issue. The problem may still happen for bigger apps where reload may take more time to finish.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - throttle reload command
Pull Request resolved: https://github.com/facebook/react-native/pull/46416
Test Plan: I've tested on provided repro and a smaller app trying to brake it.
Reviewed By: huntie
Differential Revision: D62847076
Pulled By: cipolleschi
fbshipit-source-id: 6471f792d6b692e87e3e98a699443a88c6ef43cd
Summary:
This PR adds iOS ifdefs to `RCTUIManager` to subscribe to orientation changes on this platform.
The `UIDeviceOrientationDidChangeNotification` symbol is only available there.
## Changelog:
[IOS] [FIXED] - subscribe to orientation changes in RCTUIManager only on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/46531
Test Plan: CI Green
Reviewed By: philIip
Differential Revision: D62864013
Pulled By: cipolleschi
fbshipit-source-id: 341df9ac765735273378d017b63fcb7a4d8e98e5
Summary:
Analyze code was still using the CIRCLECI env variable to retrieve the PR number.
This change uses the github one and also removes a duplicated flow check
## Changelog:
[Internal] - Remove duplicated flow check and use gh PR number rather than CircleCI one
Pull Request resolved: https://github.com/facebook/react-native/pull/46548
Test Plan: Tested locally and in CI
Reviewed By: NickGerleman
Differential Revision: D62883758
Pulled By: cipolleschi
fbshipit-source-id: 0c7e97ea9caf4465972424e0b69a899ecfd07095
Summary:
This chang introduces a patch file that can be applied to run the E2E tests in CI.
From the root folder `react-native`, a user can just run:
```sh
git apply packages/rn-tester/scripts/enable-e2e-tests.patch
```
And then add a commit to their PR to see whether the newly added E2E tests are actually running
## Changelog:
[Internal] - add patch to simplify running E2E tests in CI
Pull Request resolved: https://github.com/facebook/react-native/pull/46546
Test Plan: Tested locally
Reviewed By: NickGerleman
Differential Revision: D62880559
Pulled By: cipolleschi
fbshipit-source-id: 19d639b2641aaa50e4f3e0753018d426d2da81c9
Oskar Kwaśniewski
Hailey
Eric Rozell
Pieter De Baets
Riccardo Cipolleschi
Nicola Corti
Nick Gerleman
Jorge Cabiedes Acosta
Dmitry Rykun
Renaud Chaput
Rubén Norte
Jakub Piasecki
David Vacca
Thomas Nardone
zhongwuzw
Alex Hunt
Samuel Susla
Joe Vilches
Dawid