Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46311
A straightforward move of `NativeAnimatedHelper` into the private directory, so that it does not impact our Public API.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D62142349
fbshipit-source-id: c93979e26e290d13e2a19fbe40d8f460ebea15fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46316
This pull request introduces enhancements to the view controller presentation logic in React Native, allowing for multiple sheets to be presented on top of each other. The current implementation restricts the presentation to a single view at a time, which limits the flexibility needed in complex applications.
The proposed changes modify the presentation behavior to always utilize the top-most view controller for presentations. This adjustment ensures that multiple sheets can be managed more effectively, without disrupting the existing application flow.
Key changes include:
Modification of the presentation logic to reference the top-most view controller.
Utilization of a recursive method to determine the top-most controller.
The changes have been thoroughly tested with both old and new interfaces and have shown to work seamlessly across different scenarios
Changelog: [Internal] Allow multiple sheets to be presented on top of each other
Reviewed By: cipolleschi
Differential Revision: D62143463
fbshipit-source-id: 53667cf1a75e4514156780574bf604aee6b3fefc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46287
Changes `Animated` to avoid validating certain values in production builds to improve performance.
In order to maintain consistent behavior between development and production builds (so that we reduce the likelihood of bugs that only appear in one of the environments), this also changes the validation errors to use `console.error` instead of error throwing.
Changelog:
[General][Changed] - Changed `Animated` props validation to soft errors instead of thrown errors
Reviewed By: sammy-SC
Differential Revision: D62055674
fbshipit-source-id: 8e5732d00ab06e14ba8562f5190ce79ca240e374
Summary:
The following fixes were needed to restore a clean build of React Native Windows downstream.
- LayoutableShadowNode.cpp: Value must be cast to a float to avoid type conversion error.
- ValueUnit.h: Must add a default return statement. Switch statement alone produces compiler error that function may end with no return value.
## Changelog:
[GENERAL] [FIXED] - Upstream fixes for build errors in React Native Windows
Pull Request resolved: https://github.com/facebook/react-native/pull/46315
Test Plan: React Native Windows CI runs clean.
Reviewed By: javache, alanleedev
Differential Revision: D62149228
Pulled By: realsoelynn
fbshipit-source-id: 0d85455a22fbc0066076a50adee6b2d4409cd628
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46314
In Bridgeless's version of the Hermes JVM init path, we defaulted an internal GC option to allocate memory in Hermes' OldGen, and revert that behaviour once an internal API was called which marked the app as loaded.
This is an unsuitable default behaviour, since we can't rely on that internal API to be called on every launch. We're also moving to implicit performance instrumentation, which makes it harder to reliably call this API at the right time.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D61937427
fbshipit-source-id: 95e43fc093b56aee6362f43b6b0832d1f439fb3f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46249
Add internal only version of SafeAreaView.
This should be only used within RN Core or RNTester as there are a few places where this is needed and cannot have dependency on 3rd party
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61896413
fbshipit-source-id: 03fc263a9341f9b93b696d88a77a6501cd490177
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46302
Changelog:
[General][Fixed] - Removed noisy ENOENT error message upon launching the debugger
As described in T200199544, Metro terminal in open-source would show an error message for the missing embedder script.
In this diff, we add a response of an empty file to open-source (no-op)
Reviewed By: hoxyq
Differential Revision: D62103015
fbshipit-source-id: 219bc398b7786527db00528cca175adc13a527a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46282
We intended to enable Fusebox on `main` since https://github.com/facebook/react-native/pull/45469 — this worked when building under Buck, however was not working for builds under Xcode/Android Studio. This is because the `HERMES_ENABLE_DEBUGGER` preprocessor flag is not equivalently defined in these build configurations.
This diff genericises these checks to `!defined(NDEBUG)` (i.e. *any debug build*), meaning we are correctly able to evaluate the `ReactNativeFeatureFlags::fuseboxEnabledDebug()` setting.
Changelog: [Internal]
NOTE: `NDEBUG` should be the as-generic-as-possible choice to select a debug build in both OSS and fbsource. Having `HERMES_ENABLE_DEBUGGER` set remains significant (AFAIK) **within the Hermes codebase** (there are no other references in `jsinspector-modern`). Evaluation of whether the lack of this flag works in OSS continues in T200241280.
Reviewed By: hoxyq
Differential Revision: D61966685
fbshipit-source-id: d30950172420a0afd6c137dbf014794f3353bb7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46271
Improves the error thrown when an invalid value is supplied to `processFilter`. Without this, the error thrown would look something like:
> TypeError: … is not iterable
Changelog:
[General][Changed] - Improved error message for invalid filter values
Reviewed By: jorge-cab
Differential Revision: D62011191
fbshipit-source-id: 5594eeaf2b9174af14cc9e4daa275ae72974e597
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46281
In CSS newlines are considered equal to whitespaces which is why when receiving strings from RSD we could get \n characters which we were not handling
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D62034706
fbshipit-source-id: df2342b89156a131fecd0b0babeb478a6962b108
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46251
The diff D21124739 introduced this as a workaround for some faulty logic we used to have.
It seems like we no longer need it and it was actually causing issues with small border radii. Its barely noticeable but Outline looks weird in some cases if we leave it as is
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61938725
fbshipit-source-id: cf7ee7417e1085d01e2e307e780ff5d1db499e69
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46273
The implementation of `AnimatedObject` should recurse through its structure and consistently treat `ReactElement` objects as opaque.
It wasn't consistent. This makes it consistent.
Changelog:
[General][Fixed] - Fixed undefined behavior in certain scenarios when `ReactElement` objects are supplied to Animated components
Reviewed By: javache
Differential Revision: D62012006
fbshipit-source-id: e6c3ac472945af8070735f1df856ff88b30a5624
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46264
React-native was not in sync with metro changes that RN relies on
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D61982240
fbshipit-source-id: 63b1f53174ab0ec663a537569a032c62c431eb83
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46191
Borders should not have to deal with clipping logic, that is fairly independent.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61418470
fbshipit-source-id: 762dbf30d50b5ce9b2b73720e58625447d8bf00e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46190
Right now the background color is tightly coupled with border drawing. For starters, I find this a bit confusing as one would not assume they are very closely related. But this also causes a bug around not being able to properly clip to the padding box, because if we did this we would clip the background color and transparent borders would look wrong.
This would also block a fix related to how borders display with clipped content that is coming in the later diffs. If we decide to use the border image, then we cannot properly display things like images since they would be on top of this image (otherwise background color shows through).
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61248625
fbshipit-source-id: ad398bbcfb69edc7d61362920773b51abea81d08
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46189
A lot of the style decorators we have (filters, box shadows, borders, etc) use a separate sub-CALayer to accomplish what they want. This becomes an issue if we are clipping the content to the bounds and if these decorators extend beyond the bounds of the view as they are typically unaffected by this clipping. The main things here are `box-shadow` and `outline`. However, this implementation will let us fix some issues w.r.t content rendering under borders. See later diffs for that.
To fix this, if needed, we insert a `_containerView` to contain all of our subviews, and actually apply the clipping to. If this exists, our UIView will only have one subview, this one. But it may have multiple sublayers.
NOTE: This diff does not actually redirect the clipping. It just inserts the subview to test if this breaks anything in and of itself.
Changelog: [Internal]
Reviewed By: lenaic
Differential Revision: D61414649
fbshipit-source-id: ddc2bfa47199909274c44da96a16e008290f9d2b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46270
Changelog: [internal]
When analyzing traces, I noticed that we were using the choreographer to batch events in the native layer on Android. This approach isn't very efficient for 2 reasons:
1. The choreographer runs in specific intervals and there could be some delay between receiving the events and dispatching them from the choreographer.
2. A slow mount operation in the choreographer after receiving the event would completely block the dispatch for the whole duration of the operation. This could take as long as 100s of ms, so it can be very significant.
This is especially relevant with layout events, which are dispatched using the same mechanism as input events. In this case, there are instances where we delay rendering in JS because we're doing an expensive mount in the UI thread.
It makes sense to batch events in native so we don't do unnecessary work in JS to process them, but there's a better mechanism to do this. Instead of posting a frame callback in the choreographer, we can batch events using a new task in an Android handler running on the UI thread. This would run immediately after the job where the events are dispatched, after all the events are dispatched.
This implements that mechanism behind a feature flag.
Reviewed By: sammy-SC
Differential Revision: D62004018
fbshipit-source-id: d8b78a75cf05d0d8c9dd867a82a776f8d293a683
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46269
Changelog: [internal]
I'm planning some changes to this class and it was kinda hard for me to understand what some of these methods were meant to do. Doing a small refactor to rename them with more meaningful names.
Reviewed By: sammy-SC
Differential Revision: D62004020
fbshipit-source-id: 1e28e7e80f12a3a56ff16ace8794887b2f46495c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46268
Changelog: [internal]
`mReactEventEmitter` is final and initialized with a non-null value in the constructor, so this check is redundant.
Reviewed By: sammy-SC
Differential Revision: D62004021
fbshipit-source-id: bb8719c286cd04005370f2cdef89928c0d01007a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46267
We can propagate opacity, already part of AttributedString, to alpha channel of paint used to draw text and background on canvas.
This does not support propagating to views, and contrary to the iOS example added which originated with legacy arch, does not correctly support nesting opacity. This is a limitation of new arch more generally, where an AttributedString fragment only contains inner-most opacity.
Bg and foreground are drawn separately with alpha as well, instead of rendering overlapping content offscreen to properly apply it (this is an issue on RN Android more generally, and existing color alpha support, but is pretty noticeable here).
This impl targets new arch only.
Changelog:
[Android][Added] - Support simple opacity in nested text
Reviewed By: alanleedev
Differential Revision: D61999163
fbshipit-source-id: adb99834e94e00cb84a98d56f422c15b1bd849db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46242
This is transitively included, but should be explicitly included.
Changelog:
[Internal] commander is a dependency when bundling from Xcode
Reviewed By: cipolleschi
Differential Revision: D61916607
fbshipit-source-id: 1466d38d959970e5bd56576f8a7a22697d2eec4e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46253
Changelog: [internal]
This is still internal because this API hasn't been publicly released yet.
## Context
This fixes a problem in our implementation for Event Timing API with paint time reporting (currently gated behind `ReactNativeFeatureFlags::enableReportEventPaintTime`) where events that don't trigger UI changes would wait for the next (unrelated) UI change to finish the event timing information.
## Implementation
We had this issue because we were relying on mount hooks to finish pending events. The problem is that if the event itself didn't cause a commit, the mount hook will not execute immediately, and we'll wait for the mount notification of whatever is the next change (in an arbitrary point in time in the future).
The fix for this has several parts:
1. Modify `RuntimeScheduler` to start tracking which surface IDs are the rendering updates applying to. It makes sense to do this regardless because `RuntimeScheduler` implements the Event Loop, and the Event Loop is aware of "documents" on Web (and the equivalent are surfaces in RN).
2. Create a new hook in `RuntimeScheduler` to report events after the task has finished executing (which is already a step in the Event Loop on Web). This will pass the list of surface IDs with pending changes, so the listener can determine if the events should be finished already or they should wait for mount for those changes.
3. Integrate `EventPerformanceLogger` with `RuntimeScheduler` and add the proper logic to handle this.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939260
fbshipit-source-id: 505bd41db8d3f62e5065424e62f9ed540832eed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46254
Changelog: [internal]
Right now it's very hard to access the surface ID from the target when dispatching events, and we need that to determine if the event we dispatched produced any updates its surface ID.
This adds surfaceId to EventTarget so we can access it without an unnecessary large amount of indirection in the current code.
This is a dependency for https://github.com/facebook/react-native/pull/46253 / D61939260, split to simplify reviewing.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939910
fbshipit-source-id: 6dd6bc55fc6d4aa6cf8a535080c14a7a5b573b71
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46252
Changelog: [internal]
The long task API should only account for work specifically done by the task. Updating the rendering shouldn't be considered for that, so this moves the determination of long tasks before doing that work.
Reviewed By: sammy-SC, rshest
Differential Revision: D61939261
fbshipit-source-id: 6d2573d561d507dff60b9703e4cc90ce4d131960
Summary:
When not drawing a border, the mGapBetweenPaths adjustment can create noticable pixelation when drawing curves through a low number of pixels. This is noticable mostly on buttons and such on low-dpi devices. This fix only applies the fix if clipping for the border radius is done.
When drawing small radius rounded backgrounds (e.g. to draw a circle or button) we see visible pixelation (see [GH-41226](https://github.com/facebook/react-native/issues/41226)) This is particularly noticable on low DPI devices.
## Changelog:
[ANDROID] [FIXED] - Don't use mGapBetweenPaths if not drawing a border
Pull Request resolved: https://github.com/facebook/react-native/pull/46239
Test Plan:
Built an android app that directly uses CSSBackgroundDrawable to draw a background and verified repro of this issue.
Then modified the code according to this PR and verified that anti-aliasing is appropriately applied
Reviewed By: NickGerleman
Differential Revision: D61925281
Pulled By: jorge-cab
fbshipit-source-id: 93014629d031bd0d716cd3bb11e2c294dedad639
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46237
I can't find any uses of this, it's not referenced in any fixtures, and flow and typescript both pass without it.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61892355
fbshipit-source-id: 8ebb4da3e104109c740d90c2495dbcc89d3978e5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46222
This value was typed as always being a string, even though it was containing both strings and numbers in the fixtures. This was because on this line https://fburl.com/code/9j7gh4av the input type is $FlowFixMe (from the source AST), which wasn't catching that it couldn't flow into just `string`.
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61830075
fbshipit-source-id: 0d5a0239d7c0209049184ca858a7ceb1ada02f79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46221
Previously the schema special cased unparseable elementType with elementType just being undefined. This causes issues for logic that requires recursively matching types. Instead of being implicit, this makes them explicitly an AnyTypeAnnotation
Changelog: [Internal]
Reviewed By: makovkastar
Differential Revision: D61825742
fbshipit-source-id: 47bf70d32d21647896d8f5319087378cc8ac8d4f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46241
Our test for rebuilding the `autolinking.json` file currently rebuilds everytime if the cached json file ISN'T empty. This means users who have an empty entry get stuck there.
I've also added more validation that the contents of the cached config have at a minimum the `.project.android.packageName` entry in it, otherwise it rebuilds.
Changelog: [Internal]
Closes 46134
Reviewed By: cortinico
Differential Revision: D61911114
fbshipit-source-id: 188c7f975ce05802c8ea06eaa48345c2bc96f2b2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46224
- Extract functions from StatusBarModule so they can be reused
- WindowUtil was created as a container for the extracted Window related helper functions
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D61834841
fbshipit-source-id: a40f6b95ab7569bbe7680b5ca314eb0844114d1d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46255
Trying to fix lint error in GH likely happening after this [commit](7bc9244d0c) (D60533197).
used ` yarn run format-check --write` to get changes need to fix the error when running prettier v29
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D61951889
fbshipit-source-id: 891b6b90e854504a35452e546c81bca644661dde
Summary:
Fix linear gradient borders with BackgroundStyleApplicator.
### After fix
<img width="200" alt="Screenshot 2024-08-18 at 3 44 56 PM" src="https://github.com/user-attachments/assets/79ae7c9c-3b64-43e0-bbbe-ddc930c73648">
## Changelog:
[ANDROID] [FIXED] - Linear gradient border styles
<!-- 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/46084
Test Plan: Test border examples in LinearGradientExample.js
Reviewed By: rshest
Differential Revision: D61798132
Pulled By: NickGerleman
fbshipit-source-id: a8cf1d84166044e09fb573995cac3d3f31c2187b
