Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45512
isBufferingEnabled_ can be read (by design) from multiple threads, but
it's not atomic. Make it so.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59907026
fbshipit-source-id: ffce54a28404148b3e270fa90dfe850a334ca2f0
Summary:
This PR fixes a case where the user initializes react native in a directory that contains a space.
It was causing pod install to fail because the path to `create-dummy-hermes-xcframework.sh` script wasn't in a string.
## Changelog:
[IOS] [FIXED] - Hermes prepare_command fails with space in path
Pull Request resolved: https://github.com/facebook/react-native/pull/45316
Test Plan:
1. Create a directory with space in path
2. Initialize React Native inside
3. Install pods
4. Check if pod install doesn't fail
Reviewed By: dmytrorykun
Differential Revision: D59912979
Pulled By: cipolleschi
fbshipit-source-id: b2c08d5035a245f8b4d6bfaf562e46d9c5d127b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45501
changelog: [internal]
Implement caching for FabricUIManager::getColor. A call to FabricUIManager::getColor takes on average 0.4ms and there can be many of them. The arguments for the call keep repeating in majority of times. Employing a simple caching mechanism here to avoid unnecessary trips via JNI to reduce overhead.
The dependencies in graphics in BUCK are incorrect. I tried to separate this into multiple files and move implementation to .cpp file but this will require a bit of a more restructuring to make it possible.
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D59859754
fbshipit-source-id: 748efce7f0b8c96001b6ac1a4b457b8c9d63fe9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45471
Changelog: [internal]
This is a React Native specific modification of the Long Tasks API that refines the logic to detect long tasks considering voluntary yielding checks.
In RN, as opposed to Web, we can have a very long task executing in the JS thread without causing any issues to the responsiveness of the app, as long as the task checks whether it should yield in short intervals. In this case, if the app always checks whether it should yield at least once every 50ms, the task will not be considered "long".
Check the new unit tests to see this behavior in practice.
Reviewed By: sammy-SC
Differential Revision: D55647992
fbshipit-source-id: 82ab41173d4d9deee65b8ade2268c40d7f58c6e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45473
This is a basic implementation of the Long Tasks API (https://w3c.github.io/longtasks/).
It detects and reports long tasks when using the Event Loop (in the modern RuntimeScheduler) when a new feature flag for this purpose is enabled.
This doesn't include attribution information at the moment.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D55491870
fbshipit-source-id: e1ccad9cc6a35073b31230a8cf3a4660ab9a043d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45492
Changelog: [internal]
When testing the changes in https://github.com/facebook/react-native/pull/45473 / D55491870, I saw that the reported time spans for long tasks didn't perfectly align with the long tasks themselves in traces (Perfetto).
Taking a closer look, I realized that I wasn't doing the conversion between times and durations from `chrono` and `DOMHighResTimeStamp` (a `double`) correctly, and we're doing this conversion very often.
This moves the definition of `DOMHighResTimeStamp` to its own library and adds conversion methods to make sure we don't make this mistake in the future.
Reviewed By: rshest
Differential Revision: D59820241
fbshipit-source-id: c123920de56336da384ddc484f6ac9d287724301
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45464
Previous work would cause versions >= react-native 0.76 to exit if called through `npx react-native <cmd>`. This was intended to be full deprecated and removed. The intention was to shift users to calling react-native-community/cli directly.
This change allows commands to be proxied to react-native-community/cli but with no guarantees of success. It's up to each framework / project to explicitly create that dependency.
This also provides warnings, which won't go away, suggesting the supported method of calling the community CLI directly.
The outcome is that we're not going to break existing workflows.
closes: #45461
Changelog: [General][Fixed] allow proxying commands from react-native to react-native-community/cli with explicit warning
Reviewed By: cortinico
Differential Revision: D59805357
fbshipit-source-id: 21e23b082a9c709effa050d8e7dd04a40f5ab0e6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45483
We don't really use this functionality and is getting harder to migrate to GHA,
hence I'm removing it.
Changelog:
[Internal] [Changed] - Remove report-app-size
Reviewed By: cipolleschi
Differential Revision: D59822862
fbshipit-source-id: 2d082454aea3b3c5863bd34556a23c2fc847f841
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45510
This is just a quality of life improvement, where we test the C++ autolinking
code generation a bit more.
Changelog:
[Internal] [Changed] - Improve tests for GenerateAutolinkingNewArchitecturesFileTask
Reviewed By: blakef
Differential Revision: D59907847
fbshipit-source-id: e6367cc3b1c01700310437b73bc984e3666b3499
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45511
This adds react-native.config.js to autolinking default lockfiles
so autolinking can account for changes in that file.
Changelog:
[Internal] [Changed] - Add react-native.config.js to autolinking lockfiles
Reviewed By: blakef
Differential Revision: D59907268
fbshipit-source-id: d5893a3f7b4d5d9f6c6c13042aa6866ad16b2ea4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43333
This change fixes https://github.com/facebook/react-native/issues/43285.
Basically, when using a `yarn` alias to install pods, yarn creates a copy of the `node` and `yarn` executables and the `command -v node` command will return the path to that executable.
## Changelog
[iOS][Fixed] - Do not use temporary node when creating the .xcode.env.local
Reviewed By: dmytrorykun
Differential Revision: D54542774
fbshipit-source-id: 3ab0d0bb441988026feff9d5390dcfd10869a1b5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45503
Kebab case object literals are a pain as an API to give folks. Keep string parsing using the kebab-case web names, like in CSS, but keep object notation camelCase.
This is super super hacked up, and we should burn away all these viewconfig processors as soon as we can.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59793095
fbshipit-source-id: 888cad31142d7aeed42687ab23c2023ac7e4882d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45452
With this we enable <View> to use BoxShadow.
BoxShadow property can be a string as defined on MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/box-shadow
Or it can also be a list of BoxShadow primitives:
```
[
{
offsetX: 10,
offsetY: 5,
color: 'red',
inset: true,
},
{
...
},
]
```
The diff includes:
* Style sheet changes so typing is valid
* Process function to turn boxShadow format into parsed boxShadow primitive
* Test for process function
* View config changes on Android, iOS and ReactNativeStyleAttributes
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D57872933
fbshipit-source-id: 2c5732709959bd996cce2f979549fc95cf2410e2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45481
We are going with this name as it is more commonly used in the spec and makes more sense since there are no circles involved with spread
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59819180
fbshipit-source-id: cf20c22b11e9ff9935b9f54e28db37d3ea399d8f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45457
With this change, we are implementing in Android a similar logic that we implemented in iOS.
1. When the user stops dragging a scroll view, it tells native animated modle that a scroll has finished
2. NativeAnimated module asks to the NativeAnimatedNodesModule if there are native node listening to the scroll
3. In case they are, it emits an event to JS
4. JS listen to the events and resync the Shadow Tree and the Native Tree (this implemented in a previous change)
## Changelog
[Android][Fixed] - Sync the Shadow Tree and the Native Tree with Native animation when scroll is driving the animation
Reviewed By: sammy-SC
Differential Revision: D59756577
fbshipit-source-id: e558557b477f4da9da1f89fb31ba86d0ea1390a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45383
This is the second step required to fix the onTouchMove event in the new architecture.
In this change, we are retrieving the list of nodes that are connected by the animation, and we are sending an event to the nodes so that we can trigger the commit.
## Changelog
[iOS][Added] - retrieve the tags of the nodes connected by the animation and send them to JS
Reviewed By: sammy-SC
Differential Revision: D59524617
fbshipit-source-id: 584317afa8e4cf0ad9f98f38e4e5d436c5fe3ac5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45382
This change is the first step to tr and solve the pressability's `onTouchMove` issue with animation driven natively in the New Architecture.
The idea is to trigger a special event from native to let JS know that a scroll event has ended (`scrollViewDidEndDragging` or `scrollViewdidEndDecelerating`).
When this happens, we need to send an event to JS to let him know that it has to sync the Native Tree with the Shadow Tree.
Step 2 is to connect Native with JS
## Changelog:
[iOS][Added] - Send onScrollEnded event to NativeTurboAnimatedModule
Reviewed By: sammy-SC
Differential Revision: D59459989
fbshipit-source-id: cb425cddcdaa9d700ec40accaf4ab3ce1f3c5038
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45478
Some code is far too recursive. This consumes buffer space and causes problems for the Perfetto frontend. Let's limit it to 50 frames.
Changelog: [Internal]
Reviewed By: rubennorte, sammy-SC
Differential Revision: D59813638
fbshipit-source-id: 69068f9c2193d706ec0cc00ffc0d5950ae094e05
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45485
## Changelog:
the new functions I introduced in https://github.com/facebook/react-native/pull/45365 to read color channel value, like `alphaFromColor`, will return float between 0~255 on iOS and 8bit unsigned ints on other platforms, because of different platform implementation. However that way we cannot assume consistent return value across platforms, which kind of contradicts with RN's cross platform design.
so here I make `alphaFromColor` in Color.h (the cross platform method) to always return uint8_t, while still allow `alphaFromHostPlatformColor` to return different result
[Internal] [Fixed] -
Reviewed By: christophpurrer
Differential Revision: D59826142
fbshipit-source-id: 4401918be29980474bdc8601443ae33155710f22
Summary:
FIXES [45404](https://github.com/facebook/react-native/issues/45404)
sending headers from Image component not working in new arch , implementation was missing
```
<Image
source={{
uri: "http://localhost:3000/image",
headers: {
"test-header": 'test',
"hello":"tested"
}
}}
style={{
width: 300,
height: 300,
}}
/>
```
## Changelog:
[IOS] [ADDED]- sending missing **headers** field with **Image** component in fabric
Pull Request resolved: https://github.com/facebook/react-native/pull/45415
Test Plan:
# Tested
Attaching the below video to show how headers are getting received on server from Image component running in new arch
https://github.com/user-attachments/assets/c816265d-0bb5-4670-bde0-cfec72d7618f
Reviewed By: javache, cipolleschi
Differential Revision: D59807462
Pulled By: blakef
fbshipit-source-id: dffa4d80db58de6a81947ac876aa76ec7e62dd48
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45445
Roll our own base64 encoding and revert D59685218, which fixed the missing Folly dependency implied by D54309633.
I assumed Folly base64 was already elsewhere in RN but given it isn't, and we only need simple, non-perf-sensitive encoding for the debugger (not the SIMD or delegated implementations, or decoding), it might be best to just include our own encoder.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D58323859
fbshipit-source-id: 5ce98561e9ced82765e8e7c18e5d2ebfa8148c8c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45426
The initial implementation of `Network.loadNetworkResource` and the accompanying `IO.read` (D54202854) base64-encodes all data as if it is binary. This is the more general case, and we'll continue to base64-encode non-text resources.
In the common case of text resources (particularly JS and JSON), it'd be preferable to do as Chrome does and send UTF-8 over the wire directly. This has a few performance benefits:
- Less CPU and RAM footprint on device (UTF-8 truncation is constant-time, fast, and in-place), similarly less decoding for the frontend.
- 25% less data per chunk (base64 encodes 3 bytes as 4 characters), implies up to 25% fewer network round trips for large resources.
It also has the benefit of being human-readable in the CDP protocol inspector.
## Determining whether data is text
We use exactly Chromium's heuristic for this (code pointers in comments), which is based only on the `Content-Type` header, and assuming any text mime type is UTF-8.
## UTF-8 truncation
The slight implementation complexity here is that `IO.read` requests may specify a maximum number of bytes, and so we must slice a raw buffer up into valid UTF-8 sequences. This turns out to be fairly simple and cheap:
1. Naively truncate the buffer, inspect the last byte
2. If the last byte has topmost bit =0, it's ASCII (single byte) and we're done.
3. Otherwise, look back at most 3 bytes to find the first byte of the code point (topmost bits 11), counting the number of "continuationBytes" at the end of our buffer. If we don't find one within 3 bytes then the string isn't UTF-8 - throw.
4. Read the code point length, which is encoded into the first byte.
5. Resize to remove the last code point fragment, unless it terminates correctly exactly at the end of our buffer.
## Edge cases + divergence from Chrome
Chrome's behaviour here in at least one case is questionable and we intentionally differ:
- If a response has header "content-type: text/plain" but content eg`0x80` (not valid UTF-8), Chrome will respond to an `IO.read` with `{ "data": "", "base64Encoded": false, "eof": false }`, ie an empty string, but will move its internal pointer such that the next or some subsequent `IO.read` will have `"eof": true`. To the client, this is indistinguishable from a successfully received resource, when in fact it is effectively corrupted.
- Instead, we respond with a CDP error to the `IO.read`. We do not immediately cancel the request or discard data, since not all `IO.read` errors are necessarily fatal. I've verified that CDT sends `IO.close` after an error, so we'll clean up that way (this isn't strictly guaranteed by any spec, but nor is `IO.close` after a resource is successfully consumed).
Changelog:
[General][Added] Debugger: Support text responses to CDP `IO.read` requests
Reviewed By: hoxyq
Differential Revision: D58323790
fbshipit-source-id: def8bf8426266f16bb305d836a6efe8927a9dfc4
Summary:
When running the entire unit test suite of `RNTesterPods` with `TSan`, I saw that occasionally a data race was detected on line 843 of `RCTImageLoader`. It seems the completion handler that does contain the lock around `cancelLoad` is called concurrently with the value being assigned on line 843. Here there is no lock in place.
Here is the output of `TSan` when I comment out my fix:
```
WARNING: ThreadSanitizer: data race (pid=72490)
Write of size 8 at 0x000144151ce8 by main thread:
#0 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16e8030)
https://github.com/facebook/react-native/issues/1 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/4 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Previous write of size 8 at 0x000144151ce8 by thread T4 (mutexes: write M0):
#0 __140-[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x16e8894)
https://github.com/facebook/react-native/issues/1 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke <null> (RNTesterUnitTests:arm64+0x16e3430)
https://github.com/facebook/react-native/issues/2 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke_3 <null> (RNTesterUnitTests:arm64+0x16e52a8)
https://github.com/facebook/react-native/issues/3 __75-[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority]_block_invoke_2 <null> (RNTesterUnitTests:arm64+0x7f24)
https://github.com/facebook/react-native/issues/4 -[RCTConcreteImageURLLoader loadImageForURL:size:scale:resizeMode:progressHandler:partialLoadHandler:completionHandler:] <null> (RNTesterUnitTests:arm64+0x6c470)
https://github.com/facebook/react-native/issues/5 __139-[RCTImageLoader _loadImageOrDataWithURLRequest:size:scale:resizeMode:priority:attribution:progressBlock:partialLoadBlock:completionBlock:]_block_invoke.172 <null> (RNTesterUnitTests:arm64+0x16e4964)
https://github.com/facebook/react-native/issues/6 __tsan::invoke_and_release_block(void*) <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x77ee0)
https://github.com/facebook/react-native/issues/7 _dispatch_client_callout <null> (libdispatch.dylib:arm64+0x3974)
Location is heap block of size 48 at 0x000144151cc0 allocated by main thread:
#0 malloc <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x4fa48)
https://github.com/facebook/react-native/issues/1 _malloc_type_malloc_outlined <null> (libsystem_malloc.dylib:arm64+0xf3ec)
https://github.com/facebook/react-native/issues/2 _call_copy_helpers_excp <null> (libsystem_blocks.dylib:arm64+0x10b4)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/5 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/6 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Mutex M0 (0x000108f316e8) created at:
#0 pthread_mutex_init <null> (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x2cc98)
https://github.com/facebook/react-native/issues/1 -[NSLock init] <null> (Foundation:arm64+0x5ca14c)
https://github.com/facebook/react-native/issues/2 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:priority:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df8dc)
https://github.com/facebook/react-native/issues/3 -[RCTImageLoader loadImageWithURLRequest:size:scale:clipped:resizeMode:progressBlock:partialLoadBlock:completionBlock:] <null> (RNTesterUnitTests:arm64+0x16df534)
https://github.com/facebook/react-native/issues/4 -[RCTImageLoaderTests testImageLoaderUsesImageURLLoaderWithHighestPriority] <null> (RNTesterUnitTests:arm64+0x7cb8)
https://github.com/facebook/react-native/issues/5 __invoking___ <null> (CoreFoundation:arm64+0x13371c)
Thread T4 (tid=10935088, running) is a GCD worker thread
```
## Changelog:
[iOS][Fixed] Data race in `RCTImageLoader` related to assignment of cancellation block.
Pull Request resolved: https://github.com/facebook/react-native/pull/45454
Test Plan: There are already tests in place for `RCTImageLoader`. I hope these will cover the fix.
Reviewed By: realsoelynn
Differential Revision: D59816000
Pulled By: zeyap
fbshipit-source-id: f959d472eb60f83f39ced6711ee395949ab37e7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45469
Enables React Native DevTools by default on `main`, ahead of the 0.76 release. We've observed no new bug reports internally over the last two weeks, and are moving forward with our rollout plan.
Changelog: [Internal]
Reviewed By: blakef
Differential Revision: D59804882
fbshipit-source-id: 0cb6302f4d940718786db2e5d8fb652fae6a8c54
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45463
Changelog: [Internal]
State updates will clone shadow nodes for an shadow tree revision that is outdated.
This can lead to accessing deallocated shadow node references because the JS renderer committed a newer revision and deallocated the one used by the pending state update.
By using a weak pointer to hold a reference to the runtime shadow node reference, we can only update references for wrappers that are still valid.
Reviewed By: javache
Differential Revision: D59804999
fbshipit-source-id: 89c9967d139d3cac7d7252994beae419bc591e79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45413
## Changes
Add an example in RNTester to test that pressability with NativeDrivers works properly.
## Context
The pressability handling is a bit peculiar.
We have to handle 3 main behaviors:
* `PressIn` -> `PressOut` => triggers the `onPress`
* `PressIn` -> move inside the rectangle -> `PressOut` => triggers the `onPress`
* `PressIn` -> move outside the rectangle -> `PressOut` => cancel `onPress`.
For the first case, we detect whether the press happens inside a component in the Native layer only. And everything works.
When a move is involved, we:
1. Detect the initial press in the Native layer
2. We move the coursor and we delegate the detection of whether we are inside of a rect or not to the JS layer
3. The JS layer asks the C++ layer about the layout and decide whether we are in case 2 (move but still inside the rect) or in case 3 (move but outside the rect).
The problem is that with `nativeDriver` and animations, the C++ layer doesn't know about where the receiver view actually is.
This results in issues like the one shown by [#36504](https://github.com/facebook/react-native/issues/36504), where the onMove is not handled correctly.
## Solution
The solution is to keep detecting whether we are in the receiver view or not in the Native layer and pass the receiver view position and size back to JS so that the JS layer don't have to jump to C++ to make this decision.
We decided to pass the frame information because the JS layer is adding some padding and configurations to the final rectangle and we don't want to lose those configurations.
## Changelog
[General][Added] - Add example in RNTester to show that pressability works properly with NativeDrivers
Reviewed By: sammy-SC
Differential Revision: D58182480
fbshipit-source-id: 9ca4fb9a3ca1a8af52ccbe208cbfe8434175f87d
Summary:
CCI on main is broken. We suspect that's due to cache issues which restore a wrong layout for the Folly pod.
This PR is an attempt to fix it
## Changelog:
[Internal] - Fix missing folly base 64
Pull Request resolved: https://github.com/facebook/react-native/pull/45460
Test Plan: CCI and GHA are green
Reviewed By: sammy-SC, huntie
Differential Revision: D59804748
Pulled By: cipolleschi
fbshipit-source-id: 44d6b169cf3319f4d7ee9e0a5833f07bc6ba4bb3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45458
Checking for packager is an async operation, which may return when we've already destroyed the ReactInstanceManager. Prevent the CatalystInstance from being created if the ReactInstanceManager has been invalidated.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59753247
fbshipit-source-id: e3ac2b6dd142330e2d4051519b9863584b33f8a6
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45448
changelog: [internal]
I would like to experiment with executing insert mount instructions after layout and state update. It has shown small improvement in local testing
Reviewed By: mdvacca
Differential Revision: D59582123
fbshipit-source-id: 3ee6ec12a533a287ed32f7373863175f3a107548
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45410
changelog: [internal]
For better performance, let's test setting up the animation graph from passive effects. This will delay the work, not blocking the paint.
Reviewed By: rubennorte
Differential Revision: D59644374
fbshipit-source-id: ff951ee7c1a1d47e13c55fc7c7f6c0690aa465f7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45444
## Changelog:
[Internal] -
Even though `ScrollView.scrollIndicatorInsets` isn't supported on the vanilla Android platform, it still may be used on some other variations of it, which means that the changes may not potentially find the way into C++/Fabric, opening a door of all kinds of weird corner case issues.
Reviewed By: christophpurrer
Differential Revision: D59761458
fbshipit-source-id: 4dae5c96791ca924d589a3d803d8fa60fdca1b67
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45304
Add support for most keyword values of mix-blend-mode on iOS and added RNTester Example
Missing compositing operators and global values
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D59402969
fbshipit-source-id: b7e1aaed01fbf8f80e04ad0fa73d2ef63b5ad933
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45306
Adding missing drop-shadow test to rn-tester.
Added with alpha-hotdog image to show we are creating the shadow with the alpha channel of the view.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D59410148
fbshipit-source-id: 5a03ee84313979f99585b8ca7e07abf9cdbe2396
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45443
We are only building these out for Fabric. This means only one natural iOS impl, but that other Android bits will not work fully correctly on Paper (like setting containing block for filter element). This also means we can remove view configs once we're on Fabric CSS parser. We will do the same for boxShadow once that is ready.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D59762282
fbshipit-source-id: 14ce07f04b822c6aee908894c9081419594fc484
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45421
RNTester contains Android resources that are loaded by name and not resolved by Metro. As a result, these assets are not automatically linked when RNTester JS code is embedded in other projects. This is considered "legacy" loading and is generally discouraged, but is still showcased as an alernative way of loading resources.
I also modified the Image test to ensure that flag status is printed so it's obvious why the vector drawable hasn't loaded.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D59585555
fbshipit-source-id: d42fb44d8846d8e7c7aa01dca4cec89ae85a9195
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45442
This deprecates also `DeveloperSettings.isStartSamplingProfilerOnInit`
so we can remove it in a future version of React Native.
This field is unused so you should not be using it at all.
Changelog:
[Android] [Changed] - Deprecate DeveloperSettings.isStartSamplingProfilerOnInit
Reviewed By: blakef
Differential Revision: D59757500
fbshipit-source-id: dc879ba46f2f937e5f259a4101646c2f060db548
Summary:
## Summary
Now that HostContext determination for Fabric is a DEV-only behavior, we
can move the HostContext determination to resolve from the ViewConfig
for a given type. Doing this will allow arbitrary types to register
themselves as potential parents of raw text string children. This is the
first of two diffs for react as we'll:
1. Add the new property to the ViewConfig types
2. Update React Native to include the `supportsRawText` property for
`RCTText`, `RCTVirtualText`, `AndroidTextInput`, etc.
3. Switch the behavior of react to read from the ViewConfig rather than
a static list of types.
Changelog: [Internal]
## Test Plan
- yarn test
- yarn test --prod
- Pulled change into react-native, added `supportsRawText` props to
RCTText, RCTVirtualText, etc. ViewConfigs and confirmed everything type
checks.
DiffTrain build for commit https://github.com/facebook/react/commit/a5cc797b8801dfe58c7a34c99a9fa60c6c9c8274.
bypass-github-export-checks
Reviewed By: poteto
Differential Revision: D59641180
Pulled By: rozele
fbshipit-source-id: a3ddb1bc810a70d5f782e708cb845e3eae136d78
Alex Taylor (alta)
zhongwuzw
Alexander Blom
Oskar Kwaśniewski
Samuel Susla
Rubén Norte
Blake Friedman
Nicola Corti
Riccardo Cipolleschi
Nick Gerleman
Joe Vilches
Thomas Nardone
Blake Friedman
Pieter De Baets
Zeya Peng
Deepanshu.shukla
Rob Hogan
Andrew Coates
Håkon Knutzen
Alex Hunt
Nick Lefever
shubhamguptadream11
Ruslan Shestopalyuk
generatedunixname89002005232357
Peter Abbondanzo
rozele (Meta Employee)