Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48799
This change moves the same scripts we have to prepare the HelloWorld project to RNTester.
This is something we forgot to do when we were decoupling the reacrt-native from the community CLI.
This is also the base to start deprecating cocoapods and add more configuration steps for the project.
## Changelog:
[Internal] - Copy cli.js script from HelloWorld to RNTester
Reviewed By: cortinico
Differential Revision: D68413419
fbshipit-source-id: 7cf19d86bd3c1beb0c1e7f3380331174352a1651
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48787
For reasons that will become clear in the next diff, I'm adding more assertions for things like LogBox being called, and the console being called. I also updated the patterns of things like `toHaveBeenCalledWith` vs `toBeCalledWith` so they're consistent throughout the file.
## Changelog:
[internal] - Add tests to ExceptionManager
Reviewed By: hoxyq
Differential Revision: D68397529
fbshipit-source-id: b05073630969c40a86546a6f5c4244836b636ee1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48784
React requires React DevTools to be the first patch for console methods, because it assumes it is the _last_ on the stack called before calling the real console.
This is because React DevTools adds additional formatting for things like StrictMode dimming, and component stack formatting for browser specific consoles like Chrome and Firefox, where the DevTool extension runs.
If it's not the first patch, then other patches (like logging, or LogBox) will pick up the DevTools additions and include them, which breaks other tools (like the issue show in the screen below).
This diff ensures React DevTools is patched before the React Native console reporter by moving it to `setupErrorHandling`.
## Changelog:
[General] [Fixed] - Always patch React DevTools first so StrictMode dim chars are excluded from logs/logbox.
## Other places?
I'm not sure how we should handle this for the console polyfill or inside useAlwaysAvailableJSErrorHandling yet.
## Screens
### Before
3 errors, 1 with ANSI dim chars:
{F1974436874}
### After
Just 1:
{F1974436879}
Reviewed By: hoxyq
Differential Revision: D68380665
fbshipit-source-id: 4f5353bb8da0038088c05ef7414bf91e965c73e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48785
## Overview
This change adds code frames for component stacks if it differs from the call stack frame.
## Background
After adding native stack based stack frames, which we already symbolicate, we had the capability to show a code frame for component stacks as well as the stack frame (if they differ).
However, this usually wasn't that useful, because the native component stack was unlikely to be more useful than the component stack (see the comparisons below for key errors).
## Owner stacks
With owner stacks the component frame is a lot more useful and in many cases are better at showing the location than the call stack frame.
## Example Screens
Before:
{F1974436645}
After (with owner stacks):
{F1974436723}
Changelog:
[General][Added] - Add owner stack code frames to LogBox
Reviewed By: hoxyq
Differential Revision: D68285627
fbshipit-source-id: 541cecbd4786fffd1970d2e85e659757e3f81604
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48782
React currently has a babel transform to replace all `console.error` calls with a special function for RN and www. The function adds component stacks, which doesn't make sense in an owner stack world because:
- not all console.error calls are replaced, creating inconsistency
- oss web users don't append component stacks to console.log any more
- component stacks can be accessed for DEV modals like logbox with `captureOwnerStack`
- owner stacks are already added to the console with createTask if you use console.error directly
- the redirection is the single greatest source of fragility in the logbox reporting pipeline
So we're removing this as part of the owner stack rollout. This should only be enabled with owner stacks.
## Example Screen
Before:
{F1974436644}
After:
{F1974436645}
## Changelog:
[General] [Added] - Add full owner stack support to React Native
Reviewed By: hoxyq
Differential Revision: D68285628
fbshipit-source-id: 9772593d7ac6e012392d18c6796580c14c852074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48770
Splits CSSValueParserTest to be file per data type to better match new structure, before we introduce more complexity and tests for CSS colors.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68351049
fbshipit-source-id: 1a4218e49c8c8adb056fac1dd67f064a4f890775
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48769
Must function notations do not require delimiting commas, with color function "legacy" syntax being an exception.
E.g.
```
rgb() = [ <legacy-rgb-syntax> | <modern-rgb-syntax> ]
rgba() = [ <legacy-rgba-syntax> | <modern-rgba-syntax> ]
<legacy-rgb-syntax> = rgb( <percentage>#{3} , <alpha-value>? ) |
rgb( <number>#{3} , <alpha-value>? )
<legacy-rgba-syntax> = rgba( <percentage>#{3} , <alpha-value>? ) |
rgba( <number>#{3} , <alpha-value>? )
<modern-rgb-syntax> = rgb(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
<modern-rgba-syntax> = rgba(
[ <number> | <percentage> | none]{3}
[ / [<alpha-value> | none] ]? )
```
Theoretically, this should mean an expression like `rgb(1, 2 0)`, which mixes both comma and whitespace delimeters would be malformed, but both Chrome, and RN's existing `normalize-color` package support this, so to make this pattern easier, we add the ability to scan based on using either whitespace or comma as component value delimiter.
Interestingly, the current spec revision also allows `rgb` function with alpha, or `rgba` function without alpha, which Chrome correctly supports, but `normalize-color` does not.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68349385
fbshipit-source-id: 05cd756ee20227af4d9ec20edc9e7cfc8cc2c071
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48768
Right now, if something like `CSSColor` accepted a function notation block (e.g. for `rgb()` syntax), it is given a syntax parser which may extend beyond the scope of the current function block.
This is confusing, but also problematic for the `CSSSyntaxParser` block visiting logic to validate a correct scope exit.
This change makes it so that the `CSSSyntaxParser` passsed to `CSSDataTypeParser` for function and simple blocks is limited to the syntax within the given block. This prevents extra visiblity beyond the block we are trying to parse, and allows the function/simple block visitor to reliably fail parsing if the block is not correctly terminated, or there are unconsumed component values within the block not handled by the data type parser.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D68340127
fbshipit-source-id: 402f2eabdf6df7bce99223c966f22c2158103be5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48737
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling.
## This diff
- Updates files in Libraries/AppState and Libraries/BatchedBridge to use `export` syntax
- `export default` for qualified objects, many `export` statements for collections (determined by how it's imported)
- Appends `.default` to requires of the changed files.
- Updates Jest mocks.
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/BatchedBridge` and `Libraries/AppState` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Reviewed By: robhogan
Differential Revision: D68275767
fbshipit-source-id: 97dc84c04a8dd9c9022e53fc4595302efc848338
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48745
This is the first step in a series of diff to make RNGP more Gradle-compliant (specifically for the sake of configuration caching).
Specifically the problem in those 2 tasks is that we're accessing `project.copy()` and other
functions from the `project` field.
The project should never be accessed at execution time. See more on this here:
https://docs.gradle.org/8.12/userguide/configuration_cache.html#config_cache:requirements:use_project_during_execution
This diff fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68282777
fbshipit-source-id: 6d474f266b5bc50fba57c8cd478173c995864bbc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48764
When working on the [commit](https://github.com/facebook/react-native/commit/eced906bedf0c3d2bbc592cc27965c88278abae3) I forgot a bit that makes sure the New Architecture was the default.
This is change set the New Arch as default properly in RCTAppDelegate. Plus it refreshes the GHA caches by updating the Podfile.lock
## Changelog:
[Internal] - Ensure that the New Arch is turned on in RCTAppDelegate
Reviewed By: alanleedev
Differential Revision: D68329797
fbshipit-source-id: 9df5f805f7d3506129909f0adae5ff597f33ce3c
Summary:
In the `displayModeToInt()` function, there is no default case defined which is causing the following warning in React Native Windows when trying to build on the New Architecture:
```
##[error]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Error C2220: the following warning is treated as an error
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): error C2220: the following warning is treated as an error [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
##[warning]node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): Warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value
D:\a\_work\1\s\node_modules\react-native\ReactCommon\react\renderer\uimanager\primitives.h(163,1): warning C4715: 'facebook::react::displayModeToInt': not all control paths return a value [D:\a\_work\1\s\vnext\Microsoft.ReactNative\Microsoft.ReactNative.vcxproj]
```
Adding the default case removes the warning and resolves the issue. Not sure if using the -1 value in this case is appropriate.
## 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] - Add default case to `displayModeToInt()` function
Pull Request resolved: https://github.com/facebook/react-native/pull/48711
Test Plan: Tested on React Native Windows New Arch application and was able to build successfully.
Reviewed By: javache
Differential Revision: D68265335
Pulled By: rshest
fbshipit-source-id: 4724a4c7391b9bf651a122f5de227a0c5e0b6212
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48753
[This commit](https://github.com/facebook/react-native/commit/cc89ddd50bed869013082ad98eb0555a386cf7c9) introduced a dependency between RCTFabric and RCTAnimation because RCTFabric is now using `RCTInterpolateColorInRange` which is defined in `RCTAnimation`.
To unblock the CI, I'm adding the dependency to the RCTFabric.podspec
However, I'm not convinced that this is the proper fix. We should move the function to a common dependency between RCTFabric and RCTAnimation. Probably in `RCTUtils`.
## Changelog:
[Internal] - Fix CI by making RCTFabric depend on RCTAnimation
Reviewed By: GijsWeterings
Differential Revision: D68322935
fbshipit-source-id: 57c8833e348fb69dc1b1703ffeedd3383405b4f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48754
The React-FabricComponent was importing some non-existent files when we build for iOS with cocoapods.
This change fixes it.
## Changelog
[Internal] - Only include ReactCommon and ios platform for TextInput
Reviewed By: GijsWeterings
Differential Revision: D68319960
fbshipit-source-id: 45ddd7765f6afc0efef6dc1dadea782871fbd779
Summary:
- Adds support for color transition hint syntax in linear gradients. e.g. `linear-gradient(red, 20%, green)`
- Adds `px` support. Combination of `px` and `%` also works.
- Simplified color stops parsing.
- The `processColorTransitionHint` and `getFixedColorStops` is moved to native code so it can support combination of `px` and `%` units as it requires gradient line length, which is derived from view dimensions and gradient line angle.
- Follows CSS [spec](https://drafts.csswg.org/css-images-4/#coloring-gradient-line) (Refer transition hint section) and implementation is referred from [blink engine source](https://github.com/chromium/chromium/blob/a296b1bad6dc1ed9d751b7528f7ca2134227b828/third_party/blink/renderer/core/css/css_gradient_value.cc#L240).
## Changelog:
[GENERAL] [ADDED] - Linear gradient color transition hint syntax and `px` unit support.
Pull Request resolved: https://github.com/facebook/react-native/pull/48410
Test Plan:
Added testcase in processBackgroundImage-test.ts and example in LinearGradientExample.js
<img width="500" alt="Screenshot 2025-01-05 at 11 38 13 PM" src="https://github.com/user-attachments/assets/62858bb7-1dbf-40cf-8dd4-ec0daf84ac1b" />
## Todo
Add testcases for `getFixedColorStops` and `processColorTransitionHint` in native code for both platforms. That's the only downside of moving it out of JS 🤦
Reviewed By: NickGerleman
Differential Revision: D67870375
Pulled By: joevilches
fbshipit-source-id: b91d741f3108c25df8000d220726bf180c64be60
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48718
This diff looks a bit scary, but it's mostly just structural changes of existing code and some deletion, on a well tested path 😅.
The current parser implementation tries to special case "basic" data types. When I was looking at how to add in support for more complex values, such as lists, function notations, and more compounded types, this distinction ends up not making much sense.
Instead of treating some types as basic, this diff instead moves to a model where a user can declare any structure as a `CSSDataType`, so long as they also supply a parser, which may be visited when iterating through CSS syntax blocks (preserved tokens, function blocks, or simple blocks, which probably won't be used). The user then specifies a list of supported CSS data types to parse, which invokes said parser, calling any defined methods for specific syntax. E.g.
```cpp
struct CSSNumber {
float value{};
};
template <>
struct CSSDataTypeParser<CSSNumber> {
static constexpr auto consumePreservedToken(const CSSPreservedToken& token)
-> std::optional<CSSNumber> {
if (token.type() == CSSTokenType::Number) {
return CSSNumber{token.numericValue()};
}
return {};
}
// Could also accept function block here as well (e.g. for future math
// expressions)
};
static_assert(CSSDataType<CSSNumber>);
```
```cpp
// Can be one of std::monostate (variant null-type), CSSWideKeyword,
// CSSNumber, CSSLength, or CSSPercentage. In this case, a CSSLength.
auto value = parseCSSProperty<CSSNumber, CSSLength, CSSPercentage>("5px");
```
This breaks a whole lot of assumptions I made a year ago, especially around `CSSValueVariant` which must now be able to handle arbitrary values. For now, for the sake of simplicity, I threw this out, and migrated parser code to use plain-old `std::variant`, which has a downside of being a bit less optimized in terms of storage. I also ended up completely throwing out `CSSDeclaredStyle`, since it would majorly need to change, and we're not going to be migrating style storage quite yet. This change also broke the `CSSProperties.h` property definitions and parsing shorthand a bit, which we will need for value processing later. I also opted to delete this for now (a big centralized list is the wrong structure anyways), but will likely copy bits from its source history later.
Another particular hairy bit, that likely won't bite us in practice, is that some strings may be parseable under different data types. This just adds caller requirement to order the types correctly, instead of precedence being implemented as part of the parser.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D68245734
fbshipit-source-id: 132b11053cf41f57483c89176a9a6dceebb69fad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48716
`transparent` is specced as a special `<named-color>` outside the table the others were derived from. Let's add it, since it is supported today by `normalizeColor`.
https://www.w3.org/TR/css-color-4/#named-colors
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D68246770
fbshipit-source-id: 3ff7ed68ebb3d6bc59b24a25d35342620670f0c3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48691
We don't intent to use the prealpha logic in the near future so it makes sense to remove it for
to simplify our already complicated release process. We can always revive it if we wish.
Changelog:
[Internal] [Changed] -
Reviewed By: cipolleschi
Differential Revision: D68206014
fbshipit-source-id: f05eeae3997d52df1127852e03437a387a01f5ad
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48739
Follow-up to https://github.com/facebook/react-native/pull/48603
I realized there is one last `tasks.creating` invocation inside `hermes-engine` that needs migration. This fixes it.
Changelog:
[Internal] [Changed] -
Reviewed By: alanleedev
Differential Revision: D68276984
fbshipit-source-id: d58cf64cf41c7943464f15d12c7a04c3cc43ec7d
Summary:
https://github.com/facebook/react-native/issues/48225 fixed the same problem on Mac Catalyst build, but this crash also happen on a iOS build app running on Apple Silicon Mac.
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a iOS build app running on Apple Silicon Mac.
## Changelog
[iOS][Fixed] - Workaround for a iOS build app running on Apple Silicon Mac(in Xcode Destination: "Mac(Designed for iPad)") TextInput crash due to serialization attempt of WeakEventEmitter
## 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
Pull Request resolved: https://github.com/facebook/react-native/pull/48583
Reviewed By: javache
Differential Revision: D68093083
Pulled By: cipolleschi
fbshipit-source-id: ac48be3305eb01ff2b62d63283b929e8ab6b250c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48543
Introduces a shared interface for methods that need to be called by the `ReactScrollViewAccessibilityDelegate`
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D67948151
fbshipit-source-id: 9bafaa0b5f9ad5ba2fd73b7b1929d784fa4951c9
Summary:
Since we updated Gradle, I've noticed several warnings related to configuration avoidance API:
https://docs.gradle.org/current/userguide/task_configuration_avoidance.html
We should be using tasks.registerting rather than tasks.creating as this is going to break in Gradle 9/10.
This PR fixes it.
## Changelog:
[INTERNAL] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48603
Test Plan: CI
Reviewed By: javache
Differential Revision: D68270870
Pulled By: cortinico
fbshipit-source-id: 0ed44d903692c20d102143082fd0939f4dbeaa88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48712
Currently, all scroll events can be throttled by the `scrollEventThrottle` value when the intention is only to throttle `onScroll` calls. As a result, the scroll view helper unintentionally drops events unrelated to scrolling, like momentum begin/end. It's imperative that these momentum events dispatch so the scroll view does not lock itself in an "animated" state on the JS side; if locked in an animation state, children of the scroll view will not receive touch events. This can happen when the throttle is sufficiently high and momentum scrolling completes before the throttle time has elapsed.
Changelog:
[Android][Fixed] - Scroll view throttle no longer impacts events other than `onScroll`
Reviewed By: javache, rshest
Differential Revision: D68234045
fbshipit-source-id: d5c11412d3f273811a45e6f61af08d3fcf9f61d5
Summary:
Continuing our usual journey, this time migrating MessageQueueThread. Was not expecting to see that many assertions in ReactContext.
One important thing to note on this PR: I had to add an extra Throw RuntimeException to `startNewBackgroundThread`. It already had one from the`dataFuture.getOrThrow()`, but if your thread is not associated with a Looper, calling `myLooper` (Line 203 of MessageQueueThreadImpl) Can return null. Until now, this would have been a `NPE`, i just decided to make it a `RuntimeException` with the message `Looper not found for thread`. Let me know if you want me to make that function return a nullable, or throw another message or exception, or if you want me to treat Looper as Nullable in the whole class.
## Changelog:
[INTERNAL] [FIXED] - Migrate MessageQueueThread and MessageQueueThreadImpl to Kotlin
Pull Request resolved: https://github.com/facebook/react-native/pull/48652
Test Plan: <img width="1318" alt="Screenshot 2025-01-13 at 21 03 00" src="https://github.com/user-attachments/assets/462cc8af-4648-4437-9260-5ffa6c69e763" />
Reviewed By: tdn120
Differential Revision: D68155120
Pulled By: rshest
fbshipit-source-id: 1082a832df5b1d8ee64ca7be26e4b85e79152f88
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48723
## Changelog:
[Internal] -
In certain scenarios `TouchEvent` can be initialized with "unexpected" event actions, such as `ACTION_SCROLL`.
This caused an exception , even though such scenarios may be legitimate.
Reviewed By: javache
Differential Revision: D68265040
fbshipit-source-id: d31881e03d9110bb4f6af38548a4f73a41c54d2b
Summary:
The testing script is making unnecessary call to `input keyevent 82` which causes the Android device to
open the menu.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48707
Test Plan: Tested local with local device
Reviewed By: cipolleschi
Differential Revision: D68215641
Pulled By: cortinico
fbshipit-source-id: 3e2653d8aa0c1e6606d9921f7b3794d0d27ef3f0
Riccardo Cipolleschi
Rick Hanlon
Dawid Małecki
Nick Gerleman
Iwo Plaza
Nicola Corti
Jakub Piasecki
Mateo Guzmán
Yajur Grover
Sam Zhou
nishan (o^▽^o)
Pieter Vanderwerff
David Vacca
Rob Hogan
Samuel Susla
iwater
Peter Abbondanzo
Rob Hogan
Parsa Nasirimehr
Ruslan Shestopalyuk