Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45529
`experimental_boxShadow` is not yet part of Android view managers, and when we enable it, we are likely to do a view manager at a time before moving to BaseViewManager.
This causes user-visible errors when viewconfig validation is turned on, since we have a static view config, but not yet a native view config.
This removes the static viewconfig for Android until we start adding setters to view manager.
It is kept in `ReactNativeStyleAttributes` (which I think can have members not in the native view-config, since it has component specific props like tintColor), and iOS base viewconfig. On Fabric iOS, this is part of BaseViewProps, and handled by RCTView, but it looks like the prop (and also `experimental_filter`, `experimental_mixBlendMode`) do not have entries in iOS RCTViewManager, which is fixed in next diff in the stack.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D59939866
fbshipit-source-id: 2781029a0c29ba111ed04edfe9940c6c72f4e5ac
Summary:
Viewconfig processors may still get called for nullish values I think. Most other processors explicitly handle these (but some don't??).
This returns an empty list, like on parse error, when we have a value, but the value is nullish.
Changelog: [Internal]
Reviewed By: joevilches
Differential Revision: D59933611
fbshipit-source-id: 3f1d89d21977bbe01a05e708aadf1a9451d88083
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:
Factor out the Build NPM package job in a separate action for code reuse
## Changelog:
[Internal] - Factor out the Build NPM package job in a separate action for code reuse
Pull Request resolved: https://github.com/facebook/react-native/pull/45493
Test Plan: GHA are green
Reviewed By: robhogan
Differential Revision: D59858572
Pulled By: cipolleschi
fbshipit-source-id: 561a215ba5812352034157aa254999db56fcd31e
Summary:
With the recent changes to the CI, we need to update the test-e2e-local to work with the new artifacts
## Changelog:
[Internal] - Update local-e2e-test to run with the new Android Artifacts
Pull Request resolved: https://github.com/facebook/react-native/pull/45499
Test Plan: Tested locally.
Reviewed By: blakef
Differential Revision: D59902087
Pulled By: cipolleschi
fbshipit-source-id: 84ef78e8dba222bf8a9e3620632fb2a9d286d42b
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:
This change adds a job that runs 2 hours after the nightlies. This jobs returns successfully if the nightly has been published or it report an error in case it has failed.
We will hook this signal to the internal system to be notified about Nightlies failures
## Changelog:
[Internal] - Add jobs to check for nightlies
Pull Request resolved: https://github.com/facebook/react-native/pull/45509
Test Plan: Test the Action on GHA
Reviewed By: blakef
Differential Revision: D59907442
Pulled By: cipolleschi
fbshipit-source-id: 3b35aa2ad69b376c65a765f740a1d6e6ed8ad99f
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/45508
The scripts/clean-gha-cache.js uses the `gh` cli too, which expects the GITHUB_TOKEN presented GH_TOKEN. Also allowed us to manually kick off this workflow.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D59901639
fbshipit-source-id: f3543cc83cbf67b6969abc3390790e038e06c305
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/45334
Adds support for the `xml` file extension as a loadable asset, and lets Flow treat the type signature as an image
Changelog: [Internal]
Reviewed By: robhogan
Differential Revision: D58261501
fbshipit-source-id: b29cffee81d0438827529711e86267edd5d2a0f7
Summary:
I'm picking 1630b5c743 in main as it's currently missing (available only on `0.75-stable`).
## Changelog:
[INTERNAL] - Update testing scripts to work with any version of React native
Pull Request resolved: https://github.com/facebook/react-native/pull/45498
Test Plan: Nothing to test as this is a backport
Reviewed By: cipolleschi
Differential Revision: D59861440
Pulled By: cortinico
fbshipit-source-id: 57f642c66c7a6976f5a5cd53debaeb2e461a1f30
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/45495
Unify type definitions to semver@7, to fix a [type-sync](https://www.internalfb.com/intern/test/281475050813096/) test that was broken by D59378011. The test is very simple and doesn't actually understand the typing.
I don't believe there is a significant difference in the typing, esp. with how we're using it. Flow will tell us if this is the case though (🏖️🏰).
Changelog: [Internal]
Reviewed By: huntie
Differential Revision: D59855434
fbshipit-source-id: ae3c6b7aa81b3cde25468d72a7922bcb2b6f652f
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/45474
Our actions inputs are now a mixture of different casing.
I'm moving everything to be kebab-case
Changelog:
[Internal] [Changed] - Composite actions inputs should be kebab-case
Reviewed By: cipolleschi
Differential Revision: D59809181
fbshipit-source-id: af6d541c2b4f5fa162dcde412fb8808bae1ef2d3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45480
We currently use the default GITHUB_ACTION which makes a lot of interaction
appear as user "GitHub Actions". Instead we could use the `REACT_NATIVE_BOT_GITHUB_TOKEN`
which we have as secret so the bot will actually perform the actions.
Changelog:
[Internal] [Changed] - Act as react-native-bot on all the actions
Reviewed By: cipolleschi
Differential Revision: D59815201
fbshipit-source-id: 702b121ec07d0db10abf25e23f7ddf5658dd5d62
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/45491
The build_android job was missing the sonatype credentials so could not
publish a -SNAPSHOT version. This fixes it.
Changelog:
[Internal] [Changed] - Unbreak nightlies by fixing secrets
Reviewed By: cipolleschi
Differential Revision: D59848810
fbshipit-source-id: 2cc1d03b090d0aeb3886590ec0696f9c3a6556b9
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/45468
This should greatly reduce the time spent on build_npm_package
because we're moving all the publishing logic to build_android.
I need to do a bit more testing with nightlies to make sure that everything is published correctly.
Changelog:
[Internal] [Changed] - Make build_android publish to the stating repositories
Reviewed By: cipolleschi
Differential Revision: D59804015
fbshipit-source-id: be3f0b6e16f5fdbf760ec7a5e16c8e258e06dd28
Summary:
The `LinkingModule.getInitialURL` method is declared as returning a `Proimise<string>` but looking at the implementation it can also return null:
a96272e27e/packages/react-native/Libraries/LinkingIOS/RCTLinkingManager.mm (L166)
which is returned by
a96272e27e/packages/react-native/Libraries/Linking/Linking.js (L96)
which happens to expand the type to the correct type for most external users.
React-native-window's turbomodule codegen is more type strict, and so cannot return null with the current spec.
## Changelog:
[INTERNAL] [FIXED] - Use more accurate type in LinkingManager spec file
Pull Request resolved: https://github.com/facebook/react-native/pull/45450
Test Plan:
Type change only, so should only affect build time change which will be caught by CI.
Have verified that this type change allows react-native-windows to return null.
Reviewed By: robhogan
Differential Revision: D59816089
Pulled By: zeyap
fbshipit-source-id: 9810f150ce84b503883e72b1f29518d2e62258b6
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/45479
This just prints a summary on PRs if the Gradle task fails so it's easier to jump directly
to the failure.
Changelog:
[Internal] [Changed] - Enable add-job-summary-as-pr-comment for failed jobs
Reviewed By: cipolleschi
Differential Revision: D59812845
fbshipit-source-id: 2069a1c8db7d264ca1af3c1182fa443cb0a69646
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
