Summary:
Set the proper build flags for debugging in Bridgeless mode.
This fixes [#44240](https://github.com/facebook/react-native/issues/44240)
## Changelog:
[iOS][Fixed] - Add `HERMES_ENABLE_DEBUGGER=1` flag to React-RuntimeApple
Reviewed By: cortinico
Differential Revision: D56575647
fbshipit-source-id: a0613a5d46caeb1d3e636e54ecd43428fbaf46e8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/44185
This change will fix a symbol not found for JSC Runtime.
The `if` check was not a compile time check, therefore the symbol ended up in the binary even if it is not available.
Following this post on [Apple forum](https://forums.developer.apple.com/forums/thread/749534), this changes should do the trick.
## Changelog
[iOS][Fixed] - Fix Symbol not found: (_JSGlobalContextSetInspectable)
Reviewed By: hash3r
Differential Revision: D56425834
fbshipit-source-id: a37af51b078bd47a938e6b65d9d8e0f7506e746f
Summary:
Changelog: [iOS][Added]
this creates the RN privacy manifest in the ios build step if user has not created one yet. the reasons have been added for the following APIs:
NSPrivacyAccessedAPICategoryFileTimestamp
- C617.1: We use fstat and stat in a few places in the C++ layer. We use these to read information about the JavaScript files in RN.
NSPrivacyAccessedAPICategoryUserDefaults
- CA92.1: We access NSUserDefaults in a few places.
1) To store RTL preferences
2) As part of caching server URLs for developer mode
3) A generic native module that wraps NSUserDefaults
NSPrivacyAccessedAPICategorySystemBootTime
- 35F9.1: Best guess reason from RR API pulled in by boost
Reviewed By: cipolleschi
Differential Revision: D53687232
fbshipit-source-id: 6dffb1a6013f8f29438a49752e47ed75c13f4a5c
Summary:
This allows build configuration named like `StagingDebug` to match with settings applied to `Debug` This fixes https://github.com/facebook/react-native/issues/43185
Custom build setting were only applied to `Debug` build configurations, preventing configurations named `StagingDebug` or similar to access the new experimental debugger, as reported in https://github.com/facebook/react-native/issues/43185
This now applies the setting to every configuration ending with `Debug`
## Changelog:
[IOS] [CHANGED] - fix: build settings for custom build configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/43780
Reviewed By: dmytrorykun
Differential Revision: D55688996
Pulled By: cipolleschi
fbshipit-source-id: 1f34cd722f6acfaa08d3377e19a04d08af97ed7c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/43563
Fixes https://github.com/facebook/react-native/issues/42874
## Sumary
D9405703 added some custom logic for Flings, to support FlatList scenarios where content is being added on the fly, during Fling animation. This works by allowing start Fling to not have bounds, then correcting/cancelling Fling when overscroll happens over a bound that would normally be allowed.
This has some math to try to determine max content length, and will clamp to this when scrolling over it. This logic is incorrect when content length is less than scrollview length, and we end up snapping to a negative offset.
This change adds clamping, so that we don't snap to negative position in horizontal scroll view. This clamping was already indirectly present on vertical scroll view. https://www.internalfb.com/code/fbsource/[b43cdf9b2fec71f5341ec8ff2d47e28a066f052e]/xplat/js/react-native-github/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/views/scroll/ReactScrollView.java?lines=609
## Test Plan
Above issue no longer reproes. Flinging while content is being added to horizontal FlatList still works correctly.
Changelog:
[Android][Fixed] - Fix Android HorizontalScrollView fling when content length less than ScrollView length
Reviewed By: javache
Differential Revision: D55108818
fbshipit-source-id: 7cf0065f9f92832cc2606d1c7534fc150407b9c9
Summary:
Problem Causes: In ReactViewGroup, there is a conflict between the zIndex attribute and the removeClippedSubviews optimization attribute. When both are used at the same time, the array mDrawingOrderIndices in ViewGroupDrawingOrderHelper that records the rendering order of subviews is not reset when super is called in the updateSubviewClipStatus method to add and remove subviews.
Solution:�Because there are many third-party components that inherit from or depend on ReactViewGroup, all methods for adding and removing subviews in ViewGroup need to be override in ReactViewGroup, and ViewGroupDrawingOrderHelper corresponding to handleAddView and handleRemoveView needs to be called in these methods. And all the precautions for directly calling super to add and remove subviews are changed to calling the overridden method by ReactViewGroup.
Special Note: All addView related methods in ViewGroup will eventually be called to the addView(View child, int index, LayoutParams params) method, except addViewInLayout. Regarding the method of adding subviews, we only need to override addView(View child, int index, LayoutParams params) and addViewInLayout(View child, int index, LayoutParams params,boolean preventRequestLayout) in ReactViewGroup.
## Changelog:
[Android] [Fixed] - Fix the crash in ReactViewGroup of https://github.com/facebook/react-native/issues/30785
Pull Request resolved: https://github.com/facebook/react-native/pull/40859
Reviewed By: NickGerleman
Differential Revision: D50321718
Pulled By: javache
fbshipit-source-id: 7fa7069937b8c2afb9f30dd10554370b1be5d515
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42922
changelog: [fix][ios] prevent unwanted border animation
The problem: CALayer and its properties are animatable. If RN applies mutations inside an animation block, it will animate. In this particular example, it was animated because of a transition applied by the library and because we were not creating new views, but recycling views from previous screen.
This caused size of _borderLayer to change from value A to value B inside of animation block. To resolve this, call removeAllAnimations on borderLayer.
Reviewed By: cipolleschi
Differential Revision: D53566886
fbshipit-source-id: 98e0b01a9185046e1ee500665c1832060ecc8884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42639
When I reverted part of the deprecation of `RCT_NEW_ARCH_ENABLED`, I forget a little bit which was breaking RCTFabric podspec.
This diff fixes that.
[Internal] - Bring back `RCT_NEW_ARCH_ENABLED` to Fabric to make the `RCTThirdPartyFabricComponentsProvider` work again.
Reviewed By: cortinico
Differential Revision: D53048270
fbshipit-source-id: d21e833c10b332fb70147cc65b690f88016655e6
* Add Flow, add positive test case for monorepo publish step (#42936)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42936
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607809
fbshipit-source-id: 990826fda5538af9a13e3f24978295a2f3b0c8c3
# Conflicts:
# scripts/monorepo/__tests__/find-and-publish-all-bumped-packages-test.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Update exit cases for monorepo publish script (#42937)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42937
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607810
fbshipit-source-id: 18e79f23060ee70e96bd8ac6e9995b0a8ba300b3
# Conflicts:
# scripts/monorepo/__tests__/find-and-publish-all-bumped-packages-test.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Refactor package discovery in publish script (#42938)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42938
Substitutes the `forEachPackage` util with a replacement async `getPackages` function. This will be used further in the next diff.
The new function aims to be more erganomic/versatile than `forEachPackage` by returning a package mapping (see updated test mock). The API aligns roughly with `yarn workspaces list` and [Lerna's `detectProjects`](https://lerna.js.org/docs/api-reference/utilities#detectprojects).
This also aligns with / replaces similar attempts in our existing scripts:
- [`getPackagesToPublish`](https://github.com/facebook/react-native/blob/2ca7bec0c2a7d821ceaaf39840a6cdc5eceb8678/scripts/monorepo/get-and-update-packages.js#L56)
- [`getPublicPackages`](https://github.com/facebook/react-native/blob/2ca7bec0c2a7d821ceaaf39840a6cdc5eceb8678/scripts/releases/set-version/index.js#L19)
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607806
fbshipit-source-id: 00ec34edadab863dc8f2f0c7852f6e835a5dddf5
# Conflicts:
# scripts/monorepo.js
# scripts/monorepo/find-and-publish-all-bumped-packages.js
# scripts/monorepo/for-each-package.js
* Use npm as source of truth for updated packages (make publish script rerunnable) (#42944)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42944
Updates `find-and-publish-all-bumped-packages` to use the npm registry as the source of truth, similar to tools like Lerna (`lerna publish from-package`). **This enables safe reruns of the publish script**, and replaces the previous Git-diff-detection implementation.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D53607807
fbshipit-source-id: 135808b7ce36cf463c9f53a8059500b83f8b6679
# Conflicts:
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Add retry to monorepo publish script (#42964)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42964
We've seen npm publishes fail occasionally in CI as part of this script, most recently in S391653. This change adds a single retry, per package, during the execution of this script, in an attempt to reduce the chance of manual interventions after a broken pipeline.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607808
fbshipit-source-id: 526d9c33d51ec57702efba3c199bad313c1bf2d4
# Conflicts:
# scripts/monorepo/find-and-publish-all-bumped-packages.js
* Rename and document monorepo publish script (#42989)
Summary: Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D53607805
fbshipit-source-id: babe9bbd7fb5e7016b567193727c6a441bee60a3
# Conflicts:
# scripts/__tests__/publish-updated-packages-test.js
# scripts/publish-updated-packages.js
# scripts/releases-ci/README.md
Summary:
Closes https://github.com/facebook/react-native/issues/42164
## Changelog:
[IOS] [FIXED] - Fixes `with-environment.sh` script for the case when Node can't be found prior to loading `.xcode.env`
Pull Request resolved: https://github.com/facebook/react-native/pull/42184
Test Plan: This is a trivial update, no need for much testing.
Reviewed By: cortinico
Differential Revision: D52602653
Pulled By: cipolleschi
fbshipit-source-id: 0881456bf165d895252ae38cb7c7aee945cfaf52
Summary:
Why ignore for now?
- It only happen once during initialization and doesn't cause any breakages for RNTester
- The race condition happens in Android System code which is hard to tackle:
```Exception in native call
java.lang.NullPointerException: java.lang.NullPointerException
at com.facebook.jni.NativeRunnable.run(Native Method)
at android.os.Handler.handleCallback(Handler.java:958)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:30)
at android.os.Looper.loopOnce(Looper.java:205)
at android.os.Looper.loop(Looper.java:294)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:235)
at java.lang.Thread.run(Thread.java:1012)
```
From stack trace message.callback is checked in
```at android.os.Handler.dispatchMessage(Handler.java:99)```
but becomes null in
```at android.os.Handler.handleCallback(Handler.java:958)```
[Android source code](https://l.facebook.com/l.php?u=https%3A%2F%2Fandroid.googlesource.com%2Fplatform%2Fframeworks%2Fbase%2F%2B%2Fmaster%2Fcore%2Fjava%2Fandroid%2Fos%2FHandler.java&h=AT1aQS0Vmknao8kLbYE_hhLj1G3idUf69jFQE3ZLAqjrbcMX4OdQUV1dzZpAkAvLaZ9HAOanpsKCC8z59Ce9XJa6cOhQL2L95gM9iMrSr7FbrpTKPLKbWjDmTz89WUL2pQprnBVKyA8) of Handler.
Reviewed By: cortinico
Differential Revision: D51550240
fbshipit-source-id: 6288e196da1da88a37f5c69bfce82e3e09c6f106
Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15
This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression. It's currently blocking 0.73.3.
[iOS][Fixed] don't allow cocoapods 1.15.
<!-- 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/42702
Test Plan:
```
bundle exec pod install
```
Reviewed By: cipolleschi
Differential Revision: D53180111
Pulled By: blakef
fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42306
Internally, we have some computationally expensive checks in Debug mode when running Fabric.
However, these are not very useful in OSS and they were the cause of some issues which generated noise.
With this change, we are enabling those checks only in the Meta specific builds and making sure that the OSS won't incur in that cost.
## Changelog
[Internal] - Disable expensive Fabric checks when running Fabric in OSS
Reviewed By: cortinico, sammy-SC
Differential Revision: D52543696
fbshipit-source-id: 697f14fd21e884f293ea7cee8ee16fff73764996
Summary:
This PR removes the `apply_ats_config` function of ReactNativePodsUtils that was used inside `react_native_post_install` because it was preventing users from configuring `NSAllowsArbitraryLoads` to true in their projects, especially when building in CI as the plist file would be reset after running pod install.
[IOS] [CHANGED] - Remove ATS config patch from react_native_post_install
Pull Request resolved: https://github.com/facebook/react-native/pull/42637
Test Plan: Edit `Info.plist`, run `pod install` and check if changes have not been overwritten
Reviewed By: cortinico
Differential Revision: D53048299
Pulled By: cipolleschi
fbshipit-source-id: 8dc335fae2e05a62daf931a50fa3f7a314e76a2e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42396
Cmmunity reported [#42120](https://github.com/facebook/react-native/issues/42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.
Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.
This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.
## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge
Reviewed By: RSNara
Differential Revision: D52912604
fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40860
This diff adds support for the `AS` expression in TS sources. The following codegen declaration should work now:
```
export default codegenNativeComponent<NativeProps>(
'MyComponentView',
) as HostComponent<NativeProps>;
```
Changelog: [General][Added] - Handle TSAsExpression when looking for the codegen declaration
Reviewed By: shwanton
Differential Revision: D50225241
fbshipit-source-id: 247a3d341d742b548e82318d0fa21dff9884d2bd
Summary:
Dependency on `chalk` was introduced in https://github.com/facebook/react-native/pull/37510, but was never declared. In pnpm setups, the CLI fails to run because of this.
This needs to be picked to 0.73.
[GENERAL] [FIXED] - Declare missing dependency `chalk`
Pull Request resolved: https://github.com/facebook/react-native/pull/42235
Test Plan: n/a
Reviewed By: huntie
Differential Revision: D52660337
Pulled By: cortinico
fbshipit-source-id: 1cd45fcff72045c127773566a27103f1b38262b3
Summary:
In my mac, I use a case-sensitive volume and when I build a react-native 0.73 project it failed with an error that can't find the hermes release tarball to extract:
```
Node found at: /usr/local/bin/node
Preparing the final location
Extracting the tarball
tar: Error opening archive: Failed to open '/Volumes/Workspace/meet-art-link/ios/Pods/hermes-engine-artifacts/hermes-ios-0.73.1-Release.tar.gz'
```
Note the `...-Release.tar.gz` in the error. In the disk it's `...-release.tar.gz`.
The build fails in after download the release tarball in release mode because the hermes tarball name in the `replace_hermes_version.js` build script is capitalized, while the file is lowercase on disk.
The fix is to ensure the hermes tarball name's "build type" is lowercase just like the function that creates the tarballs in react-native release located in `hermes_utils.js` in `getHermesPrebuiltArtifactsTarballName()`.
Perhaps it's better to retrieve the tarball name from the same method it's generated? E.g.:
```js
const { getHermesPrebuiltArtifactsTarballName } = require('react-native/scripts/hermes/hermes-utils');
const tarballName = getHermesPrebuiltArtifactsTarballName(`${version}-${configuration}`);
const tarballURLPath = `${podsRoot}/hermes-engine-artifacts/${tarballName}`;
```
If yes, let me know to update the PR.
## 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
-->
[iOS][Fixed] - Fix release build error due to a casing issue in hermes tarball path after download prebuilt tarball
Pull Request resolved: https://github.com/facebook/react-native/pull/42160
Test Plan: Use a case sensitive volume or system and build react-native 0.73 in release mode, it will fail. Apply the patch in this PR and it will work fine.
Reviewed By: cortinico
Differential Revision: D52603439
Pulled By: cipolleschi
fbshipit-source-id: 41ed8d8202874f338e4aa3af88d9d28ec1b8b3d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42133
## Changelog:
[General][Fixed] - TouchableBounce, TouchableHighlight and TouchableNativeFeedback dropping touches with React 18.
TouchableBounce, TouchableHighlight and TouchableNativeFeedback do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableBounce, TouchableHighlight and TouchableNativeFeedback were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52514643
fbshipit-source-id: 0d6ae4bb7c2a797cc443181459c5614da0ecfc7a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42121
## Changelog:
[General][Fixed] - TouchableWithoutFeedback and TouchableOpacity dropping touches with React 18.
TouchableWithoutFeedback and TouchableOpacity do not trigger onPress when used with React 18. This is because it resets its pressability configuration in `componentWillUnmount`. This is fine, we want to stop deliver events and restart all timers when component is unmounted.
```
componentWillUnmount(): void {
this.state.pressability.reset();
}
```
But TouchableWithoutFeedback and TouchableOpacity were not restarting the pressability configuration when component was mounted again. It was restarting the configuration in `componentDidUpdate`, which is not called when component is unmounted and mounted again.
Reviewed By: fkgozali
Differential Revision: D52388699
fbshipit-source-id: ef13194c6581c5d31d0f1cb465bfd0cf98d672ea
Summary:
When bridgeless is enabled, RN Tester New Architecture examples crashed with a StackOverflow Exception
The root cause of this issue is that MyLegacyViewManager is sending an event to JS during the execution of MyLegacyViewManager.createViewInstance() method.
This is a problem because the delivery of events depend on the "id" of the view, but the "id" of the view is set after MyLegacyViewManager.createViewInstance() finishes executing.
The documentations "implicitly" mentions to not set props during the execution of the ViewManager.createViewInstance() method:
https://reactnative.dev/docs/native-components-android#2-implement-method-createviewinstance
To fix this issue I'm removing the execution of the method that triggers the event.
bypass-github-export-checks
changelog: [Android][Fix] Fix rendering of 'RN Tester New Architecture examples' when bridgeless is enabled
Reviewed By: fkgozali
Differential Revision: D51047007
fbshipit-source-id: 17be493f79114fa402029063e79fabc1d90efc17
Summary:
This is a continuation of my [last PR](https://github.com/facebook/react-native/pull/40914) which improved the symbolication of unhandled promise rejections.
While I was developing another library I noticed I still got an error stack of the log adding and not of the error itself. The library I'm trying to debug does not throw a standard error object but rather a custom one, but it still contains the stack field. By passing this stack field to the logbox call I was able to get a better symbolicated stack trace. The exact line of the failure is not displayed but at least the correct file is.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [ADDED] - Unhandled promise rejection - attach non-standard Error object stack info if possible
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/42079
Test Plan:
Test any unhandled promise rejection with a non-standard error (line 23, toString must not return `[object Error]`) and see if the correct (or at least a better) stack trace is shown.
Here is the one I got before and after this change:
<img src="https://github.com/facebook/react-native/assets/1634213/3d07faad-9535-42c9-8032-b4d8fe407e88" width="200" />
<img src="https://github.com/facebook/react-native/assets/1634213/2c39bd82-c7a1-4f58-8ac4-5c479bb96b6e" width="200" />
Reviewed By: huntie
Differential Revision: D52431711
Pulled By: cipolleschi
fbshipit-source-id: be2172d3b1e2fc3f72812faac372c83bc6dface2
Summary:
Follow up of https://github.com/facebook/react-native/pull/41284#issuecomment-1789516046
We should not rely on checking if the `React-hermes` pod is present to determine if hermes is enabled
## Changelog:
[IOS] [CHANGED] - Update ios pod post_install logic for detecting if hermes is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41286
Test Plan: Run `use_react_native!(hermes => false)` should not add `USE_HERMES = true;` to `project.pbxproj`
Reviewed By: blakef
Differential Revision: D50899654
Pulled By: cipolleschi
fbshipit-source-id: a5ab5b0117c61014e77b780c50bf349da92c6342
Summary:
I noticed this comment is still in Java in the Kotlin template. It also doesn't really work anymore since there is no packages variable.
To fix it I completed the comment with all code needed for it to work in kotlin. I think an older version of the template used to be more like:
```kotlin
val packages = PackageList(this).packages
// packages.add(MyReactNativePackage())
return packages
```
But then it requires adding a lint suppress annotation since packages variable can be simplified. I think this is simpler even if it makes the comment a few more lines.
## Changelog:
[GENERAL] [FIXED] - Fix comment about adding packages in android template
Pull Request resolved: https://github.com/facebook/react-native/pull/41856
Test Plan: Tested that uncommenting that code works
Reviewed By: cipolleschi
Differential Revision: D51987483
Pulled By: cortinico
fbshipit-source-id: d0135b5b536960017ccc7b25f92c75b3bd863cd9
Summary:
Since yesterday evening (why it is always friday evening???) CircleCI or Gem decided to update the default bundler version that is installed with `gem bundle install`.
Therefore, CI for iOS stopped working.
This change installs bundler's versions so that they are compatible with the Ruby version.
## Changelog:
[Internal] - Fix CI for iOS installing versions of bundler that are compatible with Ruby
Pull Request resolved: https://github.com/facebook/react-native/pull/41962
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D52230544
Pulled By: cipolleschi
fbshipit-source-id: 2f96e16ecb94159953056e8de757ea4d249f80f0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41152
Building on byCedric's approach in https://github.com/facebook/metro/pull/991, and on D49954920, this diff passes stable, unique *logical device IDs* to the debugger connection infrastructure from Android and iOS.
See D49954920 for the precise stability and uniqueness requirements that these IDs meet.
Changelog:
[Changed][General] - Automatically reconnect to an existing debugger session on relaunching the app
Reviewed By: huntie
Differential Revision: D49954919
fbshipit-source-id: d4d918f0cbfd9df426e888845817e00410efb9d3
Summary:
This PR fixes https://github.com/facebook/react-native/issues/41874.
## 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
-->
[iOS] [Fixed] - Fix NSAppTransportSecurity being overwritten during pod install
Pull Request resolved: https://github.com/facebook/react-native/pull/41875
Test Plan:
1. Delete the whole `NSAppTransportSecurity` in Info.plist and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added as expected.
2. Modify `NSAppTransportSecurity` to only contain `NSExceptionDomains` and run `pod install`: `NSAllowsArbitraryLoads` and `NSAllowsLocalNetworking` are added, and `NSExceptionDomains` is still there.
3. Run `pod install` again: nothing changes.
Reviewed By: christophpurrer
Differential Revision: D52032400
Pulled By: dmytrorykun
fbshipit-source-id: 48cf29809c283af80613ffbf1ac0dc663a0a2fb5
Summary:
The logic to constrain the last spacer size is incorrect in some cases where the spacer is the last spacer, but not the last section in the list.
For more context, the role of spacer constraining is explained in this comment:
```
// Without getItemLayout, we limit our tail spacer to the _highestMeasuredFrameIndex to
// prevent the user for hyperscrolling into un-measured area because otherwise content will
// likely jump around as it renders in above the viewport.
```
For example it is incorrect in the case where we have:
ITEMS
SPACER
ITEMS
In this case the spacer is not actually the tail spacer so the constraining is incorrectly appied.
This causes issues mainly when using `maintainVisibleContentPosition` since it will cause it to scroll to an incorrect position and then cause the view that was supposed to stay visible to be virtualized away.
## Changelog:
[GENERAL] [FIXED] - Fix last spacer constrain logic in VirtualizedList
Pull Request resolved: https://github.com/facebook/react-native/pull/41846
Test Plan:
Tested using https://gist.github.com/janicduplessis/b67d1fafc08ef848378263208ab93d4c in RN tester, before the change content will jump on first click on add items.
Tested using the same example and setting initial posts to 1000, then we can see our content view size is still constrained properly (see scrolling indicator as reference).
Reviewed By: yungsters
Differential Revision: D51964500
Pulled By: NickGerleman
fbshipit-source-id: 4465aa5a36c95466aef6571314973c1e2c9a0f2c
Summary:
This enables the network panel/inspector by passing the `unstable_enableNetworkPanel=true` to the React Native JS Inspector. (See https://github.com/facebookexperimental/rn-chrome-devtools-frontend/pull/2)
By setting this inside the `experiments`, we can enable/disable network related CDP handlers within the proxy.
## Changelog:
[GENERAL] [ADDED] - Add `enableNetworkInspector` experiment to enable Network panel and CDP handlers in inspector proxy
Pull Request resolved: https://github.com/facebook/react-native/pull/41787
Test Plan: TBD, will provide a repository using an Expo canary / RN 0.73.0-rc release.
Reviewed By: NickGerleman
Differential Revision: D51811892
Pulled By: huntie
fbshipit-source-id: 541d96b6f0735104a4050a24a152e1158871ed1d
Summary:
This diff is reverting D49509633
D49509633: [react-native][PR] fix: Text cut off issues when adjusting text size and font weight in system settings by ryancat has been identified to be causing the following test or build failures:
Tests affected:
- [xplat/endtoend/jest-e2e/apps/facebook_xplat/ReactNativeTTRCTester/__tests__/ReactNativeTTRCTester-errorReportedManually-android-e2e.js](https://www.internalfb.com/intern/test/281475019301157/)
Here's the Multisect link:
https://www.internalfb.com/multisect/3131615
Here are the tasks that are relevant to this breakage:
We're generating a revert to back out the changes in this diff, please note the backout may land if someone accepts it.
If you believe this diff has been generated in error you may Commandeer and Abandon it.
Reviewed By: NickGerleman
Differential Revision: D49645585
fbshipit-source-id: 414531e067cffa109d0663d6af185dcaf8fb9c4e
Summary:
This is my proposed solution to https://github.com/facebook/react-native/issues/41677.
Fixes https://github.com/facebook/react-native/issues/41677.
## Changelog:
[ANDROID] [FIXED] - Fix android root view group removal during instance re-creation
Pull Request resolved: https://github.com/facebook/react-native/pull/41678
Test Plan:
Both with fabric enabled and disabled (new architecture):
1. Clone repro repo: https://github.com/wschurman/rn-reload-repro
2. Build and run on android (I use android studio)
3. Click reload button, see timestamp doesn't change (indicating that the view is not removed)
4. Apply this PR as a patch.
5. Re-build and run.
6. Click reload button, see view is correctly disposed of and the new view is set.
Reviewed By: cortinico
Differential Revision: D51658524
Pulled By: javache
fbshipit-source-id: d9a026cde677ad1ec113230bc31bd9297bca8bfc
Summary:
`build_codegen!` currently assumes that `react-native/codegen` gets installed next to `react-native`. In a pnpm setup, it's found under `/~/react-native/node_modules/react-native/codegen` instead.
However, as dmytrorykun pointed out, we don't actually need to build it outside of this repository.
## Changelog:
[GENERAL] [FIXED] - `react-native/codegen` shouldn't be built unless it's in the repo — fixes `pod install` failures in pnpm setups
Pull Request resolved: https://github.com/facebook/react-native/pull/41399
Test Plan: We have a patched version of `react-native` working in a pnpm setup here: https://github.com/microsoft/rnx-kit/pull/2811
Reviewed By: dmytrorykun
Differential Revision: D51201643
Pulled By: cipolleschi
fbshipit-source-id: 53767ae08686a20f03b3b93abcbc7d5383083872
In pnpm setups, codegen will fail during build because it cannot find
its dependencies. Some of the dependencies it relies on at runtime are
currently declared under `devDependencies`. This change moves them to
`dependencies`.
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41621
Currently, if you have a dependency that is alphabetically smaller than `app`, it's evaluation will happen before `app`.
This means that the namespace auto-discovery and the JVM toolchain configuration won't be working and the project will fail to buid.
This fixes it by introducing a root-project Gradle Plugin that takes care of enforcing the evaluation order on the `app` project.
Fixes#41620
Changelog:
[Android] [Fixed] - Fix projects being broken on dependencies starting with `a..`
Reviewed By: huntie
Differential Revision: D51547294
fbshipit-source-id: 65df7149548b7087dd8928e556fb803b3baf7b79
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41614
Fixes https://github.com/facebook/react-native/issues/41545
SafeAreaView works by adding padding in order to shift content out of the safe area. This may change the layout dimensions of the SafeAreaView, in turn effecting its safe area insets.
This can cause layout results to change, which in turn changes the inset value. Because of this, there is a tolerance, where safe area inset changes do not trigger a new update.
Yoga is instructed to round layout dimensions to the closest physical pixel, so a very small difference in layout may result being off by about a pixel. Right now the tolerance is exactly one physical pixel, and if there is FP error here, we may not pass the test, and start oscillating with different layout values.
After changing affected ShadowNode order to always be root-first, the first call to set the frame of the `SafeAreaView` happens when a non-zero-sized RootView is present, which I think may lead to a safe area inset update communicated that wasn't before? Or other cosmic butterflies. Layout rounds to one physical pixel in difference, and our tolerance is `0.00001` dips off (not helped that 1/3 screen scale cannot be represented as decimal, even without FP error).
This adds a small tolerance beyond just the pixel boundary, matching the logic in Fabric, which seems to resolve the issue.
Changelog:
[iOS][Fixed] - FP Tolerance in iOS Paper SafeAreaView debouncing
Reviewed By: philIip
Differential Revision: D51539091
fbshipit-source-id: 88bddc38c7cd8d93feef5f12da64b124af22f46d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41535
## Context
**Remote JS Debugging removal**
In React Native 0.73, we have deprecated Remote JS Debugging (execution of JavaScript in a separate V8 process) and also removed the Dev Menu launcher (https://github.com/facebook/react-native/pull/36754).
## This diff
Follows D46187942 — this option wasn't correctly removed for Android when running JSC. This is now consistent with iOS.
Changelog:
[Android][Changed] "Open Debugger" is no longer available for remote JS debugging from the Dev Menu (non-Hermes). Please use `NativeDevSettings.setIsDebuggingRemotely()`.
Reviewed By: blakef
Differential Revision: D50555095
fbshipit-source-id: 1aeb48ab1390dc12ce300d6f321c30de5343cf0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41036
Changelog:
[Added] - Shipping the new event dispatching pipeline that immediately moves events over to the C++ queue. This should unblock useDeferredValue + useTransition interruptibility on Android.
Reviewed By: javache
Differential Revision: D50365981
fbshipit-source-id: ecf60e5bc29fb4568463568a6ede4330e0294fd3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39671
Since minsdk version was increased to 23, we are deleting code using Android APIs < 23 for class ReactEditText
changelog: [Android][Breaking] Remove support for Android API < 23 in ReactEditText
Reviewed By: NickGerleman
Differential Revision: D48545507
fbshipit-source-id: 98be52ba36248962864e99e80ff648bbb351ff61
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41499
After D48152876 we consume JSI from `ReactCommon/jsi`, and ignore JSI that is distributed with `hermes-engine`.
This diff removes `include/jsi` from `source_files` of `hermes-engine` so we don't get two sets of JSI headers - one from `ReactCommon`, and the other one from `hermes-engine`.
This diff also fixes accidental breakage of ODR violation. We will no longer compile JSI into `react-native` when linking against `hermes-engine`, which already has JSI in it.
Changelog: [iOS][Fixed] - Exclude JSI headers when using hermes-engine prebuilt.
Reviewed By: cipolleschi
Differential Revision: D51347562
fbshipit-source-id: 6e4b9940c43d74d227a05999926b8752d7685670
Summary:
Recently, both `metro-inspector-proxy`(https://github.com/facebook/react-native/pull/39045) and `react-native-community/cli-plugin-metro`(https://github.com/facebook/react-native/pull/38795) were moved to this repo and in the process of moving these packages, the `exports` field inside package.json was added, only exporting the `index.js` file.
The problem is that Expo CLI (and possibly other community packages) rely on functions and classes that are not exported in the `index.js` file, e.g. Importing the InspectorProxy class from `react-native/dev-middleware/dist/inspector-proxy/InspectorProxy`. Normally this wouldn't be a problem and we would just import from `dist/` but due to the `exports` field, attempting to import from any other file not specified on this field will result in a `ERR_PACKAGE_PATH_NOT_EXPORTED` error.
As a short-term fix, we should create `unstable_`-prefixed exports of individual features Expo currently depends on.
## Changelog:
[INTERNAL] [CHANGED] - Expose unstable_InspectorProxy and unstable_Device from `react-native/dev-middleware`
Pull Request resolved: https://github.com/facebook/react-native/pull/41370
Test Plan: N / A
Reviewed By: robhogan
Differential Revision: D51163134
Pulled By: blakef
fbshipit-source-id: e67adaedc4fc64131e4c9dd8383c9877b8202283
Summary:
There is a problem in the way that we check if Fabric is enabled inside `react_native_post_install`.
https://github.com/facebook/react-native/blob/899e7cdb55197fc17a96a93af4f8bcc7519553c2/packages/react-native/scripts/react_native_pods.rb#L239
We're determining if fabric is enabled by checking if the `React-Fabric pod `is present, but since we always call `setup_fabric!(:react_native_path => prefix)` (https://github.com/facebook/react-native/pull/39057) inside `use_react_native` the `React-Fabric` pod is always present causing the `-DRN_FABRIC_ENABLED` flag to always be added to `project.pbxproj` even if the new arch is disabled.
[IOS] [FIXED] - Fix ios pod post_install logic for detecting if fabric is enabled
Pull Request resolved: https://github.com/facebook/react-native/pull/41284
Test Plan: Run `use_react_native!(fabric => false)` should not add the `-DRN_FABRIC_ENABLED` flag to `project.pbxproj`
Reviewed By: fkgozali
Differential Revision: D50896487
Pulled By: cipolleschi
fbshipit-source-id: 78154407ce52b09fd3a317b7dc64bd4bba56363e
Summary:
This should fix
https://github.com/facebook/react-native/issues/37905#issuecomment-1774851214
When working on react-native-fast-image, we realized that the interop layer does not work for components where the exported name is different from the iOS class.
To fix this, we can use the Bridge to retrieve the actual view manager, given the component name.
This solution should be much more robust than making assumptions on the ViewManager name, given the ComponentName.
On top of that, we realized tha the interop layer was not calling `didSetProps` after setting the props, so we are invoking that.
bypass-github-export-checks
[iOS][Fixed] - Add support for Components with custom names in the interop layer.
Pull Request resolved: https://github.com/facebook/react-native/pull/41207
Test Plan: Tested locally on an app created in 0.72 and 0.73 in Bridge and Bridgeless mode.
Reviewed By: cortinico
Differential Revision: D50698172
Pulled By: cipolleschi
fbshipit-source-id: 49aee905418515b0204febbbe6a67c0114f37029
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40869
Bumps DRNPT to v5 - the significant change is that this one depends on `react-native/normalize-color: ^0.73.0`, instead of `*`, so is protected from future breaking changes to that package.
NOTE: We can't safely include `react-native/normalize-color: ^0.74.0` in the dependency range of DRNPT because `0.74.0` isn't a semver-compliant release (0.74 isn't cut yet), so this will pull 0.73.2 from NPM, which is fine. We may need to publish DRNPT@6 if 0.74 final turns out to contain breaking changes (eg, a Node 20 bump).
Changelog:
[General][Fixed] Update `deprecated-react-native-prop-types` to remove fragile transitive `*` dependencies.
Reviewed By: huntie
Differential Revision: D50228564
fbshipit-source-id: 01aafafad40d9a93d00de2b5f45d2796620b9b5d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41270
`scheduleCellsToRenderUpdate()` is called in response to new measurements, or component changes. It has logic to decide whether to immediately calculate new state, or to defer it until a later batched period.
It will not immediately update state if we don't yet have measurements for cells, but this condition is after another which calculates priority, relying on these measurements. These are garbage if we don't yet have measurements, and trigger an invariant violation in horizontal RTL.
This switches around the conditions, to avoid offset resolution if we don't yet have valid measurements.
I suspect some "hiPri" renders where cells shift are bugged right now when we update state in response to content size change, before we have new corresponding cell layouts.
Changelog:
[General][Fixed] - Bail on hiPri render on missing layout data before checking priority
Reviewed By: yungsters
Differential Revision: D50791506
fbshipit-source-id: 8dbffc37edd2a42f7842c0090d344dcd6f3e3c6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41159
Changelog: [Internal]
Cleanup from D48966244. The deprecated `jsinspector` files are no longer used by any code in either fbsource or `react-native`.
Reviewed By: hoxyq
Differential Revision: D50530796
fbshipit-source-id: b539b097cb6caf6c50a482fa93bf5d7886e76e52
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41058
Glog has a piece of code which looks like this:
```
namespace google {
// They need the definitions of integer types.
#include "glog/log_severity.h"
#include "glog/vlog_is_on.h"
```
This fragment is:
- Always valid when the pod does not define a module
- Valid for Xcode >= 14.3, when the pod do define a module
- Invalid for Xcode < 14.3, when the pod do define a module
Modules are required to support Swift, so, in the long run, we want to have `DEFINES_MODULE` set to `YES` for `Glog`.
This is a temporary workaround to keep supporting older versions of Xcode while Apple keeps allowing to use Xcode 14.1 to submit apps to the store.
Historically, Apple pushes the minimum version of Xcode every April, so we expect to be able to remove this workaround in April 2024.
## Changelog:
[Internal] - Make Glog work with older versions of Xcode
Reviewed By: cortinico
Differential Revision: D50410487
fbshipit-source-id: 96145cdf9ba1bc75622403d3c06454d6d4bfd967
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41055
This should fix the issue highlighted in [this comment](https://github.com/reactwg/react-native-releases/discussions/64#discussioncomment-7271155).
Basically, before the fix, we were not supporting flavours correctly, as we assumed that only Debug and Release were available.
With this change, we infer whether we have to fetch Hermes for Debug or Release based on the actual flags that are passed. In this way, the users can customize their app's flavors more freely.
## Changelog:
[Internal] - Support multiple flavors when downloading Hermes
Reviewed By: huntie
Differential Revision: D50408381
fbshipit-source-id: 6990218b286b4dd823323bc63de90279efc9e74e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41047
Array events are currently broken in the sample for RN Tester. This is because the event name is not registered correctly.
I'm updating the event registration to be correct.
Changelog:
[Internal] [Changed] - Make IntArray events work on Bridgeless for RN-Tester
Reviewed By: cipolleschi
Differential Revision: D50266485
fbshipit-source-id: 13bbce91a41281383d4857048e573b6d9cc5387b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40941
Events are currently not working for Fabric Interop on Bridgeless. That's because the `BridgelessReactContext` is not checking for interop modules on `getJsModule` calls, so the `InteropEventEmitter` is never returned.
This extends `BridgelessReactContext` so that `InteropEventEmitter` is returned if the Interop Layer is turned on.
Changelog:
[Internal] [Changed] - Make events work for Fabric Interop on Bridgeless
Reviewed By: cipolleschi
Differential Revision: D50266484
fbshipit-source-id: 0188d71bdc7acc8c188d886d45f0258914ad7af7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40929
This diff reduces the footprint that bridgeless is imposing on the new app template. Specifically:
- I've created a `.toReactHost` method that converts a DefaultReactNativeHost to a DefaultReactHost
- I've updated RN Tester to use the same setup as the New App template which reduces code duplication.
I also had to remove a couple of `UnstableReactNativeAPI` as those were bleeding in the new app template.
I don't think we should ask users to opt-in in `UnstableReactNativeAPI` in the New App template itself as
this means that all the apps will get this opt-in.
Instead we should keep it only for specific APIs that we want the users to opt into.
Changelog:
[Internal] [Changed] - Simplify new app template for bridgeless
Reviewed By: cipolleschi, luluwu2032
Differential Revision: D50227693
fbshipit-source-id: e86c54d5156cc27f1f898b43ca89c57d5cf148b8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40942
The Fabric Interop example for Android is broken. This is due to the Kotlin conversion which moved the `Color.colorToHSV(color, hsv)` statement *after* the HSV array is read so the array is always [0,0,0].
I'm fixing it here.
Changelog:
[Internal] [Changed] - Fix broken Fabric Interop example
Reviewed By: cipolleschi
Differential Revision: D50264766
fbshipit-source-id: 27ae5289408c7c23c667d6d7112437fa7ebe36d5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40940
Currently the `onIntArrayChanged` event is invoked
only once inside RN Tester. I'm changing the logic to make sure it fires whenever we click "Set Opacity"
Changelog:
[Internal] [Changed] - Make sure onIntArrayChanged is invoked on RN Tester
Reviewed By: mdvacca, dmytrorykun
Differential Revision: D50264765
fbshipit-source-id: 93a60fd1b657c3d8b8182cab6bb7cd4368ac9a42
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39810
Two issues will be fixed:
- Bridgeless has lazy view manager loading by default so the React Package that provides view managers must implement ViewManagerOnDemandReactPackage, we might could refactor the design of package classes later
- ThemedReactContext should **NOT** be used directly to call function ```getJSModule```, since it doesn't overrides ```getJSModule``` for Bridgeless, we can use it's internal variable ```meactApplicationContext``` which should be an instance of BridgelessReactContext
Reviewed By: cortinico
Differential Revision: D49912656
fbshipit-source-id: a0bdd717612398e8d7a6f36d36dba241a3b06bd7
Summary:
We don't need this if-than-else because the initializeFlipper already checks if we're on bridgeless or not
Changelog:
[Internal] [Changed] - Do not guard initializeFlipper for bridgeless for RN Tester
Reviewed By: NickGerleman
Differential Revision: D49881903
fbshipit-source-id: e6bfc941b43382580bd418a5f27ad9426d300c69
Summary:
Rewrite `RNTesterApplication` to Kotlin as per [Help us Kotlin-ify React Native tests - Round 2](https://github.com/facebook/react-native/issues/38825)
## Changelog:
[ANDROID] [CHANGED] - Rewrite RNTesterApplication to Kotlin, add AnnotationTarget property.
Pull Request resolved: https://github.com/facebook/react-native/pull/39557
Test Plan:
`yarn && yarn android` ✅
The only thing I'm kinda unsure of is whether `AnnotationTarget.PROPERTY` should be added, but it didn't let me annotate `reactHostInterface` without that and didn't compile.
<img width="637" alt="image" src="https://github.com/facebook/react-native/assets/33528752/8bc84870-f3f2-4a46-b076-6ee7e38bd735">
cortinico mdvacca
Reviewed By: cortinico
Differential Revision: D49598401
Pulled By: mdvacca
fbshipit-source-id: 105ae0c13c93dae0eeb2b6fa9040f03f42d2736a
Summary:
Commit 8b88883071 broke the Cache for RNTester because the cached version of the pods does not know about the exitence of SocketRocket 6.1.0
Bumping the keys should force a redownload of the cocoapods specs repo
## Changelog:
[Internal] - Bump RNTester cache keys
Pull Request resolved: https://github.com/facebook/react-native/pull/40789
Test Plan: CircleCI is green
Reviewed By: GijsWeterings
Differential Revision: D50169281
Pulled By: cipolleschi
fbshipit-source-id: 83e251495bfa43d62384470efe97c5505d76684f
# Conflicts:
# packages/rn-tester/Podfile.lock
Summary:
The SocketRocket version was upgraded to 0.6.1 on the 0.72-stable branch but for some reason it was not updated in main, causing a downgrade when running `pod install` with 0.73.0 RC1
Original commit bumping SocketRocket -> https://github.com/facebook/react-native/commit/8ce471e2fa802cc50ff2d6ab346627cb5f6d79b4
## Changelog:
[IOS] [CHANGED] - Bump SocketRocket to 0.6.1
Pull Request resolved: https://github.com/facebook/react-native/pull/40774
Test Plan: Run rntester locally
Reviewed By: cipolleschi
Differential Revision: D50137261
Pulled By: arushikesarwani94
fbshipit-source-id: dfc2760f5d5611881126ad114d8f6ada23630a29
# Conflicts:
# packages/react-native/React-Core.podspec
# packages/react-native/React/CoreModules/React-CoreModules.podspec
# packages/rn-tester/Podfile.lock
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41050
This change aligns all the podspecs to 13.4, including 3rd party libraries. This should fix https://github.com/facebook/react-native/issues/39826
## Changelog
[iOS][Changed] - Align all pods to 13.4
Reviewed By: huntie
Differential Revision: D50405114
fbshipit-source-id: 2d1b50ed8433e8cdc2214eb17e15be6ea81107a1
# Conflicts:
# packages/react-native/scripts/cocoapods/utils.rb
Summary:
For a very long time when a promise rejects without an attached catch we get this warning screen without a correct stack trace, only some internal calls to the RN internals.
<img src="https://github.com/facebook/react-native/assets/1634213/75aa7615-ee3e-4229-80d6-1744130de6e5" width="200" />
I created [an issue for discussion](https://github.com/react-native-community/discussions-and-proposals/discussions/718) in the react-native-community repo and we figured out it was only a matter of symbolication. While it cannot be done on release without external packages and source maps, at least while developing we can provide a symbolicated stack-trace so developers can better debug the source of rejected promise.
I got the stack trace symbolicated and the correct code frame. I'm missing some help trying to display it in the warning view but at the very least I can now correctly show the line of the error and log the codeframe to the console.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[GENERAL] [FIXED] - Show correct stack frame on unhandled promise rejections on development mode.
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
Pull Request resolved: https://github.com/facebook/react-native/pull/40914
Test Plan:
I simply created a throwing function on a dummy app, and checked the output of the console and the warning view:
```ts
import React from 'react';
import {SafeAreaView, Text} from 'react-native';
async function throwme() {
throw new Error('UNHANDLED');
}
function App(): JSX.Element {
throwme();
return (
<SafeAreaView>
<Text>Throw test</Text>
</SafeAreaView>
);
}
export default App;
```
Here is the output
<img src="https://github.com/facebook/react-native/assets/1634213/2c100e4d-618e-4143-8d64-4095e8370f4f" width="200" />
Edit: I got the warning window working properly:
<img src="https://github.com/facebook/react-native/assets/1634213/f02a2568-da3e-4daa-8132-e05cbe591737" width="200" />
Reviewed By: yungsters
Differential Revision: D50324344
Pulled By: javache
fbshipit-source-id: 66850312d444cf1ae5333b493222ae0868d47056
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/41009
This change should fix [#39971](https://github.com/facebook/react-native/issues/39971), computing the relative path from the App path to the pod installation root and using that instead of the absolute path to the `react-native.config.js` file
## Changelog
[Internal] - Stabilize RCTAppDelegate podspec
Reviewed By: cortinico
Differential Revision: D50323710
fbshipit-source-id: e29e62228d08c752e822d7a9ab5b1a2b5dcd6eb4
Summary:
…king root view frame changes
Looking through where this was introduced (https://github.com/facebook/react-native/pull/37649), it seems the notification went from tracking root view size changes to window size changes. However, it was not renamed. I was using it for root view changes in RN-macOS, which.. I guess I'll refactor. Meanwhile, let's update the name?
## Changelog:
[IOS] [CHANGED] - Rename `RCTRootViewFrameDidChangeNotification` as it's not tracking root view frame changes
Pull Request resolved: https://github.com/facebook/react-native/pull/39835
Test Plan: CI should pass
Reviewed By: cipolleschi
Differential Revision: D50173742
Pulled By: javache
fbshipit-source-id: 4651696174c439800984a5e6cf642200bb9c4f3c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39959
We're still accessing project.buildDir which will be removed in Gradle 9.0
I'm cleaning it up here.
Changelog:
[Internal] [Changed] - Fix compilation warnings introduced by Gradle 8.4
Reviewed By: yungsters
Differential Revision: D50016573
fbshipit-source-id: de7a725f61b503f08991ebf85b9a002cefab221a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40767
Fix the following issue:
```Invariant Violation: TurboModuleRegistry.getEnforcing(...):
'ExceptionsManager' could not be found. Verify that a module by this name is registered in the native
binary.Bridgeless mode: true. TurboModule interop: true. Modules loaded: {"NativeModules":[],"TurboModules":
["PlatformConstants","AppState","SourceCode","BlobModule","WebSocketModule","DevSettings","DevToolsSettingsManager","LogBox","Networking","Appearance","DevLoadingView","DeviceInfo","DeviceEventManager",
"SoundManager","ImageLoader","DialogManagerAndroid","NativeAnimatedModule","I18nManager","AccessibilityInfo","StatusBarManager","StatusBarManager","IntentAndroid","ToastAndroid","ShareModule","Vibration"],
"NotFound":["NativePerformanceCxx","NativePerformanceObserverCxx","RedBox","BugReporting","HeadlessJsTaskSupport","FrameRateLogger","KeyboardObserver",
"AccessibilityManager","ModalManager","LinkingManager","ActionSheetManager","ExceptionsManager"]}
```
Changelog:
[Android][Changed] - Add Add ExceptionsManagerModule to CoreReactPackage
Reviewed By: cortinico
Differential Revision: D50017783
fbshipit-source-id: 8642bb23bdae50a1e702f5e0586b0ede80007bb1
# Conflicts:
# packages/rn-tester/android/app/src/main/java/com/facebook/react/uiapp/RNTesterApplication.kt
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40998
changelog: [Android] Add back interface FabricViewStateManager to unblock 0.73
I incorrectly deleted FabricViewStateManager in D47993140. This is a breaking change even for old architecture. Let's add it back and mark it as deprected so we can remove it later on.
This interface is not used in react-native anymore.
We are removing FabricViewStateManager because it simply wraps StateWrapper and provides no additional anymore.
Reviewed By: cortinico
Differential Revision: D50318633
fbshipit-source-id: aeb1c66c35018e336339616b564dee6f3156b54b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39834
Bridgeless is instacrashing on fast-refresh. This fixes it.
Changelog:
[Android] [Fixed] - Fix instacrash on bridgeless due to calling showMessage on null instance
Reviewed By: cipolleschi
Differential Revision: D49929822
fbshipit-source-id: a2ce65797abd34d6a3e2b7f2c50d38a62ea8bdea
Summary:
Fix https://github.com/facebook/react-native/issues/40560
## Changelog:
[ANDROID] [FIXED] - Ensure that `configureJavaToolChains` is only executed once during configuration
Pull Request resolved: https://github.com/facebook/react-native/pull/40757
Test Plan:
- Create a fresh `react-native@0.73.0-rc.1` project
- Install `react-native-webview`
- Apply [this patch](https://github.com/react-native-webview/react-native-webview/pull/3175/files) for `react-native-webview` (caused by another issue https://github.com/facebook/react-native/issues/40559)
- Edit `android/gradle.properties` and set `newArchEnabled` to true
- Build application
- (Expected) Application fail to build
- Apply this PR
- (Expected) Application build successfully
**Additional explanation:**
According to the implementation of `configureJavaToolChains`, all the subprojects (both the app and the libraries) will have their toolchains setup in one execution of the method. Therefore, it is okay for the method to be invoked only when configuring the plugin for the app.
On the other hand, invoking the method for more than one time will cause the issue stated in https://github.com/facebook/react-native/issues/40560.
Reviewed By: cipolleschi
Differential Revision: D50361871
Pulled By: cortinico
fbshipit-source-id: bd5e18df97988122788d0482dba954e517a0cb5c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40939
Currently some libs on RN 0.73 are broken as the default for Build Config generation changed
from true to false since AGP 8.x. This reverts the behavior to the old flag.
Closes#40791Closes#40559
Changelog:
[Internal] [Changed] - Make sure buildConfig is turned on for all the 3rd party libraries
Reviewed By: mdvacca
Differential Revision: D50270382
fbshipit-source-id: 02dcb031c577f65be2f41d9da0334c1b3d89e4c5
Summary:
… request to local pathname comparator variables to fix issue with other rightward elements of url such as query or fragment entering the comparison and causing 404 errors for key debugging routes.
A change in Chromium appended the query "?for_tabs" to the /json/list request made by Chrome DevTools to find remote debugger targets.
The current comparison in InspectorProxy.js compares the entire node IncomingMessage url field to the local pathname constants. The issue arises as url can also contain the query and fragment portions so the original comparison of "/json/list" === "/json/list" which resolved as true would become "/json/list?for_tabs" === "/json/list" and evaluate to false ultimately resulting in a 404 for the request.
In summary, all these changes/issues caused remote debugging of Hermes code in React Native apps to become unavailable, greatly impacting developer experience.
## Changelog:
[GENERAL] [FIXED] JS Debugging: Fix inspector-proxy to allow for DevTools requests with query strings
Pull Request resolved: https://github.com/facebook/react-native/pull/41005
Reviewed By: NickGerleman
Differential Revision: D50342265
Pulled By: robhogan
fbshipit-source-id: a65f2908f0bea9fc15e1e3e4e6d31a3b9598e81f
Summary:
## Changelog:
[Internal] - Run all the tests in CI when not on a PR
Reviewed By: cortinico
Differential Revision: D50220596
fbshipit-source-id: be1a30d713e9d427858cf22bd3ca9549ad513057
Summary:
The reference to runtime assumes the queue will ensure references to runtime are valid when invoked. This
isn't the case if you create a breakpoint, Hermes hit that breakpoint and your refresh the app. This consistently
will crash the app.
The fix is to not assument this, similar to ReactCommon/react/runtime/hermes/HermesInstance.cpp
Reviewed By: javache
Differential Revision: D50225678
fbshipit-source-id: b45cae1f5f687bc8c699fd74b187376a547012c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40751
In D48379915 I fixed inverted `contentOffset` in `onScroll` events on iOS. I thought I tested on Paper, but I think this was during a period where the Paper route in Catalyst was actually launching Fabric (oops).
In Paper, at least under `forceRTL` and English, `[UIApplication sharedApplication].userInterfaceLayoutDirection` is not set to RTL. We instead have a per-view `reactLayoutDirection` we should be reading.
This sort of thing isn't currently set on Fabric, which checks application-level RTL. This seems... not right with being able to set `direction` in a subtree context, but Android does the same thing, and that would take some greater changes.
Changelog:
[iOS][Fixed] - Fix iOS Paper Scroll Event RTL check
Reviewed By: luluwu2032
Differential Revision: D50098310
fbshipit-source-id: e321fca7b2f7983e903e23237bc2d604c72f98a3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39646
We can dramatically simplify this code and remove quirks/hacks, now that we can assume layout events are always fired top down.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D49628669
fbshipit-source-id: 7de5bbc4597eba1c59aaa7672c70e76d2786c7ef
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40748
The ordering of `onLayout` events is non-deterministic on iOS Paper, due to nodes being added to an `NSHashTable` before iteration, instead of an ordered collection.
We don't do any lookups on the collection, so I think this was chosen over `NSMutableArray` for the sake of `[NSHashTable weakObjectsHashTable]`, to avoid retain/release. Using a collection which does retain/release seems to cause a crash due to double release or similar, so those semantics seem intentional (though I'm not super familiar with the model here).
We can replicate the memory semantics with ordering by using `NSPointerArray` (which is unfortunately not parameterized). This change does that, so we get consistently top-down layout events (matching Fabric, and Android Paper as of D49627996). This lets us use multiple layout events to calculate right/bottom edge insets deterministically.
Changelog:
[iOS][Changed] - Deterministic onLayout event ordering for iOS Paper
Reviewed By: luluwu2032
Differential Revision: D50093411
fbshipit-source-id: f6a9d5c973b97aede879baa8b952cc1be2447f28
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39644
This makes Android Paper/Classic renderer fire `onLayout` events top down, like in Fabric/new Architecture. This gives a much more sane model for using layout events to calculate bottom/right-edge insets.
I was under the impression that Paper in general was bottom-up, but it turns out that is only true for Android and Windows (iOS seems totally deterministic).
This is a behavior change, but to my knowledge was never hit during the Fabric migration, and any JS code already written for both Android and iOS cannot make assumptions here anyways.
Changelog:
[General][Changed] - Make layout events top-down on Android classic renderer
Reviewed By: mdvacca
Differential Revision: D49627996
fbshipit-source-id: 29964b421dd420681d45348c7db16f211a6c087f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/40766
This changeset allows users to opt into the new debugger frontend experience by passing `--experimental-debugger` to `react-native start`. **We are defaulting this option to `true`** for now, but will continue to evaluate this feature before 0.73 ships. It restores Flipper (via `flipper://`) as the default handling for `/open-debugger` (matching 0.72 behaviour) when this flag is not enabled.
Detailed changes:
- Replaces `enableCustomDebuggerFrontend` experiment in `dev-middleware` with `enableNewDebugger`. The latter now hard-swaps between the Flipper and new launch flows.
- Removes now-unused switching of `devtoolsFrontendUrl`.
- Implements `deprecated_openFlipperMiddleware` (matching previous RN CLI implementation).
- Disables "`j` to debug" key handler by default.
- Marks "`j` to debug" and `/open-debugger` console logs as experimental.
Changelog:
[Changed][General] Gate new debugger frontend behind `--experimental-debugger` flag, restore Flipper as base launch flow
Reviewed By: motiz88
Differential Revision: D50084590
fbshipit-source-id: 5234634f20110cb7933b1787bd2c86f645411fff
Summary:
Changelog: [Internal] - Set the hermes value as specified by the test-e2e-local script flag. Right now, the script incorrectly ignores the flag
By default, the template project has `hermesEnabled=true`
Reviewed By: cipolleschi
Differential Revision: D49831355
fbshipit-source-id: 7fb8613fa86f2c6140b7d25b16aeb583e6e26c12
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39828
Active Suppert released a new Gem which is incompatible with Cocoapods 1.13.0, the latest release, as they removed a method used by cocoapods.
This fix ensures that we install compatible versions of the Gem.
## Changelog:
[iOS][Fixed] - Set the max version of Active support to 7.0.8
Reviewed By: hoxyq
Differential Revision: D49949782
fbshipit-source-id: 278097502d3a416567cc8c0b90090fee4fb21503
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39704
Default to native view configs in bridged mode and to static view configs in bridgeless mode.
Remove `setRuntimeConfigProvider` calls from RNTester and from the Template.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49687252
fbshipit-source-id: 140e1c510ba3fbc153978b59c8bb4b4e35bc7571
Summary:
The Loading.../Refreshing... indicator is currently broken on Android.
The reason is related to D42599220
We used to have a Toast shown to users on Android as a fallback, but as the
DevLoadingView is not always loaded as a module in the core package, this ends up in the banner never beign shown to the user (on RN Tester or template apps).
Changelog:
[Android] [Fixed] - Fix broken Loading/Refreshing indicator on Android
Reviewed By: cipolleschi
Differential Revision: D49876757
fbshipit-source-id: 400e002327ebca908e3e7a7f81c5066888ac4e9b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39755
The goal of this diff is to fix:
```
JNI DETECTED ERROR IN APPLICATION: JNI NewGlobalRef called with pending exception java.lang.NoSuchMethodError: no static or non-static method
"Lcom/facebook/react/jscexecutor/JSCExecutor;.initHybrid(Lcom/facebook/react/bridge/ReadableNativeMap;)Lcom/facebook/jni/HybridData;"
```
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D49831595
fbshipit-source-id: 9ce22cdccdd02af74edb27be2df72a469d3166c9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39710
Last week Apple released Xcode 15, which required us to ship a workaround for the new linker.
Unfortunately, the previous fix was not good enough and there were some edge cases that were not covered.
For example, in some occasions the flags are read as an array and the `-Wl` and the `-ld_classic` flags were separated and not properly removed when moving from Xcode 15 to Xcpde 14.3.1.
This change fixes those edge cases, with a more robust solution where:
- We convert the flags to a string.
- We trim the string and the values properly.
- We add the flags when running `pod install` with Xcode 15 as the default iOS toolchain.
- We remove the flags when running `pod install` with Xcode <15 as the default iOS toolchain.
## Changelog:
[Internal] - Make the Xcode 15 workaround more robust.
Reviewed By: dmytrorykun
Differential Revision: D49748844
fbshipit-source-id: 34976d148f123c5aacba6487a500874bb938fe99
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39696
`Commands` and `Constants` should be set in native only if component data is instantiated via native view config interop layer.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D49684166
fbshipit-source-id: ceaa29c2ed3336aa6e21a116a3f5f94e03c225c1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/39640
changelog: [internal] internal
Reducing visibility from public to package only for `ReactHostImpl.getDefaultHardwareBackBtnHandler()` since it's only used within package
Reviewed By: mdvacca
Differential Revision: D49612859
fbshipit-source-id: 3c40888da732f33dc046d9363b08119e707f4ea4
import*asefrom"../platform/platform.js";constt=newURLSearchParams(location.search);letn,s="";classr{constructor(){}staticinstance(e={forceNew:null}){const{forceNew:t}=e;returnn&&!t||(n=newr),n}staticremoveInstance(){n=void0}staticqueryParam(e){returnt.get(e)}staticsetQueryParamForTesting(e,n){t.set(e,n)}staticexperimentsSetting(){try{returnJSON.parse(self.localStorage&&self.localStorage.experiments?self.localStorage.experiments:"{}")}catch(e){returnconsole.error("Failed to parse localStorage['experiments']"),{}}}staticsetPlatform(e){s=e}staticplatform(){returns}staticisDescriptorEnabled(e){constt=e.experiment;if("*"===t)return!0;if(t&&t.startsWith("!")&&o.isEnabled(t.substring(1)))return!1;if(t&&!t.startsWith("!")&&!o.isEnabled(t))return!1;constn=e.condition;return!(n&&!n.startsWith("!")&&!r.queryParam(n))&&!(n&&n.startsWith("!")&&r.queryParam(n.substring(1)))}loadLegacyModule(e){returnimport(`../../${e}`)}}classi{#e;#t;#n;#s;#r;#i;constructor(){this.#e=[],this.#t=newSet,this.#n=newSet,this.#s=newSet,this.#r=newSet,this.#i=newSet}allConfigurableExperiments(){conste=[];for(consttofthis.#e)this.#n.has(t.name)||this.#i.has(t.name)||e.push(t);returne}enabledExperiments(){returnthis.#e.filter((e=>e.isEnabled()))}setExperimentsSetting(e){self.localStorage&&(self.localStorage.experiments=JSON.stringify(e))}register(t,n,s,r,i){this.#t.add(t),this.#e.push(newa(this,t,n,Boolean(s),r??e.DevToolsPath.EmptyUrlString,i??e.DevToolsPath.EmptyUrlString))}isEnabled(e){returnthis.checkExperiment(e),!1!==r.experimentsSetting()[e]&&(!(!this.#n.has(e)&&!this.#s.has(e))||(!!this.#r.has(e)||Boolean(r.experimentsSetting()[e])))}setEnabled(e,t){this.checkExperiment(e);constn=r.experimentsSetting();n[e]=t,this.setExperimentsSetting(n)}enableExperimentsTransiently(e){for(consttofe)this.checkExperiment(t),this.#n.add(t)}enableExperimentsByDefault(e){for(consttofe)this.checkExperiment(t),this.#s.add(t)}setServerEnabledExperiments(e){for(consttofe)this.checkExperiment(t),this.#r.add(t)}setNonConfigurableExperiments(e){for(consttofe)this.checkExperiment(t),this.#i.add(t)}enableForTest(e){this.checkExperiment(e),this.#n.add(e)}disableForTest(e){this.checkExperiment(e),this.#n.delete(e)}clearForTest(){this.#e=[],this.#t.clear(),this.#n.clear(),this.#s.clear(),this.#r.clear()}cleanUpStaleExperiments(){conste=r.experimentsSetting(),t={};for(const{name:n}ofthis.#e)if(e.hasOwnProperty(n)){consts=e[n];(s||this.#s.has(n))&&(t[n]=s)}this.setExperimentsSetting(t)}checkExperiment(e){}}classa{name;title;unstable;docLink;feedbackLink;#e;constructor(e,t,n,s,r,i){this.name=t,this.title=n,this.unstable=s,this.docLink=r,this.feedbackLink=i,this.#e=e}isEnabled(){returnthis.#e.isEnabled(this.name)}setEnabled(e){this.#e.setEnabled(this.name,e)}}consto=newi;varl,E;!function(e){e.CAPTURE_NODE_CREATION_STACKS="captureNodeCreationStacks",e.CSS_OVERVIEW="cssOverview",e.LIVE_HEAP_PROFILE="liveHeapProfile",e.DEVELOPER_RESOURCES_VIEW="developerResourcesView",e.CSP_VIOLATIONS_VIEW="cspViolationsView",e.WASM_DWARF_DEBUGGING="wasmDWARFDebugging",e.ALL="*",e.PROTOCOL_MONITOR="protocolMonitor",e.WEBAUTHN_PANE="webauthnPane",e.FULL_ACCESSIBILITY_TREE="fullAccessibilityTree",e.PRECISE_CHANGES="preciseChanges",e.STYLES_PANE_CSS_CHANGES="stylesPaneCSSChanges",e.HEADER_OVERRIDES="headerOverrides",e.EYEDROPPER_COLOR_PICKER="eyedropperColorPicker",e.INSTRUMENTATION_BREAKPOINTS="instrumentationBreakpoints",e.AUTHORED_DEPLOYED_GROUPING="authoredDeployedGrouping",e.IMPORTANT_DOM_PROPERTIES="importantDOMProperties",e.JUST_MY_CODE="justMyCode",e.PRELOADING_STATUS_PANEL="preloadingStatusPanel",e.DISABLE_COLOR_FORMAT_SETTING="disableColorFormatSetting",e.TIMELINE_AS_CONSOLE_PROFILE_RESULT_PANEL="timelineAsConsoleProfileResultPanel",e.OUTERMOST_TARGET_SELECTOR="outermostTargetSelector",e.JS_PROFILER_TEMP_ENABLE="jsProfilerTemporarilyEnable",e.HIGHLIGHT_ERRORS_ELEMENTS_PANEL="highlightErrorsElementsPanel",e.SET_ALL_BREAKPOINTS_EAGERLY="setAllBreakpointsEagerly",e.REACT_NATIVE_SPECIFIC_UI="reactNativeSpecificUI"}(l||(l={})),function(e){e.CAN_DOCK="can_dock",e.NOT_SOURCES_HIDE_ADD_FOLDER="!sources.hide_add_folder"}(E||(E={}));varc=Object.freeze({__proto__:null,getRemoteBase:function(e=self.location.toString()){constt=newURL(e).searchParams.get("remoteBase");if(!t)returnnull;constn=/\/serve_file\/(@[0-9a-zA-Z]+)\/?$/.exec(t);returnn?{base:`devtools://devtools/remote/serve_file/${n[1]}/`,version:n[1]}:null},Runtime:r,ExperimentsSupport:i,Experiment:a,experiments:o,getExperimentName(){returnl},getConditionName(){returnE}});export{casRuntime};
import*asefrom"../platform/platform.js";constt=newURLSearchParams(location.search);letn,s="";classr{constructor(){}staticinstance(e={forceNew:null}){const{forceNew:t}=e;returnn&&!t||(n=newr),n}staticremoveInstance(){n=void0}staticqueryParam(e){returnt.get(e)}staticsetQueryParamForTesting(e,n){t.set(e,n)}staticexperimentsSetting(){try{returnJSON.parse(self.localStorage&&self.localStorage.experiments?self.localStorage.experiments:"{}")}catch(e){returnconsole.error("Failed to parse localStorage['experiments']"),{}}}staticsetPlatform(e){s=e}staticplatform(){returns}staticisDescriptorEnabled(e){constt=e.experiment;if("*"===t)return!0;if(t&&t.startsWith("!")&&l.isEnabled(t.substring(1)))return!1;if(t&&!t.startsWith("!")&&!l.isEnabled(t))return!1;constn=e.condition;return!(n&&!n.startsWith("!")&&!r.queryParam(n))&&!(n&&n.startsWith("!")&&r.queryParam(n.substring(1)))}loadLegacyModule(e){returnimport(`../../${e}`)}}classi{#e;#t;#n;#s;#r;#i;constructor(){this.#e=[],this.#t=newSet,this.#n=newSet,this.#s=newSet,this.#r=newSet,this.#i=newSet}allConfigurableExperiments(){conste=[];for(consttofthis.#e)this.#n.has(t.name)||this.#i.has(t.name)||e.push(t);returne}enabledExperiments(){returnthis.#e.filter((e=>e.isEnabled()))}setExperimentsSetting(e){self.localStorage&&(self.localStorage.experiments=JSON.stringify(e))}register(t,n,s,r,i){this.#t.add(t),this.#e.push(newa(this,t,n,Boolean(s),r??e.DevToolsPath.EmptyUrlString,i??e.DevToolsPath.EmptyUrlString))}isEnabled(e){returnthis.checkExperiment(e),!1!==r.experimentsSetting()[e]&&(!(!this.#n.has(e)&&!this.#s.has(e))||(!!this.#r.has(e)||Boolean(r.experimentsSetting()[e])))}setEnabled(e,t){this.checkExperiment(e);constn=r.experimentsSetting();n[e]=t,this.setExperimentsSetting(n)}enableExperimentsTransiently(e){for(consttofe)this.checkExperiment(t),this.#n.add(t)}enableExperimentsByDefault(e){for(consttofe)this.checkExperiment(t),this.#s.add(t)}setServerEnabledExperiments(e){for(consttofe)this.checkExperiment(t),this.#r.add(t)}setNonConfigurableExperiments(e){for(consttofe)this.checkExperiment(t),this.#i.add(t)}enableForTest(e){this.checkExperiment(e),this.#n.add(e)}disableForTest(e){this.checkExperiment(e),this.#n.delete(e)}clearForTest(){this.#e=[],this.#t.clear(),this.#n.clear(),this.#s.clear(),this.#r.clear()}cleanUpStaleExperiments(){conste=r.experimentsSetting(),t={};for(const{name:n}ofthis.#e)if(e.hasOwnProperty(n)){consts=e[n];(s||this.#s.has(n))&&(t[n]=s)}this.setExperimentsSetting(t)}checkExperiment(e){}}classa{name;title;unstable;docLink;feedbackLink;#e;constructor(e,t,n,s,r,i){this.name=t,this.title=n,this.unstable=s,this.docLink=r,this.feedbackLink=i,this.#e=e}isEnabled(){returnthis.#e.isEnabled(this.name)}setEnabled(e){this.#e.setEnabled(this.name,e)}}constl=newi;varo,E;!function(e){e.CAPTURE_NODE_CREATION_STACKS="captureNodeCreationStacks",e.CSS_OVERVIEW="cssOverview",e.LIVE_HEAP_PROFILE="liveHeapProfile",e.DEVELOPER_RESOURCES_VIEW="developerResourcesView",e.CSP_VIOLATIONS_VIEW="cspViolationsView",e.WASM_DWARF_DEBUGGING="wasmDWARFDebugging",e.ALL="*",e.PROTOCOL_MONITOR="protocolMonitor",e.WEBAUTHN_PANE="webauthnPane",e.FULL_ACCESSIBILITY_TREE="fullAccessibilityTree",e.PRECISE_CHANGES="preciseChanges",e.STYLES_PANE_CSS_CHANGES="stylesPaneCSSChanges",e.HEADER_OVERRIDES="headerOverrides",e.EYEDROPPER_COLOR_PICKER="eyedropperColorPicker",e.INSTRUMENTATION_BREAKPOINTS="instrumentationBreakpoints",e.AUTHORED_DEPLOYED_GROUPING="authoredDeployedGrouping",e.IMPORTANT_DOM_PROPERTIES="importantDOMProperties",e.JUST_MY_CODE="justMyCode",e.PRELOADING_STATUS_PANEL="preloadingStatusPanel",e.DISABLE_COLOR_FORMAT_SETTING="disableColorFormatSetting",e.TIMELINE_AS_CONSOLE_PROFILE_RESULT_PANEL="timelineAsConsoleProfileResultPanel",e.OUTERMOST_TARGET_SELECTOR="outermostTargetSelector",e.JS_PROFILER_TEMP_ENABLE="jsProfilerTemporarilyEnable",e.HIGHLIGHT_ERRORS_ELEMENTS_PANEL="highlightErrorsElementsPanel",e.SET_ALL_BREAKPOINTS_EAGERLY="setAllBreakpointsEagerly",e.REACT_NATIVE_SPECIFIC_UI="reactNativeSpecificUI"}(o||(o={})),function(e){e.CAN_DOCK="can_dock",e.NOT_SOURCES_HIDE_ADD_FOLDER="!sources.hide_add_folder",e.REACT_NATIVE_UNSTABLE_NETWORK_PANEL="unstable_enableNetworkPanel"}(E||(E={}));varc=Object.freeze({__proto__:null,getRemoteBase:function(e=self.location.toString()){constt=newURL(e).searchParams.get("remoteBase");if(!t)returnnull;constn=/\/serve_file\/(@[0-9a-zA-Z]+)\/?$/.exec(t);returnn?{base:`devtools://devtools/remote/serve_file/${n[1]}/`,version:n[1]}:null},Runtime:r,ExperimentsSupport:i,Experiment:a,experiments:l,getExperimentName(){returno},getConditionName(){returnE}});export{casRuntime};
@@ -1020,6 +1020,54 @@ Please follow the instructions at: fburl.com/rn-remote-assets`,
});
});
it('detects a component stack for ts, tsx, jsx, and js files',()=>{
expect(
parseLogBoxLog([
'Some kind of message\n in MyTSComponent (at MyTSXComponent.ts:1)\n in MyTSXComponent (at MyTSCComponent.tsx:1)\n in MyJSXComponent (at MyJSXComponent.jsx:1)\n in MyJSComponent (at MyJSComponent.js:1)',
]),
).toEqual({
componentStack:[
{
content:'MyTSComponent',
fileName:'MyTSXComponent.ts',
location:{
column:-1,
row:1,
},
},
{
content:'MyTSXComponent',
fileName:'MyTSCComponent.tsx',
location:{
column:-1,
row:1,
},
},
{
content:'MyJSXComponent',
fileName:'MyJSXComponent.jsx',
location:{
column:-1,
row:1,
},
},
{
content:'MyJSComponent',
fileName:'MyJSComponent.js',
location:{
column:-1,
row:1,
},
},
],
category:'Some kind of message',
message:{
content:'Some kind of message',
substitutions:[],
},
});
});
it('detects a component stack in the first argument (JSC)',()=>{
@"This method isn't implemented faithfully: the viewRegistry passed to RCTViewManagerUIBlock is nil. Please migrate to RCTViewRegistry: @synthesize viewRegistry_DEPRECATED = _viewRegistry_DEPRECATED."
@"This method isn't implemented faithfully. Please migrate to RCTViewRegistry if possible: @synthesize viewRegistry_DEPRECATED = _viewRegistry_DEPRECATED."
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Distiller
Riccardo Cipolleschi
hurali97andThibault Malbranche
Riccardo CipolleschiandThibault Malbranche
Alex Hunt
Alfonso Curbelo
Distiller
Phillip PanandAlfonso Curbelo
Jean-Baptiste LARRIVIEREandAlfonso Curbelo
Nick GerlemanandAlfonso Curbelo
huangtaibinandAlfonso Curbelo
Evert EtiandAlfonso Curbelo
Distiller
Luna Wei
Samuel Suslaandhurali97
Distiller
Fabrizio BertoglioandLuna Wei
Szymon RybczakandGitHub
Tommy NguyenandGitHub
Dr. Sergey PogodinandLuna Wei
Distiller
Lulu WuandLuna Wei
Dmitry RykunandLuna Wei
Distiller
Blake Friedman
zhongwuzwandBlake Friedman
Gabriel DonadelandBlake Friedman
LIM AlbertandBlake Friedman
Paul SchreiberandBlake Friedman
William FernandesandBlake Friedman
Distiller
Alex HuntandAlex Hunt
David VaccaandAlex Hunt
Oscar FrancoandAlex Hunt
LunaandGitHub
MorritzandAlex Hunt
Janic DuplessisandAlex Hunt
Ivan AlexandrovandAlex Hunt
Moti ZilbermanandAlex Hunt
Distiller
Rui YingandThibault Malbranche
Cedric van PuttenandAlex Hunt
Krzysztof PiaskowyandAlex Hunt
Michał PierzchałaandAlex Hunt
Distiller
Distiller
generatedunixname89002005232357andAlex Hunt
Distiller
Will SchurmanandAlex Hunt
Distiller
Nicola CortiandAlex Hunt
Christoph PurrerandAlex Hunt
Distiller
Luna Wei
Jesse Watts-RussellandLuna Wei
Kacper KafaraandLuna Wei
Distiller
Rob HoganandLuna Wei
tarunrajputandLuna Wei
Rob HoganandRob Hogan
Distiller
OleksiiandAlex Hunt
Saad NajmiandAlex Hunt
DeokHyeon WiandAlex Hunt
UNIDY2002andAlex Hunt
116-7andAlex Hunt
Distiller
NishanandLuna Wei
Distiller
Distiller
Distiller
Distiller
Ramanpreet NaraandLuna Wei
Arushi KesarwaniandLuna Wei
Alex HuntandGitHub
