Summary: Backing out the stack since a same crash that previously effected many apps appeared again, and there are changes soon landing that will add more conflicts.
Reviewed By: Abbondanzo
Differential Revision: D63493331
fbshipit-source-id: 44658ffc99eb4ebc947f95bb6e6bde105ac88c93
Summary: Backing out the stack since a same crash that previously effected many apps appeared again, and there are changes soon landing that will add more conflicts.
Reviewed By: Abbondanzo
Differential Revision: D63493334
fbshipit-source-id: 175fc7b5b69aa2874c867e460ab102bb077a7cd8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46668
Small tweaks post-Kotlin-conversion:
- Make `overflow` a var
- Replace `+ -` with `-`
- Clean up properties and move up init block
- Iterate over entire allChildren array to clean up listeners
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63343964
fbshipit-source-id: 2e9022e2d7e54ac338d1003419d8959771f7f270
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46676
Changelog: [internal]
## Context
We recently "fixed" a problem in `MountingCoordinator` on Android where it would report that it doesn't have any pending transactions when, in fact, it does. The fix introduces a new method in that class to delay marking transactions as done until a mount hook is invoked for that surface.
That fixed the issue... by always reporting that there were pending transactions accidentally.
The reason for this bug is that the mount hook doesn't have access to the mounting coordinator of the surface if the surface is registered through some of the methods in `Binding.cpp` that don't add the surface to a registry. In that case, we can never mark the transactions as done and the mounting coordinator for those surfaces always report pending transactions incorrectly.
NOTE: this bug only affects apps that have the `fixMountingCoordinatorReportedPendingTransactionsOnAndroid` feature flag enabled.
## Changes
This fixes the issue by making sure that surfaces are always registered in the registry and that we can access their mounting coordinators in the mount hook to report the transactions as done.
Reviewed By: rubennorte
Differential Revision: D63466672
fbshipit-source-id: a621a12cda89a3ab7331d3c6a16c6cdfa9341821
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46678
I'm investigating some issues with surface management and noticed `surfaceHandlerRegistry_` is not updated in the bridgeless path when using ReactSurfaceView.
Adding a warning to help us validate this is resolved when we do eventually fix it.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63463521
fbshipit-source-id: 38995924588f1d71b9fc517c76a6e0c572fd0699
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46674
bypass-github-export-checks
React DevTools no longer operates with just Fibers, it now builds its
own Shadow Tree, which represents the tree on the Host (Fabric on
Native, DOM on Web).
We have to keep track of public instances for a select-to-inspect
feature. We've recently changed this logic in
https://github.com/facebook/react/pull/30831, and looks like we've been
incorrectly getting a public instance for Fabric case.
Not only this, turns out that all `getInspectorData...` APIs are
returning Fibers, and not public instances. I have to expose it, so that
React DevTools can correctly identify the element, which was selected.
Changes for React Native are in
[D63421463](https://www.internalfb.com/diff/D63421463)
DiffTrain build for commit https://github.com/facebook/react/commit/d66fa02a303fc53d901bdb0d7bbdaec3e6774b19.
Test Plan: Sandcastle tests
Reviewed By: poteto
Differential Revision: D63453667
Pulled By: hoxyq
fbshipit-source-id: 21b1d5d4cd68b42748d4a785e0f28eaf5db57f21
Summary:
Changelog: [internal]
(this functionality hasn't been enabled in OSS yet, so no changelog necessary).
Fix https://github.com/facebook/react-native/issues/45122.
performance.mark is currently O(1) but performance.clearMark is O(n) (being n the number of entries in the buffer), which makes this operation very slow.
### Changes overview
- Created new `PerformanceEntryBuffer` abstraction with the following subtypes, that differ on how entries are stored:
- `PerformanceEntryCircularBuffer` - stores them in a ring buffer that was already implemented, removed key lookup cache (`BoundedConsumableBuffer`)
- `PerformanceEntryKeyedBuffer` - stores them in a `unordered_map`, allowing for faster retrieval by type
- `PerformanceEntryLinearBuffer` - a simple infinite buffer based on `std::vector`, currently used in a `PerformanceObserver`
- Created `PerformanceObserver` abstraction on native side.
- Created `PerformanceObserverRegistry` that collects active observers and forwards entries to observers that should retrieve them
- Moved some method implementations to `.cpp` files to reduce potential compilation time slowdown. As the `PerformanceEntryReporter` can be included from anywhere in the code, it will be beneficial to make header files as light as possible.
- Add comments to methods that note which standard is the method from/for.
- Added some `[[nodiscard]]` attributes
- Since the logic of routing entries to observers is moved to native side, JS side of the code got much simplified
- If ever needed, `PerformanceObserver` can be created from native-side
Standards covered:
- https://www.w3.org/TR/performance-timeline
- https://www.w3.org/TR/event-timing/
- https://w3c.github.io/timing-entrytypes-registry
- https://w3c.github.io/user-timing/
Pull Request resolved: https://github.com/facebook/react-native/pull/45206
Test Plan:
I've tested this e2e on IGVR and in the RNTester playground for the performance APIs. Everything works as expected.
There are also new unit tests for this.
C++ test results: https://www.internalfb.com/intern/testinfra/testconsole/testrun/8725724513169247/
Reviewed By: rshest
Differential Revision: D63101520
Pulled By: rubennorte
fbshipit-source-id: 5970b5c14692ff33ffda44a9f09067f6a758bdbe
Summary:
While developing my project with New Architecture enabled I've found out that properties `tintColor` and `progressViewOffset` of component `RefreshControl` don't apply on iOS. This happens due to the lack of handling of these properties in the `RCTPullToRefreshViewComponentView.mm` class.
The bug can be easily reproduced in RNTester app on RefreshControlExample.js screen, since it has property `tintColor="#ff0000"` (Red color), but RefreshControl renders with gray color:
<img width="300" alt="RefreshControlExample.js" src="https://github.com/user-attachments/assets/10931204-dbe8-4cbd-9adc-d0f38319febd">
<img width="300" alt="gray Refresh Control" src="https://github.com/user-attachments/assets/e5d088e8-b3f5-46b8-9284-9b452232ad10">
<br />
<br />
This PR is opened to fix that by applying `tintColor` and `progressViewOffset` props to `_refreshControl` in `RCTPullToRefreshViewComponentView.mm` class.
Fixes https://github.com/facebook/react-native/pull/46628
## Changelog:
[IOS][FIXED] - Fix applying of tintColor and progressViewOffset props for RefreshControl component with New Architecture enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/46628
Test Plan:
1. Run rn-tester app with New Architecture enabled on iOS
2. Open screen of RefreshControl component:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 48 49" src="https://github.com/user-attachments/assets/94a2d02d-f3e3-4e18-a345-87c22d4a2620">
3. Open `/packages/rn-tester/js/examples/RefreshControl/RefreshControlExample.js` file and change properties `tintColor` and `progressViewOffset` of RefreshControl components on the line 85:
<img width="300" alt="Снимок экрана 2024-09-24 в 22 01 19" src="https://github.com/user-attachments/assets/425826a6-d34c-4316-8484-e65f125a8b28">
4. check that your changes applied:
<img width="300" alt="Снимок экрана 2024-09-24 в 19 54 46" src="https://github.com/user-attachments/assets/b97621f1-b553-48c9-bc81-e04a99a7e099">
Reviewed By: cortinico
Differential Revision: D63381050
Pulled By: cipolleschi
fbshipit-source-id: 4f3aed8bd7a1e42ce2a75aa19740fd8be1623c86
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46620
The following error was thrown when the test `packages/metro/src/integration_tests/__tests__/server-test.js` was running on Metro:
{F1816961963}
It led me to investigate why don't we wait for Metro to be torn down.
Currently we close metro by closing the http server that it launches.
```
const httpServer = await Metro.runServer(/* ... */);
httpServer.close(callback);
```
While we can listen to the callback fired when the server is closed, it only covers one of the systems running internally in metro. The systems that are not covered are:
* File watchers
* File map workers
* Dependency graph
* Bundler
And many systems that were themselves listening to the above like "eslint file map" or the "dependency analysis".
**These systems are closed by us _after_ the server is closed.** This means that a listener to `server.on('close'` would only get the indication where these systems has started to close rather than actually got closed.
https://www.internalfb.com/code/fbsource/[17e03bc6bd86]/xplat/js/tools/metro/packages/metro/src/index.flow.js?lines=359-361
This diff introduces a way to wait for all of metro to be closed.
In this diff I use that new way of listening to Metro closure to get rid of the jest test warning mentioned above in `packages/metro/src/integration_tests/__tests__/server-test.js`:
```
let serverClosedPromise;
beforeEach(async () => {
config = await Metro.loadConfig({
config: require.resolve('../metro.config.js'),
});
let onCloseResolve;
serverClosedPromise = new Promise(resolve => (onCloseResolve = resolve));
httpServer = await Metro.runServer(config, {
reporter: {update() {}},
onClose: () => {
onCloseResolve();
},
});
});
afterEach(async () => {
httpServer.close();
await serverClosedPromise;
});
```
Changelog: [Feature] add `onClose` to `Metro.runServer` configuration allowing to wait for metro and all associated processes to be closed.
Reviewed By: huntie
Differential Revision: D61594124
fbshipit-source-id: e3c50ef986077503bce0caa42a9f9430efc65272
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46632
Changelog: [General][Added] Add Playground to RNTester for testing out features & submitting reproducers.
**Context**
- Adding the Playground from Catalyst to RNTester
- This should help folks test React Native features for a particular version
**Change**
- Add a new playground component to RNTester
- Add a new reducer action for opening an example from navbar press
- Fixed typing issues
- Add icon from this fb asset pack: https://www.internalfb.com/assets/set/facebook_icons/nucleus-beaker/variant_outline-size_24?q=beaker
- Matched background color using this imagemagick script
**dark**
```
convert input.png -fill 'rgb(178,180,186)' -colorize 100% output.png
```
**light**
```
convert input.png -fill 'rgb(81,82,84)' -colorize 100% output.png
```
Reviewed By: NickGerleman
Differential Revision: D61972594
fbshipit-source-id: 4a5523a84a6ef09d3266d5f56825907bd3fbe4b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46638
This is annoying, but in the next diff that fixes a bug I need to test using the default warning filter instead of a mock (really, all this mocking is terrible, idk why I did it this way).
Unfortunately, in Jest you can't just reset mocks from `jest.mock`, `restoreMocks` only resets spies and not mocks (wild right).
So in this diff I converted all the `jest.mock` calls to `jest.spyOn`. I also corrected some of the mocks that require `monitorEvent: 'warning',` like the warning filter sets.
I also added a test that works without the fix.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349615
fbshipit-source-id: 4f2a5a8800c8fe1a10e3613d3c2d0ed02fca773e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46636
Adds more integration tests for LogBox (currently incorrect, but fixed in a later diff).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349614
fbshipit-source-id: 8f5c6545b48a1ed18aea08d4ecbecd7a6b9fa05a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46639
These tests were skipped when we were switching to component stacks, which also hid a bug later in the stack. Re-enable them.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D63349616
fbshipit-source-id: ccde7d5bb3fcd9a27adf4af2068a160f02f7432a
Summary:
X-link: https://github.com/facebook/yoga/pull/1701
Pull Request resolved: https://github.com/facebook/react-native/pull/46630
I would like to write some tests for box sizing that will drive a lot of my development as I implement content box. To do that, I need this publicly exposed. Obviously not that ideal since this currently does not do anything. Maybe we can name the value in such a way that its clear it is in development?
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63135970
fbshipit-source-id: 7520823bf925364eae45341531e012e80ec92284
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46629
If we clipped and had no border or corner radius we would end up hitting this path every time. We can optimize this a bit to avoid that.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63299597
fbshipit-source-id: 90031f964b7669049a4a2efe00a553c888d28cd7
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
