Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37039
ReactInstance is not meant to be used outside of bridgless package, this diff reduces its visibility.
changelog: [internal] internal
Reviewed By: fkgozali
Differential Revision: D45197462
fbshipit-source-id: e2fa8ed145a05882d8f5384d4e4e17a3d6d984ac
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37042
BridgelessAtomicRef is only used in com.facebook.react.bridgeless, we reduce visibility to package only
changelog: [internal] internal
Reviewed By: NickGerleman
Differential Revision: D45192193
fbshipit-source-id: 12253a2a8acd3c2edd550650f5f04a0346694b3e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37047
We're seeing scenarios where `onRequestPermissionsResult` is being invoked but the current activity does not implement `PermissionAwareActivity`. This should not crash the app.
Changelog:
[Android][Fixed] - Fix crash when Android requests permission with activity that does not implement `PermissionAwareActivity`
Reviewed By: mdvacca
Differential Revision: D45203319
fbshipit-source-id: 4a6eb67ad67ae5c731c27301967b837b1286ccbb
Summary:
In the TurboModule interop layer, several modules are appearing as null. It's unclear why. We landed a few module resolution simplification diffs, to *attempt* to mitigate the problem: D45131297. But we're not sure if those diffs will be 100% successful.
So, this diff inserts two logs into the TurboModule system, for scenarios we know could lead to TurboModules being null. The hope: this helps us understand the actual problem, in case our earlier fix attempt (i.e: D45131297) fails.
Notes:
- These logs are temporary.
- These logs will only run in the TurboModule interop's test group.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45197703
fbshipit-source-id: 4401a6111492444cc4b405c52183d02df94c3828
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37032
Before, calling into global.turboModuleProxy would kickstart the module creation algorithm, **even if the module wasn't registered.**
Now, if the module isn't registered, TurboModuleManager will just early return null.
NOTE: When an unregistered module is requested from Java via TurboModuleManager.getModule(moduleName), the module algorithm will **still** run.
This fixes a bug:
- global.**native**ModuleProxy will no longer kickstart **turbo** module creation.
- global.**turbo**ModuleProxy will no longer kickstart **legacy** module creation.
NOTE: This **might** improve fb4a performance **a bit**: The TurboModule creation algorithm is *probably* expensive to run. 44 NativeModules are loaded at startup by Fb4a; 8 of them aren't registered with the app: [pastry](https://www.internalfb.com/phabricator/paste/view/P701125588?lines=2%2C4%2C5%2C7%2C9%2C16%2C18%2C24). Those 8 NativeModule creates will now shortcircuit to null faster.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45195578
fbshipit-source-id: cb09bdc059b3651b02447b7c2e37ef3f4ca2f92b
Summary:
These getNative* TurboModuleRegistry APIs make the TurboModuleManager harder to understand. They should have never been introduced.
Let's remove them for added clarity.
Changelog: [Android][Removed] - Remove TurboModuleManager.getNativeModule,getNativeModules,hasNativeModule
Reviewed By: mdvacca
Differential Revision: D45158032
fbshipit-source-id: 6f904dfe43fe7b2c215070a19f474acceddbf2f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36991
D15296732 added a byte to each YGNode exposed via private API, to stash random junk in. At the time, not adding to node size because of how fields ended up aligning. I'm not sure if this is still the case, but this is subject to change (e.g. adding a single extra flag).
There is a per-node "context" already that can store arbitrary data, and this reserved space isn't public, so this API is already a bit suspect.
The only place it is used is in instrumentation in fbandroid, enabled only in benchmarks, to store an enum to forward to QPL for what framework it thinks created the Yoga Node.
This is already broken for React Native (worked for Paper only), and afaict isn't used anywhere. But it also has little reason to be caching more information on the node (beyond maybe saving a couple memory accesses) since it derives this information from the node config already.
This removes the field.
Changelog:
[Internal]
Reviewed By: rshest
Differential Revision: D45137133
fbshipit-source-id: 75755b21102f7928b3ad947051c35b1a6566ef40
Summary:
changelog: [internal]
`_isUserTriggeredScrolling` must be NO when user interaction stops. This was not the case when user scrolled -> lifted finger but the scroll did not decelerate into position. The case with deceleration is handled in method `scrollViewDidEndDecelerating`.
Reviewed By: javache
Differential Revision: D45147325
fbshipit-source-id: 1b55dc708c4c7d6cffa917a822eb2b569b22dbb2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37020
changelog: [internal]
if host view's position on screen changes, `RootShadowNode` has to be notified of this. Otherwise the state of UI is not correctly reflected in ShadowTree, leading to inconsistencies. For example, when trying to get views position in window, it won't be correct when hosting view isn't full screen.
Overriding `setFrame` only works for cases where it is hosting view's parent changing its position. But there are other cases where the position may change on the screen, like when hosting view's parent is moved by movable navigation bar. This does not affect frame of hosting view but it does change its position on the screen. To know about this event, we need to override `layoutSubviews`. `layoutSubviews` is called by UIKit whenever its internal flag `_needsLayout` is set to YES.
Reviewed By: javache
Differential Revision: D45122502
fbshipit-source-id: b7b1b08a8b3accffce7e3c71f7d19887caf6462f
Summary:
I'm adding a reference to our official template in the Needs: Repro label response
## Changelog:
[INTERNAL] - Update actOnLabel to include the official reproducer
Pull Request resolved: https://github.com/facebook/react-native/pull/37023
Test Plan: n/a
Reviewed By: mdvacca
Differential Revision: D45183426
Pulled By: cortinico
fbshipit-source-id: cd97981eda49ff7123f6beb05b6eb64b4899ded0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37018
Just bumping Gradle version to the latest stable.
This brings configuration caching as stable, which is quite of a big deal.
Changelog:
[Android] [Changed] - Gradle to 8.1
Reviewed By: yungsters
Differential Revision: D45177537
fbshipit-source-id: 6a47208b69d5591d299451e5a610cc3f5e9afe66
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36905
In this diff I'm deprecating EventBeatManager constructor that receives a Context as a parameter.
bypass-github-export-checks
changelog: [Android][Deprecated] deprecating EventBeatManager constructor that receives a Context as a parameter.
Reviewed By: fkgozali
Differential Revision: D44759827
fbshipit-source-id: cb117c26af0a43fe245f8778a55dfbea756b3ce6
Summary:
X-link: https://github.com/facebook/yoga/pull/1250
Pull Request resolved: https://github.com/facebook/react-native/pull/36988
BitUtils functions in Yoga are like bit fields, with more steps, and more error prone (you need to work with explicit offsets which can be tricky for anything variable length). Replace usage with a bitfield struct. Eventually I'd like to remove the BitUtils functions in general.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45133645
fbshipit-source-id: aa1430df5e2fb71ed9d2a5f5b1a35429b71c7069
Summary:
Changelog: [iOS][Breaking]
continuing getting rid of optional methods, but this does have a behavioral change. if the delegate does not provide the module instance, then we lazily create it. before we were returning nil, idk why. this will be a breaking change if you have any classes that conform to `RCTTurboModuleManagerDelegate`
#saynotoruntimechecks
Reviewed By: cipolleschi
Differential Revision: D45022139
fbshipit-source-id: 9635332caf3db7bb9306f99ee5c0d577091d38ea
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36968
Changelog: [iOS][Breaking]
we should be using `optional` never. this will be a breaking change if you have any class that conform to `RCTTurboModuleManagerDelegate`
#saynotoruntimechecks
Reviewed By: cipolleschi
Differential Revision: D45022003
fbshipit-source-id: d1b3cf72bae82070704f20de4558949189da462a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/37008
Reduce Visibility of public methods that should be private
changelog: [Internal] internal
Reviewed By: luluwu2032
Differential Revision: D45153669
fbshipit-source-id: 2177a114eaa701d79a21d8a25bd299bf681dc4b8
Summary:
X-link: https://github.com/facebook/yoga/pull/1251
Pull Request resolved: https://github.com/facebook/react-native/pull/36990
YGNode::setConfig was deprecated as part of D15416474 in an apparent goal to remove config pointers per-Node.
While I don't know the history of the motivation here, these config pointers were never removed, and we will be doubling down on per-node configs for StrictLayout, so we will want to undeprecate this.
This also exposes functions to the public C ABI, but I didn't spend the effort to create language projections for it.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D45133646
fbshipit-source-id: 2bb15c4825717793529cdad8542447d11e723e35
Summary:
Upgrades React Native to `deprecated-react-native-prop-types@4.1.0`, which includes many of the new prop types in React Native v0.72.
See: https://github.com/facebook/react-native-deprecated-modules/blob/main/deprecated-react-native-prop-types/CHANGELOG.md
Changelog:
[General][Changed] - Upgrade to deprecated-react-native-prop-types@4.1.0
Reviewed By: rickhanlonii
Differential Revision: D45155955
fbshipit-source-id: 36e715c2338b667755bd1e522b7d5a2611103779
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36980
With the TurboModule interop layer, some modules aren't being loaded at all. This logging will help us root cause the problem: is the issue with the TurboModule system, or with instantiating a particular module.
Changelog: [Internal]
Reviewed By: cortinico, mdvacca
Differential Revision: D45102812
fbshipit-source-id: 5c5f55d5857c694270a83c38b68cae0fdb2c3b50
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36986
global.nativeModuleProxy and global.__turboModuleProxy should not share the same cache.
Otherwise, global.nativeModuleProxy could return TurboModules, and global.__turboModuleProxy could return legacy native modules.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45131296
fbshipit-source-id: 472059dc95d760a5eb8fc376606b30e614ee86c5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36985
This diff simplifies TurboModuleManagerDelegate. Now, it doesn't do any filtering.
What TurboModuleManagerDelegate does:
- If the TurboModule interop layer is on, getLegacyModule(moduleName) starts returning legacy modules.
- If the TurboModule interop layer is off, getLegacyModule(moduleName) returns null.
This should help with T144183369. In that crash, some native modules are returned as null. And complicated filtering could be a contributor to that problem. So, simplifying filtering might mitigate that issue.
Even if it doesn't, this makes the TurboModuleManager easier to understand, which makes root causing/mitigating that problem easier.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D45131297
fbshipit-source-id: 9e37804e09c9f04ab0610f5b444574ae65c9d638
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36994
We already run changelog validation internally which has specific exemptions for codemods and dirsynced directories. Do not run twice, now that we need to export diffs.
An alternative solution would be to port the logic to the OSS changelog generator and stop running the internal one, but that would increase latency, and we have made fixes to the internal once as recent as two weeks ago in D44746795.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D45135111
fbshipit-source-id: e23c2613b183f75a148d1b38b31c259acc9c9fc5
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36998
For performance entries that have the same start/end time it makes more sense to report them back to `PerformanceObserver` in the same order they were logged.
This kind of determinism is arguably better both in terms of API, and from the point of view of testing.
Changelog: [Internal]
Reviewed By: javache
Differential Revision: D45142500
fbshipit-source-id: 77ff0093bead45dc2f15efc4b903dc181927565a
Summary:
<!--
Thanks for submitting a pull request!
We appreciate you spending the time to work on these changes. Please
provide enough information so that others can review your pull request.
The three fields below are mandatory.
Before submitting a pull request, please make sure the following is
done:
1. Fork [the repository](https://github.com/facebook/react) and create
your branch from `main`.
2. Run `yarn` in the repository root.
3. If you've fixed a bug or added code that should be tested, add tests!
4. Ensure the test suite passes (`yarn test`). Tip: `yarn test --watch
TestName` is helpful in development.
5. Run `yarn test --prod` to test in the production environment. It
supports the same options as `yarn test`.
6. If you need a debugger, run `yarn debug-test --watch TestName`, open
`chrome://inspect`, and press "Inspect".
7. Format your code with
[prettier](https://github.com/prettier/prettier) (`yarn prettier`).
8. Make sure your code lints (`yarn lint`). Tip: `yarn linc` to only
check changed files.
9. Run the [Flow](https://flowtype.org/) type checks (`yarn flow`).
10. If you haven't already, complete the CLA.
Learn more about contributing:
https://reactjs.org/docs/how-to-contribute.html
-->
## Summary
Browsers restore state like forms and scroll position right after the
popstate event. To make sure the page work as expected on back or
forward button, we need to flush transitions scheduled in a popstate
synchronously, and only yields if it suspends.
This PR adds a new HostConfig method to check if `window.event ===
'popstate'`, and `scheduleMicrotask` if a transition is scheduled in a
`PopStateEvent`.
## How did you test this change?
yarn test
DiffTrain build for commit https://github.com/facebook/react/commit/d121c67004a2e6b0bb5d341843663ef213f64863.
Reviewed By: kassens
Differential Revision: D45145742
Pulled By: sammy-SC
fbshipit-source-id: 196fe3539ee8588a31012d6af86a5ce0cd7fc973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36824
After this diff, RNTester Android can build successfully, and it should be safe to land this stack to move Venice Android to OSS folders
Changelog:
[Android][Changed] - Add bolts task files as internal dependency
Reviewed By: cortinico
Differential Revision: D44729814
fbshipit-source-id: 80926dc548bb269bb9c69efab4c7620a3fb9fdc2
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36961
changelog: [internal]
Initial state must reflect content offset, otherwise ShadowTree will not know about the contentOffset until user scrolls.
This was affecting both, iOS and Android.
Reviewed By: mdvacca
Differential Revision: D45087358
fbshipit-source-id: 8812c2d3fe97e017938a9a81acbb31d579a00d45
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36981
We are (following a quick internal RFC) looking to standardise the term "[in-app] [Developer|Debug] menu" to "Dev Menu" in the React Native Debugging docs (and all docs references). (Indeed, the prevalent existing use in docs was already "Developer menu".) This PR aligns naming in the `RCTDevMenu` component on iOS.
See also https://github.com/facebook/react-native-website/pull/3692.
Changelog:
[iOS][Changed] - Rename "Debug Menu" title to "Dev Menu"
Reviewed By: christophpurrer
Differential Revision: D44872456
fbshipit-source-id: c222bb2c551a4f434a1dc0efbb8d4f75c785aa11
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/36997
I've noticed that `Performance.mark`, for some reason, has been using an explicit `duration` parameter throughout, whereas it doesn't really make sense - neither from the web standard perspective, nor in general.
Changelog: [Internal]
Reviewed By: rubennorte
Differential Revision: D45141978
fbshipit-source-id: ce3d149401249882f673c4bb6727eb1560469fa3
David Vacca
Tim Yung
Ramanpreet Nara
Nick Gerleman
Samuel Susla
Nicola Corti
Ruslan Shestopalyuk
Christoph Purrer
Phillip Pan
Oleksandr Melnykov
yaqi.liu
Samuel Susla
acdlite
Lulu Wu
Facebook Community Bot
Alex Hunt