Summary:
## Context
Right now we are using both LogBox and ExceptionsManager native module to report JS errors in ExceptionsManager.js, from below code we can tell they have some overlapping - when ```__DEV__ === true``` both could report the error.
https://www.internalfb.com/code/fbsource/[5fb44bc926de87e62e6e538082496f22017698eb]/xplat/js/react-native-github/Libraries/Core/ExceptionsManager.js?lines=109-141
## Changes
In this diff overlapping is removed: in ```ExceptionsManager.js``` LogBox will be responsible for showing the error with dialog when ```__DEV__ === true```, when it's prod we'll use ExceptionsManager native module to report the error. As a result LogBox and ExceptionsManager native module don't share responsibilities any more.
Changelog:
[General][Changed] - Remove shared responsibility between LogBox and ExceptionsManager native module
Reviewed By: philIip
Differential Revision: D30942433
fbshipit-source-id: 8fceaaa431e5a460c0ccd151fe9831dcccbcf237
Summary:
This module is imported by all flavors of the React Native renderers (dev/prod, Fabric/Paper, etc.), which itself imports `InitializeCore`. This is effectively a no-op in most React Native apps because Metro adds it as a module to execute before the entrypoint of the bundle.
This import would be harmless if all React Native apps included all polyfills and globals, but some of them don't want to include everything and instead of importing `InitializeCore` they import individual setup functions (like `setupXhr`). Having this automatic import in the renderer defeats that purpose (most importantly for app size), so we should remove it.
The main motivation for this change is to increase the number (and spec-compliance) of Web APIs that are supported out of the box without adding that cost to apps that choose not to use some of them (see https://github.com/facebook/react-native/pull/30188#issuecomment-929352747).
Changelog: [General][Removed] Breaking: Removed initialization of React Native polyfills and global variables from React renderers.
Note: this will only be a breaking change for apps not using the React Native CLI, Expo nor have a Metro configuration that executes `InitializeCore` automatically before the bundle EntryPoint.
Reviewed By: yungsters
Differential Revision: D31472153
fbshipit-source-id: 92eb113c83f77dbe414869fbce152a22f3617dcb
Summary:
We are defining an alias for the global variable in React Native called `GLOBAL`, which is not used at all at Facebook and it doesn't seem it's used externally either. This alias is not standard nor common in the JS ecosystem, so we can just remove it to reduce the pollution of the global scope.
Changelog: [General][Removed] - Removed unnecessary global variable `GLOBAL`.
Reviewed By: yungsters
Differential Revision: D31472154
fbshipit-source-id: 127c3264848b638f85fb2e39e17ed2006372d2dd
Summary:
The Modal's mock always render its children (whether it is visible or not), whereas in reality the Modal renders `null` when the Modal is not visible.
This causes troubles when trying to test whether the Modal is visible or not. Instead of testing if the children are rendered (using getByText from React Native Testing Library for instance), we are forced to test the value of the visible prop directly (see https://github.com/callstack/react-native-testing-library/issues/508 and https://github.com/callstack/react-native-testing-library/issues/659).
This is not ideal because we are forced to test implementation detail and can't test from the user perspective. I also believe the mock should be closest as possible from reality.
I had 2 options:
1. Rendering the Modal without its children
2. Not rendering the Modal at all
The latter has the advantage of being closer to the reality, but I chose the former to still be able to test the Modal through the visible prop, so there is no breaking change (only snapshots update will be required).
## Changelog
[General] [Changed] - Update Modal's mock to not render its children when it is not visible
Pull Request resolved: https://github.com/facebook/react-native/pull/32346
Test Plan:
I added a test case when visible is false, then updated the mock so the children are not rendered. The before / after is here:
Reviewed By: yungsters
Differential Revision: D31445964
Pulled By: lunaleaps
fbshipit-source-id: 08501921455728cde6befd0103016c95074cc1df
Summary:
changelog: [internal]
Catch JavaScript errors and forward them to `ErrorUtils` in *RuntimeScheduler*. This makes sure that JS errors are handled by ErrorUtils and do not bubble up to bridge.
Reviewed By: philIip
Differential Revision: D31429001
fbshipit-source-id: 50f865872e4cd3ba180056099ff40f5962ee7a77
Summary:
We noticed that by default when the RootView / ReactView calls runApplication, we're logging at an info level any props ("params") passed to that component. In our case, one of these props was sensitive in nature, causing the value to leak out in logs for our release builds. This is especially problematic on Android where device logs can be accessed by any app which requests that permission.
This is probably more of a concern for brownfield react-native apps, but it seems worthwhile locking this down in non-dev builds.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Security] - Avoiding logging root view params outside of dev / debug mode builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31522
Test Plan: * build app in release mode on Android and verified I could not see: `Running "my app" with { sensitive: 'thing' }` in logcat in Android Studio with a tethered device
Reviewed By: yungsters
Differential Revision: D31064902
Pulled By: charlesbdudley
fbshipit-source-id: 8b10a46d92a9ec44243dd74384299087260c7d83
Summary:
This PR fixes a few issues with the Appearance API (as noted here https://github.com/facebook/react-native/issues/28823).
1. For the Appearance API to work correctly on Android you need to call `AppearanceModule.onConfigurationChanged` when the current Activity goes through a configuration change. This was being called in the RNTester app but not in `ReactActivity` so it meant the Appearance API wouldn't work for Android in newly generated RN projects (or ones upgraded to the latest version of RN).
2. The Appearance API wasn't working correctly for brownfield scenarios on Android. It's possible to force an app light or dark natively on Android by calling `AppCompatDelegate.setDefaultNightMode()`. The Appearance API wasn't picking up changes from this function because it was using the Application context instead of the current Activity context.
3. The Appearance API wasn't working correctly for brownfield scenarios on iOS. Just like on Android its possible to force an app light or dark natively by setting `window.overrideUserInterfaceStyle`. The Appearance API didn't work with this override because we were overwriting `_currentColorScheme` back to default as soon as we set it.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
### Fixed
https://github.com/facebook/react-native/issues/28823
* [Android] [Fixed] - Appearance API now works on Android
* [Android] [Fixed] - Appearance API now works correctly when calling `AppCompatDelegate.setDefaultNightMode()`
* [iOS] [Fixed] - Appearance API now works correctly when setting `window.overrideUserInterfaceStyle`
Pull Request resolved: https://github.com/facebook/react-native/pull/29106
Test Plan: Ran RNTester on iOS and Android and verified the Appearance examples still worked [correctly.](url)
Reviewed By: hramos
Differential Revision: D31284331
Pulled By: sota000
fbshipit-source-id: 45bbe33983e506eb177d596d33ddf15f846708fd
Summary:
In https://github.com/facebook/react-native/issues/31609, the deprecated `jcenter()` was replaced with `mavenCentral()`. In the template build.gradle, it _also changed the order of repos_. I am not sure if this was done intentionally or not (dulmandakh please confirm). Instead of appearing right _after_ `google()`, `mavenCentral()` was put **first** in the list, even before the local repos (that, for example, contain the `react-native` artifacts fetched by npm). Now, under normal circumstance, this _might_ not cause issues because of latency, but there is chance that Gradle could resolve incorrect versions (or at least look in the wrong repo first). The last version of `react-native` published to the public repo was [`0.20.1`](https://mvnrepository.com/artifact/com.facebook.react/react-native/0.20.1), uploaded in February 2016!
This PR changes the order of `mavenCentral()` so that is consistent with both the repo's current [root level build.gradle](https://github.com/facebook/react-native/blob/main/build.gradle.kts#L34), as well as other default Android templates. Putting the local repos first will ensure they have the highest priority when looking for artifacts. `react-native` should _always_ come from the locally downloaded `node_modules/` folder, not from a remote repo.
## Changelog
[Android] [Changed] - Move mavenCentral repo below local paths
Pull Request resolved: https://github.com/facebook/react-native/pull/32326
Test Plan: Create new app from template, ensure local repos appear before remote repos; `react-native` resolves to correct version.
Reviewed By: yungsters
Differential Revision: D31375678
Pulled By: cortinico
fbshipit-source-id: e47737262b4eebb06e22a955cacd6114059bb2f4
Summary:
When the overflow style set to 'scroll', React ViewGroup does nothing to the container. Instead it should be clipped just like hidden.
Changelog:
[Android][Changed] - Setting `overflow: scroll` in View component style will clip the children in the View container
Reviewed By: javache
Differential Revision: D31350605
fbshipit-source-id: e0d618f5e872fec9cf9ecb2d4cfe7af9a2f3c063
Summary:
changelog: [internal]
Retaining `EventEmitter` beyond runtime triggers a crash. Let's try to use raw pointer in `EventEmitterWrapper` to see if it fixes some crashes.
Reviewed By: philIip
Differential Revision: D31307332
fbshipit-source-id: cd059b6c56f8dffe985b3ecb62cdafe823ba1462
Summary:
Implement par of the discussion https://github.com/react-native-community/discussions-and-proposals/discussions/411, except the `.nvmrc` part, this includes:
- Setting `.ruby-version` in the main project and also `template/`
- Fixing the CocoaPods version with a project-level `Gemfile` and also `template/Gemfile`
- Using all `pod` executions from `bundle exec pod`, using the determined version
- Script to manage and update the ruby version
## Changelog
[iOS] [Added] - Gemfile with CocoaPods 1.11 and ruby-version (2.7.4)
Pull Request resolved: https://github.com/facebook/react-native/pull/32303
Test Plan: Build for iOS and run all CircleCI tests to see if nothing changed
Reviewed By: RSNara
Differential Revision: D31344686
Pulled By: fkgozali
fbshipit-source-id: 25c63131ca9b16d3cf6341019548e0d63bdcaefe
Summary:
Changelog: [Internal]
https://fb.workplace.com/groups/rn.support/posts/6677051292343429
ax team is building a tool to extract information about the views for design reviewers, and RN has some AX information that is not working atm because of dependency on whether voiceover is on or not. so, this will give them the ability to programmatically set that field and hopefully be able to get accurate ax info
Reviewed By: ikenwoo
Differential Revision: D31010566
fbshipit-source-id: 4c8a33fce40266b270dd5994442c8472ca88f5dd
Summary:
changelog: [internal]
This is a pre-condition to get rid of `shared_ptr` from `EventEmitterWrapper`. Also saves us a few copies of shared_ptr, this is negligible though.
Reviewed By: mdvacca
Differential Revision: D31307048
fbshipit-source-id: b84654bed2359b66faf3995795e135e88fe51cb6
Summary:
Event merging or "coalescing" is done on Java side from Android, but Fabric also includes some Cxx logic to merge those events. Although Android doesn't need this logic in particular, it is important to follow this path to ensure these events (e.g. scroll) are dispatched as "continuous", allowing for correct prioritization in Concurrent Mode.
`dispatchModernV2` selects between `dispatch` and `dispatchUnique` based on the `canBeCoalesced` parameter of the event, which is exactly what we need. The logic is only used in the "new" event dispatcher at the moment, so I wrapped it with feature flag to validate it doesn't cause any regressions.
Changelog:
[Android][Internal] - Try dispatching coalescing events as unique to Fabric
Reviewed By: sammy-SC
Differential Revision: D31272585
fbshipit-source-id: 6b67b61bd13fbff019d9eb8c5172bdd814a7b5b8
Summary:
Assuming this method was deprecated to mean experimental.
This execution path is used by overwhelming majority of events and it seems as stable as it can be.
Changelog:
[Android][Changed] Removed experimental deprecation from `dispatchModern`
Reviewed By: cortinico
Differential Revision: D31270721
fbshipit-source-id: 5a7e50455ab2850adf9bc86a248773b170bf0ab9
Summary:
We forgot to make ClipboardModule TurboModule compatible. I think this was most likely because our codemods targeted all Java classes that extended ReactContextBaseJavaModule. The ClipboardModule extends ContextBaseJavaModule instead.
There are no other NativeModules that extend ContextBaseJavaModule.
Changelog: [Internal]
Reviewed By: sshic
Differential Revision: D31291293
fbshipit-source-id: cf5d21898101699f8c349b013a77e8329339a8d3
Summary:
Pressability previously was filtering which events get forwarded through the PerformanceEventEmitter, but this causes issues for native telemetry systems which won't know which events Pressability has skipped (or why).
Also, the "delay ms" no longer has any meaning because the native timestamps and Date.now() have a different time-basis entirely.
Changelog: [Internal]
Differential Revision: D31251300
fbshipit-source-id: f097047ac150e8dddb0f3857d9f375bae2318681
Summary:
Original commit changeset: ab1e842b60c5
Changelog:
[Internal] [Changed] - Back out "[RN][Android] Make react-native depend on react-native-gradle-plugin"
Reviewed By: fkgozali
Differential Revision: D31310547
fbshipit-source-id: 46c4c1e41b0f5432bc24975f754e0852e7180769
Summary:
Similarly to what we did for react-native-codegen, I'm introducing
a dependency between RN and the Gradle plugin, to be processed upon OSS bumps.
Changelog:
[General] [Added] - Make react-native depend on react-native-gradle-plugin
Reviewed By: fkgozali
Differential Revision: D31206303
fbshipit-source-id: ab1e842b60c51d0dce272892a30be2e27350f9bb
Summary:
When we were iterating on the Fabric renderer, animated components went through some iteration to ensure that animated shadow nodes were not flattened away. At the time, `collapsable` was not supported on iOS, even in Fabric, because the legacy renderer would not publish the `collapsable` prop on the view config.
This has since been fixed and `collapsable` is supported on both Android and iOS. We no longer need the `nativeID` workaround to prevent view flattening.
For use cases of the JavaScript driver and legacy renderers, this change will cause views which used to be flattened to no longer be flattened. This seems like an appropriate change considering the direction that we are moving (in which everything is eventually transitioned to using the Fabric renderer).
Changelog:
[Android][Changed] - Native views backing Animated.View (w/ JavaScript-driven animations) will no longer be flattened; this should be a transparent change.
Reviewed By: lunaleaps, mdvacca
Differential Revision: D31223031
fbshipit-source-id: 48dc63471eef406f4c215bfea0b3ef82a05d4b24
Summary:
Add examples for Switch component in RN Tester app for:
- ios_backgroundColor
- onChange
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[General] [Added] - Added examples to Switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/30611
Test Plan: 
Reviewed By: lunaleaps
Differential Revision: D25680480
Pulled By: sota000
fbshipit-source-id: 91202a0d8699554b0535f1a91875fd9fc664d54d
Summary:
Expands the building of npm tarballs to include branches that match the /^(\d+)\.(\d+)-stable$/ regexp.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D31272377
fbshipit-source-id: a536a0b5e14812ece8266f3c83497071405a164a
Summary:
changelog: [internal]
This code assured that view preallocation is only triggered if ShadowNode is cloned from revision 0 to revision 1 (first time ShadowNode is cloned).
Node can go from virtual to view forming in subsequent clones, not just the first one. This is more of a case in Concurrent React where the node can be cloned many times before it is first mounted.
Reviewed By: mdvacca
Differential Revision: D31237719
fbshipit-source-id: 13fe6d10fdc815dbdae785d1d9d86d1c8fd36be4
Summary:
Updates event category deduction to match iOS implementation.
The event priority is used by concurrent mode to prioritize certain events, where Cxx part already assigns the correct priority based on the `ContinuousStart` -> `ContinuousEnd` spans. These spans can be deduced from the touch events, which we do in this implementation.
All events that can be "coalesced" (dispatched through `invokeUnique`) are assigned `Continuous` by default in Fabric core, so scroll/slider change events will never be discrete.
Changelog:
[Internal] Add category deduction to Android touch events
Reviewed By: mdvacca
Differential Revision: D31233233
fbshipit-source-id: f5b039aa137f1b4d2e2b15578bfc29ab6903a081
Summary:
For iOS, event category deduction is done from the C++ code, but the touch events are handled on Java layer in Android. This change exposes the category parameter through the `EventEmitterWrapper` called from Java, allowing to define category for events in the future.
Changelog:
[Internal] - Expose event category through JNI
Reviewed By: mdvacca
Differential Revision: D31205587
fbshipit-source-id: f2373ce18464b01ac08eb87df8f421b33d100be2
Summary:
Removes `metro-babel-register` as a runtime dependency of the `react-native` package, where it is only used as a dev dependency (in the Jest preprocessor).
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D31177424
fbshipit-source-id: bf7b7216116744a3234beea089d0028c0bfe4d1e
Summary:
Fix Image defaultSource not showing on iOS.
This bug was introduced somewhere between RN 0.63 and 0.65. On iOS, defaultSource does not show while the image is being downloaded, only if it fails or there's no internet.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix Image defaultSource not showing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/32172
Test Plan: Ran both debug and release builds on an iPhone 12 pro (iOS 14.6)
Reviewed By: sammy-SC
Differential Revision: D30822805
Pulled By: lunaleaps
fbshipit-source-id: c4ef18723a8311ef3be1d7ae25ff3c205e8fff62
Summary:
This diff extends the current implementation of ScrollView.snapToAlignments from RN Android to reach feature parity with RNiOS
changelog: [Android][Changed] Implement ScrollView.snapToAlignments in RN Android
Reviewed By: javache
Differential Revision: D31206398
fbshipit-source-id: b6534965c476a0a4745ac98b419cbe05dc5c746e
Summary:
This diff implements the SnapToAlignment functionality in ReactScrollView for RN Android.
In order to use SnapToAlignment, the pagingEnabled prop should be set
Based on the documentation the behavior implemented in this diff is more "advanced" than the one implemendted in RNiOS, because it let you snap without specifying any interval nor offset (it calculates the intervals in real time based on the size of its content)
I still need to verify how different RNiOS and RN Android behaviors are
changelog: [Android][Added] Implement SnapToAlignment in ReactScrollView
Reviewed By: JoshuaGross
Differential Revision: D31182786
fbshipit-source-id: a9b55d9c00326ae21ca9b89575e79c60bf9edcca
Summary:
This diff adds the new snapToAlignment into ReactScrollViewManager
changelog: [Android][Added] Implement snapToAlignment into ReactScrollViewManager
Reviewed By: JoshuaGross
Differential Revision: D31182787
fbshipit-source-id: 8049ceb462461a11f184dbc1b40ca8079a3e8b60
Lulu Wu
Rubén Norte
AntoineDoubovetzky
Samuel Susla
Wes Johnson
Gijs Weterings
Xiankun Cheng
Juan Tejada
Manoj Kumar
Pieter De Baets
Brent Kelly
Luna Wei
Frieder Bluemle
Rob Hogan
Xin Chen
CodemodService FBSourceClangFormatLinterBot
Gustavo Sverzut Barbieri
Phillip Pan
Kevin Gozali
fabriziobertoglio1987
Andrei Shikov
Ramanpreet Nara
Pieter Vanderwerff
Michael Neeley
Joshua Gross
Nicola Corti
David Vacca
Tim Yung
Su Min Kim
Héctor Ramos
Moti Zilberman
Cristiano Coelho
