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
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46145
Filters clip children by default due to using `RenderEffect` we are keeping this behavior but we were clipping to the border box while Web clips to padding box.
To keep the clipping consistent we are enforcing `Overflow.HIDDEN` when a view contains a filter.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D61630698
fbshipit-source-id: dcc3fd680546793096d8996f405724df0a834079
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46231
Removes this option from `npx react-native start`. Flipper will no longer be the default launch flow in 0.76.
The debugger frontend variant remains controlled by `target.reactNative.capabilities?.prefersFuseboxFrontend`. This will always be Fusebox, since D60893243.
Changelog:
[General][Changed] Remove `--experimental-debugger` option from start command
Reviewed By: robhogan
Differential Revision: D61852415
fbshipit-source-id: 3351f0e12c24717916a70dd1ea28f8690bb5509f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46223
Changelog: [internal]
This introduces a new feature flag to fix some problems with `IntersectionObserver` on Android.
## Context
Our current implementation works as follows:
1. When observing a new target, we synchronously check if there are pending transactions in the mounting layer for that surface.
a) If there are, then we don't dispatch an initial notification for the current state of that target and we wait for those transactions to the applied. When they are, mount hooks are executed and the notifications are dispatched.
b) If there aren't, then we cannot rely on receiving a notification via mount hooks, so we dispatch the notification immediately.
This works well to ensure that when observing a target that was just mounted by React we'll receive a notification with the paint time for that target.
The problem we currently have on Android is that that platform uses a "push" model for the mounting layer, which means we consume transactions immediately after commit. Because of that, when we check whether there are pending transactions, the mounting layer would report "no" but the consumed transactions haven't actually been mounted. In that case, we dispatch the notification immediately.
The result of that behavior is that we don't wait for the transactions that will paint a new target and instead report its intersection immediately, providing incorrect data about when it was first mounted.
## Changes
The way the new feature flag fixes the problem is by adding a new parameter in `MountingCoordinator::pullTransaction` to tell the coordinator that it should continue reporting pending transactions if there were any when that was called. We also add a new method to clear pending transactions when we execute mount hooks for that surface.
Reviewed By: javache
Differential Revision: D61831209
fbshipit-source-id: ed6e5a3d27bd3e802c79a203e920d247b1715c61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46234
We were seeing some cases of these not working and that was because CoreFeatures::enablePropIteratorSetter was set to true and we need to add this line for it to parse with that
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D61861547
fbshipit-source-id: 47356671dc61e99ffa3df9834eb5856f29b07c59
Summary:
RN Android has historically delegated any responsibilities for background and border rendering to individual view managers.
When we enforced that SVCs didn't allow more properties than native view configs, it meant that unlike for iOS, we needed to structure these SVCs to only apply to single view managers, to avoid warnings.
This creates issues for third-party view managers extending ReactViewGroupManager, which don't seem to get these attributes added to their SVCs under current setup. RNSVG also uses `codegenNativeComponent` on TS `ViewProps`, but for historically reasons around hiding props from the new arch, that does not include these props (and would not have a way to associate with the right process function if it did).
After we clean up an old experiment path (waiting a little bit longer for safety), BaseViewManager on Android will be able to influence rendering, and we can put these in BaseViewManager (see D61658737).
In the meantime, D60575253 allows us to make SVCs a superset of native view config, which means we can declare this for `BaseViewConfig`, before Java view managers catch up, without creating warnings.
Changelog:
[Android][Changed] - Move `experimental_boxShadow` and `experimental_backgroundImage` to BaseViewConfig
Reviewed By: RSNara
Differential Revision: D61744706
fbshipit-source-id: dcf3511ee6f826ef260f557703c182b361b7a2d7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46043
# Changelog: [Internal]
Defined JavaScript interface, which can be used by other modules, such as LogBox, which will be migrated in the next diff
Reviewed By: robhogan
Differential Revision: D61301333
fbshipit-source-id: 63bb8581b893d0fdcb36e1fa16d243f1a5b08ac4
Summary:
Solves this issue: https://github.com/facebook/react-native/issues/29763
## 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
-->
[ANDROID] [ADDED] - Added a conditional check in the `resolveThemeAttribute` function to reattempt resource resolution with the "android" package name if the resource ID is 0.
**Reason why app is getting crashes?**
The crash was occurring due to an issue with resolving certain color attributes in the Android theme. Specifically, when attempting to resolve attributes like textColorPrimary, the getIdentifier method returned a resource ID of 0, indicating that the resource could not be found. This issue resulted in the resolveThemeAttribute function failing, as it attempted to resolve a non-existent resource ID, which led to a crash.
**Key Points:**
**Problem**: Resource ID returned as 0 for specific attributes like textColorPrimary.
**Cause**: The resource ID of 0 indicates that the attribute was not found in the app's resources.
**Impact**: The resolveThemeAttribute function attempted to resolve an invalid resource ID, leading to crash because of this line: 6cfe51ded0/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/bridge/ColorPropConverter.java (L227)
The introduced fix includes a fallback mechanism to attempt resolution with the "android" package name when the initial lookup returns 0. This helps in correctly resolving theme attributes that might be part of the Android system's default resources, thereby preventing the crash.
Pull Request resolved: https://github.com/facebook/react-native/pull/46202
Test Plan: - Tested the app with above colors mentioned. Ensured that app is not getting crashed.
Reviewed By: cipolleschi
Differential Revision: D61847357
Pulled By: cortinico
fbshipit-source-id: 50895a8fd7956e001dbbad9a505ae65151209bd9
Summary:
Replicates 48d4c29bba, which landed inside `cli-plugin-metro` inside RNC CLI, but because of migration of code to `community-cli-plugin` it looks like apparently the fix wasn't replicated.
## Changelog:
[GENERAL] [FIXED] - Ensure `--build-output` destination exists
Pull Request resolved: https://github.com/facebook/react-native/pull/45182
Test Plan:
Specify a new directory that doesn't exists inside `--build-output`:
`npx react-native bundle --build-output dist/new-dir/index.bundle`
and this command shouldn't fail.
Reviewed By: christophpurrer
Differential Revision: D61850942
Pulled By: huntie
fbshipit-source-id: 90e57f19c661ace8206162d6fa2e6a27acb31e20
Summary:
This PR solves a small issue I've encountered when working with the repo.
When changing branches we often run `yarn` to reinstall dependencies (let's say we change from 0.74-stable to main).
There are lots of changes between those two versions in the `react-native-codegen` package. This causes an issue when we install pods in `packages/rn-tester` the old version of codegen is used (the one cached from 0.74-stable) leading to a big error that's hard to solve at first.
This PR solves this by building codegen on `postinstall`. I've seen many newcomers blocked by this issue (and rerunning `yarn` is the natural thing to do in this situation)
## Changelog:
[INTERNAL] [ADDED] - Build codegen on postinstall when working with the monorepo
Pull Request resolved: https://github.com/facebook/react-native/pull/46227
Test Plan: Run `yarn`
Reviewed By: cipolleschi
Differential Revision: D61849150
Pulled By: huntie
fbshipit-source-id: 24fc5cf9b6a2510298f7bcdce59043e5dcfbfdd4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46229
When running codegen from `pod install`, something affects `require.resolve`, and it starts looking for codegen-enabled dependencies from the workspace root, not the current RN project root.
This is bad if we have different versions of same dependency across multiple workspaces. One of them will be hoisted to the workspace root, and will be used for all the workspaces.
This issue is described in details here https://github.com/facebook/react-native/issues/46196
This diff is supposed to fix this by adding the project root path to the `require.resolve` call.
Changelog: [iOS][Fixed] - Codegen will start looking for codegen-enabled dependencies from the project root.
Reviewed By: cipolleschi
Differential Revision: D61850219
fbshipit-source-id: d60a0e72e9c60e862c0d64e227ea3652d1be5a90
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46216
Regarding [issue](https://github.com/facebook/react-native/issues/45817) with incorrect layout when `left` is set to `auto`. This PR introduces handling `auto` whenever inline or flex position is checked to be defined and it fixes above issue.
Changelog:
[General][Fixed] - Fix handling 'auto' checks in absolute layout
## Tests:
I have run the provided unit tests and everything passes.
X-link: https://github.com/facebook/yoga/pull/1689
Reviewed By: cipolleschi
Differential Revision: D61737876
Pulled By: NickGerleman
fbshipit-source-id: 531199a91c5e122b930b49725ea567cbb1d592ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46215
These cause a build error in RN and need to be updated any time a thick Yoga API changes. This change replaces them with mocking the factories with Mockito instead.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D61804855
fbshipit-source-id: 24fbf10a12102de2975ba3aee45efe7350e294ec
