Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48182
Maintainers from SVG reached out because of an edge case they inencountered when generating the ComponentProvider. In their setup, they had a `.git` folder in the repo and the algorithm was spending a lot of time crawling the git folder.
In general, we should avoid crawling hidden folders.
This change fix that.
## Changelog:
[General][Fixed] - Skip hidden folders when looking for third party components.
Reviewed By: javache
Differential Revision: D66959345
fbshipit-source-id: 992a79f3cff22cd6a459e0272c8140bc329888da
Summary:
Fixes an [issue](https://github.com/facebook/react-native/issues/48168) where only iOS configurations with "Debug" in the name are configured to use the hermes debugger.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[IOS] [FIXED] - Enable hermes debugger by configuration type instead of configuration name
Pull Request resolved: https://github.com/facebook/react-native/pull/48174
Test Plan:
Added new test scenarios that all pass:
```
ruby -Itest packages/react-native/scripts/cocoapods/__tests__/utils-test.rb
Loaded suite packages/react-native/scripts/cocoapods/__tests__/utils-test
Started
Finished in 0.336047 seconds.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
56 tests, 149 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
166.64 tests/s, 443.39 assertions/s
```
In a personal project with the following configurations:
```
project 'ReactNativeProject', {
'Local' => :debug,
'Development' => :release,
'Staging' => :release,
'Production' => :release,
}
```
I added the following to my Podfile:
```
installer.pods_project.targets.each do |target|
target.build_configurations.each do |config|
puts "#{config.name} is debug? #{config.type == :debug}"
end
end
```
To confirm that my logic is correct:
```
Local is debug? true
Development is debug? false
Staging is debug? false
Production is debug? false
```
Reviewed By: robhogan
Differential Revision: D66962860
Pulled By: cipolleschi
fbshipit-source-id: 7bd920e123c9064c8a1b5d45df546ff5d2a7d8be
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48225
Fixes https://github.com/facebook/react-native/issues/47762
The weak event emitter in AttributedString attributes is causing a serialization error when typing into a TextInput in a Mac Catalyst build. We can resolve this by not putting the event emitters in the attributed string, but this is likely to cause other issues with event handling for nested <Text> components.
## Changelog
[iOS][Fixed] - Workaround for Mac Catalyst TextInput crash due to serialization attempt of WeakEventEmitter
Reviewed By: NickGerleman
Differential Revision: D66664583
fbshipit-source-id: efdfbcb0db4d5e6b9bf7c14f9bbb221faae2d724
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48145
While writing the docs for 0.77, I found an edge case in the generation of the RCTThirdPartyComponentProvider:
* If the app has the `codegenConfig` field set in the `package.json`
* And it does not have the `ios.componentProvider` field is not provided
Codegen was generating the mapping for the react-native core components. That's not expected as, in that case, it should only generate components that are declared in the app or in libraries.
This change fixes this edge case.
## Changelog:
[Internal] - Exclude mapping generation of core component
Reviewed By: blakef
Differential Revision: D66875080
fbshipit-source-id: 65fe10381729ec7808efec70feacf2a55f0056e9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48132
Backs out D63573322 and D65645981, reverting the change that makes callbacks passed to `animation.start(<callback>)` scheduled for execution in a microtask.
This is being reverted becuase the latency introduced by the current macro and pending micro tasks can introduce visible latency artifacts that diminish the fidelity of animations.
Changelog:
[General][Changed] - Reverts #47503. (~~Callbacks passed to `animation.start(<callback>)` will be scheduled for execution in a microtask. Previously, there were certain scenarios in which the callback could be synchronously executed by `start`.~~)
Reviewed By: javache
Differential Revision: D66852804
fbshipit-source-id: 08434b9876813fe9e8b189b6b467198933843bf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48124
Fixes https://github.com/facebook/react-native/issues/47592
The logic in HeadlessJsTaskService is broken. We should not check whether `getReactContext` is null or not.
Instead we should use the `enableBridgelessArchitecture` feature flag to understand if New Architecture was enabled or not.
The problem we were having is that `HeadlessJsTaskService` was attempting to load the New Architecture even if the user would have it turned off. The Service would then die attempting to load `libappmodules.so` which was correctly missing.
Changelog:
[Android] [Fixed] - Fix crash on HeadlessJsTaskService on old architecture
Reviewed By: javache
Differential Revision: D66826271
fbshipit-source-id: 2b8418e0b01b65014cdbfd0ec2f843420a15f9db
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48090
This alleviates a breaking change on `ReactModuleInfo` constructor.
While the ctor was deprecated, we realized that there are more than 250 usages in OSS.
We'll need to properly communicate this removal before we do it.
Changelog:
[Android] [Fixed] - Re-introduce the deprecated constructor on ReactModuleInfo
Reviewed By: cipolleschi
Differential Revision: D66755541
fbshipit-source-id: 3673d8f2af278d55491cea89f1594d368513e3d8
Summary:
GHA to build HermesC for windows are failing because the machines comes with a different CMake version already.
Let's try not to install Cmake and use the one provided by the machine.
## Changelog:
[Internal] -
Pull Request resolved: https://github.com/facebook/react-native/pull/48122
Test Plan: GHA {F1973187648}
Reviewed By: alanleedev
Differential Revision: D66825216
Pulled By: cipolleschi
fbshipit-source-id: 9a9376a5409e192195a6b6cc25b4d58cb47f15da
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/48039
This class was removed in D66127067 but was marked as DeprecatedInNewArchitecture and not Deprecated, which limited the signal we gave to developers to move away from this.
Restore for now to e
Changelog: [Android][Fixed] Reverted removal of TurboReactPackage
Reviewed By: rshest
Differential Revision: D66648209
fbshipit-source-id: 165f9390b4874e69353612b929d87b0c495588af
Summary:
building RN tester with 0.77 rc-0 doesn't work now because of `java.io.IOException: No such file or directory` on line 48.
`buildDirectory` is a Gradle property representing a file
https://github.com/facebook/react-native/pull/47552 removes this file altogether so feel free to close if that one is the "right one"
## Changelog:
[ANDROID] [FIXED] - fix IOException in `BuildCodegenCLITask`
Pull Request resolved: https://github.com/facebook/react-native/pull/48008
Test Plan: After this change, building RN tester works.
Reviewed By: cortinico
Differential Revision: D66650038
Pulled By: robhogan
fbshipit-source-id: 11cd83493fa118c6b79d11c9113228dd3971a803
Summary:
https://github.com/facebook/react-native/pull/46385 introduced use of `Object.hasOwn` as an incidental detail of some `Animated` performance improvements.
Unfortunately, `Object.hasOwn` is not present in the version of JSC shipped with Android, nor the built in iOS JSC until iOS 15.4, which is greater than React Native's minimum version (13.4).
Instead:
- Use `obj.hasOwnProperty(prop)` for known objects that have the `Object` prototype.
- Otherwise, use `Object.hasOwn` where it is defined.
- Lastly, fall back to `Object.prototype.hasOwnProperty.call(obj, prop)`, which is compatible with passed `null`-prototype objects.
Fixes https://github.com/facebook/react-native/issues/47963
Intend to pick for RN 0.77.
## Changelog:
[GENERAL][FIXED] Replace Object.hasOwn usages to fix Animated on JSC
Pull Request resolved: https://github.com/facebook/react-native/pull/48035
Test Plan:
- Run `rn-tester` on Android with Hermes disabled.
- Verify the FlatList->Basic example redboxes before this change, and works after it.
Reviewed By: yungsters
Differential Revision: D66638379
Pulled By: robhogan
fbshipit-source-id: 51ac525851b41adea3bf3cc41349225138e1f2fe
Summary:
This Pull Request fixes a regression introduced in https://github.com/facebook/react-native/commit/7c7e9e6571c1f702213e9ffbb40921cd5a1a786b, which adds a `filename*` attribute to the `content-disposition` of a FormData part. However, as the [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition#directives) states, there is no `filename*` attribute for the `content-disposition` header in case of a form data.
The `filename*` attribute would break the parsing of form data in the request, such as in frameworks like `Next.js` which uses the web implementation of [`Request`](https://developer.mozilla.org/en-US/docs/Web/API/Request).
Fixes https://github.com/facebook/react-native/issues/44737
## 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
-->
[General] [Fixed] - Remove non compliant `filename*` attribute in a FormData `content-disposition` header
Pull Request resolved: https://github.com/facebook/react-native/pull/46543
Test Plan:
- Clone the `react-native` repo
- Create a simple JS file that will act as a node server and execute it
```javascript
const http = require('http');
const server = http.createServer(async function (r, res) {
const req = new Request(new URL(r.url, 'http://localhost:3000'), {
headers: r.headers,
method: r.method,
body: r,
duplex: 'half',
});
const fileData = await req.formData();
console.log(fileData);
res.writeHead(200);
res.end();
});
server.listen(3000);
```
- Go to `packages/rn-tester`
- Add a `useEffect` in `js/RNTesterAppShared.js`
```javascript
React.useEffect(() => {
const formData = new FormData();
formData.append('file', {
uri: 'https://www.gravatar.com/avatar',
name: '测试photo/1.jpg',
type: 'image/jpeg',
});
fetch('http://localhost:3000', {
method: 'POST',
body: formData,
}).then(res => console.log(res.ok));
});
```
- Run the app on iOS or Android
- The node server should output the file added to the FormData with an encoded name
Reviewed By: robhogan
Differential Revision: D66643317
Pulled By: yungsters
fbshipit-source-id: 0d531528005025bff303505363671e854c0a2b63
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47950
`addInArray` may reallocate `mAllChildren` so it's not correct to store this reference.
Changelog: [Internal]
Reviewed By: tdn120
Differential Revision: D66474532
fbshipit-source-id: 90ce2fcbf8ff236501ed47b2acc413e54ef8b82a
Summary:
Removed `node-fetch` in favour of node builtin fetch to get rid of the deprecated `punycode` warning when using Node 22.
`react-native/community-cli-plugin` already requires Node >= 18 where it was made available by default (without `--experimental-fetch` flag).
This change is similar to the one made in https://github.com/facebook/react-native/pull/45227
## Changelog:
[GENERAL] [CHANGED] - Drop node-fetch in favor of Node's built-in fetch from undici in `react-native/community-cli-plugin`
Pull Request resolved: https://github.com/facebook/react-native/pull/47397
Test Plan: tests pass
Reviewed By: blakef
Differential Revision: D66512595
Pulled By: NickGerleman
fbshipit-source-id: c4e01baf388f9fae8cea7b4bfe25034bff28b461
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47895
X-link: https://github.com/facebook/yoga/pull/1750
These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66332307
fbshipit-source-id: 1d596964e0c893091c541988506e8b80fa6d1957
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47896
X-link: https://github.com/facebook/yoga/pull/1752
These APIs were only added so that we could do TDD as we work on intrinsic sizing functionality. As of right now they do nothing. We are aiming on publishing a new version of Yoga soon so for the time being we are going to back these out so as not to confuse anyone with this new functionality. Ideally we get to a point where we have some temporary experimental header to stage these in but this is a bit time sensitive so just backing out for now
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D66332309
fbshipit-source-id: 793f77dad021fa5e57b52c36ae954307636bcbf0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47336
Before mix-blend-mode would not blend with the background color due to it not being a ViewGroup. This adds the mix-blend-mode logic to ReactRootView so blending works
Changelog:
[Android][Fixed] - Enable mix-blend-mode on ReactRootView so blending works with app background
Reviewed By: NickGerleman
Differential Revision: D65156543
fbshipit-source-id: b3628b667573d0b56c74214e40d21c656fda495a
Summary:
I was just going through the README file, and I felt that the word "repo" seems a bit informal. Thus I made the correction and made it "repository".
## Changelog:
[General] [Changed] - Fixed a typo in the README file.
Pull Request resolved: https://github.com/facebook/react-native/pull/47918
Test Plan: No specific Test Plan for these changes, as it is just a typo fix in README.md
Reviewed By: fkgozali
Differential Revision: D66414686
Pulled By: arushikesarwani94
fbshipit-source-id: 578530d2dcdf046a90bf5a5bc32ba68e8f496c81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47914
This was a bug in the original diff: D66193194.
If a fatal js error happens, we should only drop subsequent **fatal** js errors. It's fine to report soft errors.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D66392706
fbshipit-source-id: c51bae186184c54faa9bce065b81b442607e751b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47747
Deprecate NotThreadSafeViewHierarchyUpdateDebugListener as won't be available in new arch and will be deleted
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216730
fbshipit-source-id: 88f3346ad38b80a710d9df4ba08b63887048c8cd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47746
Remove DeprecatedInNewArchitecture annotation from ReactPropGroup since this annotation is not deprecated in new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216727
fbshipit-source-id: 252bae58557b51c9fbfb1deab4edc7c50511a005
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47745
Remove DeprecatedInNewArchitecture for ReactPropHolder annotation
ReactProp is still used in new arch, we might remove this annotation in the future but it will be independent of new arch
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D66216729
fbshipit-source-id: 3f64858ab4fa60b09978b18b17200ae488e229ce
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47910
It seems there could be a race where a commit is being processed on the JS thread after the surface has been removed from the mounting manager. Since we don't actually need to retrieve the default paddings in these cases, there's no reason we need an enforced read of the SurfaceMountingManager.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D66369969
fbshipit-source-id: 44ccdc9beafdbd0ac47457fb01c4114348c1a316
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47891
Various C++ utilities for handling callbacks and promises rely on the static LongLivedObjectCollection. Even if a host platform injects it's TurboModuleBinding with a custom LongLivedObjectCollection, there's no guarantee that the platform is not also using C++ TurboModules that use the static LongLivedObjectCollection. Clearing both collections solves issues for TurboModuleBindings with custom LongLivedObjectCollections that also have cross platform C++ TurboModules that use the static collection.
## Changelog
[Internal]
Reviewed By: javache
Differential Revision: D66324044
fbshipit-source-id: a5a973087c35fc00240e40ba757d49125473daf4
Summary:
Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/47907
EnableDevSupport is set to false on lifecyle events like onPause and onHostDestroy, and set to true on events like onResume and onCreate.
In apps like AMA and Twilight, there is first a loginActivity, which then calls the mainActivity. After mainActivity is created, loginActivity is destroyed. This causes enableDevSupport to always be false because onDestroy for loginActivity is triggered after onCreate for mainActivity.
Reviewed By: RSNara, alanleedev
Differential Revision: D66124018
fbshipit-source-id: e40a5b24cf73000b0bfeaa1d8e3902718b281410
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47897
Changelog: [Internal]
In some situations, we want to provide multiple `CxxReactModules` from a single lambda. Currently, this is painful -- this change makes it less so.
Reviewed By: tdn120
Differential Revision: D66337573
fbshipit-source-id: ed57ad6ca2b98d4787aca7da3714c05c3d03b649
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47908
Changelog: [General][Added] - Add support for `rn_rootThreshold` in Intersection Observer
`rn_rootThreshold` is a custom IntersectionObserver option and not part of the IntersectionObserver spec. We are adding it because it covers a specific use-case for measuring viewability that is robust for `target`s that are larger than the viewport or specified `root`.
The threshold ratio is of the intersection area (of `root` and `target`) to the total area of the `root`.
{F1960832959}
Source - EX314979
`rn_rootThreshold` is an optional threshold and can be combined with the `thresholds` option. An intersection will fire if any specified thresholds is met.
Note: If you use specify a `rn_rootThreshold`, the default `threshold` is no longer applied
The main use case of `rn_rootThreshold` is being able to specify a level of viewability independent of `target` size. For example, a `target` that is larger than the `root` (commonly the viewport) will not trigger the IntersectionObserver for a `threshold` of `1`. Setting `rn_rootThreshold` of `1`, will trigger once the item takes full size of the `root`.';
Reviewed By: yungsters
Differential Revision: D66031119
fbshipit-source-id: 7bdc871dc5b4e6c0edc7d6e17a0a0cfd51c4fe81
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47878
Make it clearer what we're checking, and provide a single point of code where we could potentially improve the logic.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D66302526
fbshipit-source-id: a0e6d1004aef25897e9633fe930915ba585c1cb5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47674
Small changes that can be done in Java and make a Kotlin conversion more seamless.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D66033963
fbshipit-source-id: 666302f132b98019f1013a335a2c59c7a4f31836
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47880
The previous diffs in this stack have aimed to make URL rewriting by inspector-proxy robust to any configuration of device->server, debugger->server and server->server connections.
Though rewriting was originally introduced to support Android emulator networking, we can now expand it to cover other use cases, like the device reaching the server over an internet address not reachable from the dev machine, or the debugger routing to the server through a tunnel on a different port, without needing CORS workarounds.
Changelog
[General][Fixed] dev-middleware: Rewrite URLs in the inspector proxy to cover all configurations, not just Android emulators.
Reviewed By: huntie
Differential Revision: D66247355
fbshipit-source-id: e9201ebc1f7f5fe2119c71cd4d7b4ca895645404
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47681
These were deprecated back in D49262824, so should be safe to remove now.
Changelog: [Android][Removed] Removed hasConstants constructor from ReactModuleInfo
Reviewed By: mdvacca
Differential Revision: D66127070
fbshipit-source-id: 3bd441c96597598470f16c7770c4dfa4ada563a0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/47680
This was deprecated in D50128456 so should be safe to remove now.
Changelog: [Android][Removed] Removed TurboReactPackage, which was replaced by BaseReactPackage
Reviewed By: mdvacca
Differential Revision: D66127067
fbshipit-source-id: a4090ab439cf99dc693622b8da2c0cffa247ad24
Summary:
Fixes the high contrast color when not specified. Previously, if we didn't specify highContrastLight or highContrastDark, it would create a UIColor with an alpha of 0, which is not what we expected. We should fall back to the dark or light color instead.
## Changelog:
[IOS] [FIXED] - Fabric: Fixes high contrast color when not specified
Pull Request resolved: https://github.com/facebook/react-native/pull/47418
Test Plan:
1. Enable color contrast in iPhone's settings.
2. Open PlatformColor example in RNTester. See dynamic colors
3. color shows correctly
Before:
Reviewed By: javache
Differential Revision: D66303078
Pulled By: cipolleschi
fbshipit-source-id: 63a0d2bc94eea438d4f69643d09825b74575188b
Summary:
Attempting to use the various bridging template and generated C++ Specs for native modules in a project compiling with MSVC does not build.
For the fromJs I had to add `std::move` - otherwise it could not cast.
The supportsFromJs and supportsToJs are changed to address an IntelliSense issue where the template specialization cannot have default members.
## Changelog:
[GENERAL] [FIXED] - Fix C++ bridging template compatibility with MSVC
Pull Request resolved: https://github.com/facebook/react-native/pull/47882
Test Plan: It continues to build on Android/iOS builds. And it also builds with MSVC for react-native-windows and other out of tree platforms that use MSVC.
Reviewed By: cipolleschi
Differential Revision: D66360833
Pulled By: javache
fbshipit-source-id: bf97db1cd247a383eb86cac31c601e8ab3400fd2
Riccardo Cipolleschi
Ben Handanyan
Eric Rozell
Blake Friedman
React Native Bot
zhongwuzw
Tim Yung
Nicola Corti
Rob Hogan
Alex Hunt
Pieter De Baets
Vojtech Novak
Hugo FOYART
Jakub Romanczyk
Joe Vilches
Jorge Cabiedes Acosta
Aryan Dev Shourie
Panos Vekris
Ramanpreet Nara
David Vacca
Thomas Nardone
Maddie Lord
Tom Scallon
Luna Wei
Rob Hogan
Andrew Coates