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:
Pull Request resolved: https://github.com/facebook/react-native/pull/48715
{D68154908} fixed a problem with the `onAnimatedValueUpdate` listener not being correctly attached if `__attach` were called before `__makeNative` (which sets `__isNative` to true).
We're potentially seeing production symptoms of stuttering interactions and user responsiveness, after queuing up many operations. Our hypothesis is that in scenarios where `ensureUpdateSubscriptionExists` is being called during `__makeNative` (instead of during `__attach`), a backup of operations occurs leading to these symptoms.
This diff attempts to validate and mitigate this hypothesis by deferring `ensureUpdateSubscriptionExists` to when an `AnimatedValue` instance has had both `__attach` and `__makeNative` invoked.
Changelog:
[Internal]
Differential Revision: D68236594
fbshipit-source-id: 2089100a773ebfc161fb5b567123eb58a893939f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48708
{D68171721} [facebook/react-native#48678](https://github.com/facebook/react-native/pull/48678) mitigated the bug that necessitated this revert.
Changelog:
[General][Changed] - (Reapply) The `AnimatedNode` graph will not occur during the insertion effect phase, which means animations can now be reliably started during layout effects.
Reviewed By: sammy-SC
Differential Revision: D68217144
fbshipit-source-id: 6796440f2839d897158528642e07869951651327
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48703
## Motivation
Modernising the react-native codebase to allow for ingestion by modern Flow tooling
## This diff
- Updates files in Libraries/Alert and Libraries/ActionSheetIOS 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 of the related modules
- Updates the public API snapshot (intented breaking change)
Changelog:
[General][Breaking] - Files inside `Libraries/Alert` and `Libraries/ActionSheetIOS` use `export` syntax, which requires the addition of `.default` when imported with the CJS `require` syntax.
Differential Revision: D68210738
fbshipit-source-id: a984034b165908f75485f2bad33fcccadd865494
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48678
While diagnosing a recent issue in which `AnimatedValue` instances were not being correctly updated as expected, the insertion effects feature flag was identified as a root cause.
Upon further investigation, it appears that this is because the `onUserDrivenAnimationEnded` listener was not implemented the same way in the two feature flag states:
- When `useInsertionEffectsForAnimations` is disabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in a passive effect, after all nodes have been attached.
- When `useInsertionEffectsForAnimations` is enabled, `useAnimatedProps` listens to `onUserDrivenAnimationEnded` in an insertion effect when attaching nodes.
The bugs occurs because `useAnimatedProps` checks whether native driver is employed to decide whether to listen to `onUserDrivenAnimationEnded`. However, we do not know whether native driver will be employed during the insertion effect. (Actually, we do not necessarily know that in a passive effect, either... but that is a separate matter.)
This fixes the bug when that occurs when `useInsertionEffectsForAnimations` is enabled, by moving the listening logic of `onUserDrivenAnimationEnded` into a passive effect. This is the same way that it is implemented when `useInsertionEffectsForAnimations` is disabled.
Changelog:
[Internal]
Reviewed By: javache, sammy-SC
Differential Revision: D68171721
fbshipit-source-id: 50b23348fd4641580581cacebc920959651f96a7
Summary:
Whenever I run `yarn lint --fix` I noticed that this test is not formatted correctly. This fixes it.
## Changelog:
[Internal] [Changed] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48692
Test Plan: CI
Reviewed By: sammy-SC
Differential Revision: D68207001
Pulled By: cortinico
fbshipit-source-id: 2a6c44ca02249f6662b03c87f0c4d4f3eb5a3054
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48690
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: D68205691
fbshipit-source-id: 22a3416335052a4bf6a76faa6e6af622254a6e56
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48689
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] - RNGP - Cleanup prealpha logic from the Gradle Plugin
Reviewed By: cipolleschi
Differential Revision: D68205665
fbshipit-source-id: 81d5257544df97b566421164944e3b6e71f06635
Summary:
In the old arch, stylistic sets were supported however in the new arch support was not added. It seems that fontVariant support was actually initially missed on iOS fabric however a limited version was added in https://github.com/facebook/react-native/pull/44112 . I referenced that PR and also old arch implementation for these changes.
<img width="480" alt="Screenshot 2025-01-14 at 11 15 18 AM" src="https://github.com/user-attachments/assets/ec32a356-fadd-4281-83b9-15871bbcd18f" />
## Changelog:
<!-- 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
-->
[GENERAL] [ADDED] - Support stylistic sets for fontVariant
Pull Request resolved: https://github.com/facebook/react-native/pull/48674
Test Plan:
- Verified that the "Unsupported FontVariant" native log no longer displays on both platforms
- On iOS was easy to test in the tester app as SF supports stylistic sets by default:
```
<Text>
Stylistic{'\n'}
<Text>Normal: ${'\n'}</Text>
<Text style={{fontVariant: ['stylistic-four']}}>
Stylistic Four: $
</Text>
</Text>
```
<img width="391" alt="Screenshot 2025-01-14 at 11 59 29 AM" src="https://github.com/user-attachments/assets/1ede258e-783f-448f-8300-4c8c710796ef" />
- On Android I could not find any system fonts that support stylistic sets by default so I added Raleway and confirmed with a W character
I did not add font variant example to the tester apps as I felt it could be confusing for people at a glance to understand why there is only a system font example on iOS and why I chose the specific stylistic set.
Reviewed By: cipolleschi
Differential Revision: D68205738
Pulled By: javache
fbshipit-source-id: 03ce572d3c8ecafca71fe00fc0e88eeafc2558bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48664
Simplify ViewManager base-class by making `ViewManager`'s delegate non-nullable and using a single path for updating properties.
The ViewManagerDelegate API can map back to the original ViewManagerSetter API transparently, allowing us to remove the codepath from `ViewManagerPropertyUpdater`.
Changelog: [Android][Removed] `ViewManagerPropertyUpdater.updateProps` is deprected, use the related ViewManager APIs instead
Reviewed By: mdvacca, rshest
Differential Revision: D68120420
fbshipit-source-id: cd8b906dc36d4803dbe09ee0283654285eb81fd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48658
Migrate to Kotlin before I make further changes to this. Generics are really tricky due to our previous usage of raw generics on the Java side, but were worked around by some combination of unchecked cast and `Nothing`
Changelog: [Internal]
Reviewed By: mdvacca, rshest
Differential Revision: D68102210
fbshipit-source-id: 90013f09db0826f571a4e2a84132ae3b49fa299d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48547
For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why
I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input.
This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method.
**In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`.
Changelog: [Android] [Fixed] - TextInputs can now receive focus via external keyboard
Reviewed By: NickGerleman
Differential Revision: D67953398
fbshipit-source-id: 506006769a7c8a63f0a9b7ce27cfbe8578777790
Riccardo Cipolleschi
nishan (o^▽^o)
Nick Gerleman
Nicola Corti
David Vacca
Rob Hogan
Samuel Susla
iwater
Peter Abbondanzo
Parsa Nasirimehr
Mateo Guzmán
Dawid Małecki
Ruslan Shestopalyuk
Tim Yung
Devan Buggay
Iwo Plaza
Fabrizio Cucci
Levi
Pieter De Baets
Joe Vilches