Summary:
When a new version of `fbjni` is released, we can simplify `getName` and `getMessage` calls on throwables.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ANDROID] [CHANGED] - Use new `getCanonicalName` and `getMessage` methods exposed by `fbjni`
Pull Request resolved: https://github.com/facebook/react-native/pull/37879
Test Plan: https://github.com/facebookincubator/fbjni/pull/78
Reviewed By: cortinico
Differential Revision: D46966561
Pulled By: javache
fbshipit-source-id: f30720a30146cf8fe5125336435a1512063c253d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38029
# Changelog:
[Internal] -
A trivial fix - I was looking into some deeper issues with `Image.prefetch`, noticed that code docs were copypasted and incorrect.
Reviewed By: cipolleschi
Differential Revision: D46959350
fbshipit-source-id: 4e4196f9399d91402d9b206c20f2bbd0d1d0eb2a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37863
This creates 2 examples for IntersectionObserver in RNTester:
* The first example is just a copy of the example provided by MDN in the documentation page for `IntersectionObserver` (https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API). This example is useful to show how React Native behaves the same way with the same code.
* The second example is a "stress test" for the API: a screen with 500 simultaneous node being observed at the same time with different observers. As we compute the intersections after scroll (after "mounting" the state update with the updated scroll position) in the main thread, this highlights a possible impact on scroll performance.
IntersectionObserver isn't yet enabled by default, so no need to add a changelog entry about this. We'll add one when the API becomes generally available.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45736845
fbshipit-source-id: 40b6bce39f90e04653504b1033a4edfaa65e93ca
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37853
This adds a basic implementation of `IntersectionObserver`. This will not be available yet and is only compatible with the new React Native architecture. This shouldn't show up in the changelog until we're ready to enable this in some form.
Changelog: [Internal]
## Context
This implements a basic version of the `IntersectionObserver` API (as defined on the Web) for React Native.
The motivation for this is supporting several use cases that are not possible in React Native at the moment, most importantly:
* Tracking paint times for elements in the screen.
* Tracking precise visibility of elements in the screen outside the context of a `VirtualizedList` (with an even better precision and control).
## Implementation details
This API is implemented as a native module that registers a mount hook in Fabric. Whenever there's a mount (an update to the UI of the host platform) we check for intersections in the shadow tree. The shadow tree contains information about the representation of the UI in a given time (including scroll position), which we use as source of truth for this in a cross-platform fashion. We rely on the fact that scroll position is updated regularly in the shadow tree to provide an up-to-date view into the UI.
**This implementation is completely cross-platform.** The only platform-specific part is the report of mounts in mount hooks from the host platform to Fabric.
This API uses a centralized entity in JS and native to handle registration of observers and dispatch of notifications. The dispatch the notifications for all observers in the same callback so we can easily change the sequencing of events easily (for example, we can change this to use microtasks when they're available in RN).
## Known limitations
* Timestamps are generally accurate for paint (as we report mounts right after they happen in the host platform), but **state updates (like scroll) are reported with a slight delay**.
* In regular rendering, we first update the shadow tree and then mount it (paint), which is generally precise. In state updates, the UI is updated first and then the shadow tree is updated. In this case, we're not correctly reporting the timestamp of the scroll event (which we should be using) but the timestamp of when the update is processed. We'll fix this in a following diff.
* The IntersectionObserver API has a concept of initial notification. This is a mechanism to report the initial state of an observed target. If we start observing a target when it's added to the tree but before it's painted, this initial notification is supposed to provide initial paint time (which is important for performance measurements). This implements some logic to handle that correctly (we check if there is a pending transaction) but it's currently unreliable:
* React Native does not currently block paint on microtasks or layout effects, so setting up an observer in these stages could have race conditions with actual mount. If mount happens before the observation is started, the initial notification doesn't report initial time but observation time. If mount happens after, the initial notification should be fine (except in some cases on Android, see the next point).
* On Android, we have a push model to send mutations to the host platform, we means we consume transactions after commit, not immediately before mount. This breaks this logic and we need to figure out a solution in a following diff.
----
Reviewed By: sammy-SC, rshest
Differential Revision: D45278720
fbshipit-source-id: de350388c6325128f1cf73328779a9d3577a258a
Summary:
Follow up to:
- https://github.com/facebook/react-native/pull/37960
## Changelog:
[INTERNAL] - Update NativeAnimatedNodeTraversalTest to be more idiomatic
Pull Request resolved: https://github.com/facebook/react-native/pull/37970
Test Plan: Will run on CI
Reviewed By: javache, cipolleschi
Differential Revision: D46853581
Pulled By: cortinico
fbshipit-source-id: 73776493163413b045482344b7b1be0635f5aa25
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:
Well, looks like we've hit a GH limit 🤣
<img width="1272" alt="Screenshot 2023-06-22 at 10 32 19" src="https://github.com/facebook/react-native/assets/16104054/d1901d7c-a06b-4dae-9ec4-1846dc458eb1">
This PR splits the changelog into (for lack of better term) decades:
* lower than 0.60 (turns out we only started having proper changelogs in the mid 0.50-ish)
* 60->69
* 70+
This also works well because anything lower than 0.70 is now in the unsupported range.
## 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
-->
[Internal] [Changed] - split the changelog into decades
Pull Request resolved: https://github.com/facebook/react-native/pull/38017
Test Plan: N/A
Reviewed By: GijsWeterings
Differential Revision: D46932308
Pulled By: cipolleschi
fbshipit-source-id: f384d24cdf73c932b0b560919ac732bd993e93da
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:
Adds changelog for new minor 0.72.0
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.72.0
Pull Request resolved: https://github.com/facebook/react-native/pull/36553
Test Plan: N/A
Reviewed By: rshest
Differential Revision: D45778748
Pulled By: cipolleschi
fbshipit-source-id: c3cca1327db0f0d3c579137f7368a2861bb72bf7
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
Kryštof Woldřich
Ruslan Shestopalyuk
Tommy Nguyen
Rubén Norte
Nicola Corti
Intl Scheduler
g4rb4g3
David Vacca
Lulu Wu
Arushi Kesarwani
Pieter De Baets
Samuel Susla
Lorenzo Sciandra
Abdennour JEBBAR
Moti Zilberman
Nick Gerleman
Hanno J. Gödecke
Ramanpreet Nara
Lorenzo Sciandra
