Summary:
I faced an issue that on Android the whole UI would freeze when using minimumFontScale. This is caused by an int cast that turns the while loop into an endless loop.
Also the docs are not correct since they say it is an iOS only prop.
https://reactnative.dev/docs/text#minimumfontscale-ios
## Changelog:
[ANDROID] [FIXED] - UI freezing when using minimumFontScale
Pull Request resolved: https://github.com/facebook/react-native/pull/38016
Test Plan:
Run this sample app with and without this fix. https://github.com/g4rb4g3/androidMinimumFontScaleBug
Without the ui will freeze when hitting the + button, with the fix a Text component will be shown and no freeze will happen. 🙂
Reviewed By: cipolleschi
Differential Revision: D46931439
Pulled By: NickGerleman
fbshipit-source-id: 6985443b3424539b40bc0081fe742ab59105a2ae
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38026
In this diff I'm moving the initialization of "rninstance" so as soon as the class is loaded
The goal is to ensure so is loaded earlier and prevent issues like T156403678
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D46945464
fbshipit-source-id: f4d68574030ca3bda5d55fe3a9c1630a4879f3ab
Summary:
This would cause an UnsupportedOperationException in java and thus result in a white screen.
The root cause is that ```mDelegate.getReactPackages()``` returns a non-resizable list so we wrap it to a resizable list in this diff.
Created from CodeHub with https://fburl.com/edit-in-codehub
Reviewed By: cortinico, adanoff
Differential Revision: D46943066
fbshipit-source-id: 27fcb78610aea0c8cb98d6ead4d0e1603a767e6e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37995
We now have native stack symbols (since D45182122) for TurboModule exceptions, so report those to ExceptionManager so they can end up in the crash reporting pipeline. It will likely not get symbolicated properly yet, but at least we'll have some metadata.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D46893131
fbshipit-source-id: 2b2713ed3af9a366cc43f8ceaef36000834310c7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37620
changelog: [internal]
To better align cocoapods structure with BUCK structure internally, we need render debug module to be a seaparate pod. This diff does that.
Reviewed By: cortinico, cipolleschi
Differential Revision: D46275529
fbshipit-source-id: d4402f264608e3297c232fcaa4fdc3df88551a65
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38005
Fixes https://github.com/facebook/react-native/issues/32093 by guarding the expensive `BABEL_CODE_FRAME_ERROR_FORMAT` regex with a cheaper initial scan. (Longer term, we should reduce our reliance on string parsing and propagate more structured errors.)
Changelog: [General][Fixed] Prevent LogBox from crashing on very long messages
Reviewed By: GijsWeterings
Differential Revision: D46892454
fbshipit-source-id: 3afadcdd75969c2589bbb06f47d1c4c1c2690abd
Summary:
As explained in this issue:
- https://github.com/facebook/react-native/issues/35350
starting from android API 33 there are severe performance issues when using `scaleY: -1` on a view, and its child view, which is what we are doing when inverting the `ScrollView` component (e.g. in `FlatList`).
This PR adds a workaround. The workaround is to also scale on the X-Axis which causes a different transform matrix to be created, that doesn't cause the ANR (see the issue for details).
However, when doing that the vertical scroll bar will be on the wrong side, thus we switch the position in the native code once we detect that the list is inverted.
The goal of this PR is that react-native users can just use `<FlatList inverted={true} />` without running into any ANRs or the need to apply manual hot fixes 😄
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID] [FIXED] - ANR when having an inverted `FlatList` on android API 33+
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [FIXED] - ANR when having an inverted `FlatList` on android API 33+
Pull Request resolved: https://github.com/facebook/react-native/pull/37913
Test Plan:
- The change is minimal, and only affects android.
- Run the RNTesterApp for android and confirm that in the flatlist example the inverted list is still working as expected.
Reviewed By: rozele
Differential Revision: D46871197
Pulled By: NickGerleman
fbshipit-source-id: 872a2ce5313f16998f0e4d2804d61e4d8dca7bfd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38010
This diff refactors the integration of ReactPackages into ReactHost and ReactHostDelegate.
As part of this diff I'm also modifying ReactHostDelegate to depend on TurboModuleManagerDelegate.Builder instead of TurboModuleManagerDelegateBuilder. This is necessary to be able to create BridgelessReactPackage inside ReactInstance
bypass-github-export-checks
changelog: [internal] internal
Reviewed By: luluwu2032
Differential Revision: D46410795
fbshipit-source-id: 221f0f5ce06b7c57410dc4d351d1a1eae29f2733
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38013
Move BridgelessReactPackage to com.facebook.react package.
This is necessary because BridgelessReactPackage is a core package that needs to be part of RN (and should not be re-defined by all apps)
I will revisit naming in a later diff
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D46918732
fbshipit-source-id: c0d0dd0147a6e160189a8cfabc713c348f2499a2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38008
Introduce a legacy module (+ example) in RNTester.
In the future, SampleLegacyModule will be used to:
- Showcase the TurboModule interop layer in RNTester, once Bridgeless mode is ready
- E2E Test the TurboModule interop layer.
The TurboModule interop layer is just an extension to the TurboModule system that allows the system to create legacy modules. Unlike regular TurboModules, these legacy modules don't need codegen for JavaScript -> native method dispatch.
Changelog: [Internal]
Reviewed By: cipolleschi
Differential Revision: D46874160
fbshipit-source-id: f9810d0bdb3bd0c0a74099fcb6f74ca547977a53
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37864
This was deprecated as part of bridgeless development, but since we now have `BridgelessReactContext`, which is also a `ReactContext`, this deprecation is no longer necessary.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D46685374
fbshipit-source-id: 4d13418419ac987261b1d10bd50aeb311caadc95
Summary:
Installing `react-native` 0.72.x causes a warning about `react-test-renderer` because `react-native/virtualized-lists` has declared a peer dependency on it. As far as I know, it is not used for anything but tests.
```
➤ YN0002: │ react-native@npm:0.72.0-rc.6 [292eb] doesn't provide react-test-renderer (p5a2fb), requested by react-native/virtualized-lists
```
Note that while many package managers default to warnings in this case, there are still a number of users out there for which this is an error.
## Changelog:
[GENERAL] [FIXED] - `react-native/virtualized-lists` does not need `react-test-renderer` at runtime
Pull Request resolved: https://github.com/facebook/react-native/pull/37955
Test Plan: n/a
Reviewed By: rshest
Differential Revision: D46871536
Pulled By: NickGerleman
fbshipit-source-id: 1e5e15608ab394bc43cd4e6ac727a74734874642
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37939
# Changelog:
[Internal] -
This addresses potential problem with inconsistent naming of direct events on Android, as we've recently found out that there are several such occasions, which can be potentially a source of errors.
Reviewed By: javache
Differential Revision: D46801798
fbshipit-source-id: 01050f53c1efa382021400e803214ae1aafff3fa
Summary:
Prior to 0.69, an RN app receiving the `UIApplicationDidReceiveMemoryWarningNotification` notification resulted in RN performing a GC on the JSC. Since 0.69 this has not worked, this PR fixes the issue.
Before 0.69 this was handled via a hardcoded memory pressure level: https://github.com/facebook/react-native/blob/c5c17985dae402725abb8a3a94ccedc515428711/React/CxxBridge/RCTCxxBridge.mm#L362
(It seems like the levels are an Android concept - see https://developer.android.com/reference/android/content/ComponentCallbacks2#constants_1)
In commit https://github.com/facebook/react-native/commit/0916df99511d6918ea905c2a9df45bccc1fd332a it was changed to run from a constant which could be reconfigured but a mistake (return type of `BOOL` rather than `int`) was resulting in the intended default memory pressure level of 15 (same as the old hardcoded value) being changed to 1 when it was passed on to `handleMemoryPressure`.
## Changelog:
[IOS] [FIXED] - UIApplicationDidReceiveMemoryWarningNotification has not been obeyed on iOS since RN 0.69
Pull Request resolved: https://github.com/facebook/react-native/pull/37973
Test Plan:
Tested manually via the Simulator using Debug -> Simulate Memory Warning and monitoring the console output of the app.
Before fix:
```
WARNING: Logging before InitGoogleLogging() is written to STDERR
W0620 11:21:42.824463 257294336 JSIExecutor.cpp:377] Memory warning (pressure level: 1) received by JS VM, unrecognized pressure level
```
With fix (and also the same output for the latest 0.68 tag in the repo):
```
WARNING: Logging before InitGoogleLogging() is written to STDERR
I0620 11:25:47.479444 79212544 JSIExecutor.cpp:370] Memory warning (pressure level: TRIM_MEMORY_RUNNING_CRITICAL) received by JS VM, running a GC
```
Reviewed By: javache
Differential Revision: D46857205
Pulled By: sammy-SC
fbshipit-source-id: 35121e6c4186fded6ef3ba728d9aafbc936627bb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37964
When a Surface is stopped, we don't immediately destroy the SurfaceMountingManager but instead just tear down its internal state. This allows for better error handling (eg did this react tag ever exist, or is this non-existing tag).
The way we construct the set of tags post-deletion is flawed though: `mTagToViewState.keySet()` does not create a new Set with all the tags used, but instead uses the underlying HashMap to iterate over the keys as needed. This effectively keeps all the Views inside that deleted surface alive.
Changelog: [Android][Fixed] Surfaces in the new architecture no longer leak views once stopped
Reviewed By: sammy-SC, rshest
Differential Revision: D46840717
fbshipit-source-id: fad145e4dd21b216d1e64f5dc79900434cff1785