Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38301
Changelog: [Internal] - Add dispatchEvent API to EventEmitter that accepts an EventPayload directly
This diff adds a deeper overload of dispatchEvent to EventEmitter which accepts a caller-provided EventPayload subclass, and modifies TouchEventEmitter's dispatchPointerEvent method to use it so that the typed PointerEvent is actually sent through the event pipeline.
Reviewed By: NickGerleman
Differential Revision: D47351851
fbshipit-source-id: a6fdabbfc9b8287c564252f5cc7296fa75044a1e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38128
changelog: [internal]
This is debug code that should not have been committed. It is harmless but still should be removed.
Reviewed By: NickGerleman
Differential Revision: D47127817
fbshipit-source-id: 6a13cbf0bf678ef5b7c5e8148e28ce78fba7d6de
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38303
X-link: https://github.com/facebook/yoga/pull/1327
This bumps Yoga to C++ 17 for a few reasons:
1. New versions of C++ may introduce behavior changes (e.g. evaluation order) and deprecations. Keeping the version closer to the version of large users helps avoid that.
2. C++ 17 unblocks some new bits I have wanted to use at times, like `std::optional`, `std::variant`, `if constexpr`, `[[nodiscard]]`.
3. There are already changes in C++ 20 that would be directly useful to Yoga, like `std::bit_cast` to avoid `memcpy` style type punning.
There has been some contention around C++ versions before, but by the time the next stable version of Yoga is out, it will have been more than 6 years (~2 C++ versions) since a stable version of Clang/LLVM with C++ 17 support. I would not like to go back further than n-2.
Changelog: [Internal]
Reviewed By: christophpurrer
Differential Revision: D47383922
fbshipit-source-id: eb95d4853f2168b68d6df5fddb797236eac55870
Summary:
Fixes https://github.com/facebook/react-native/issues/28602
When creating a `RCTFrameUpdate`, ensure it is created with the correct unix timestamp in seconds. This is needed to match the `NSTimeInterval` type defined in the header.
Previously, it was using the `CADisplayLink`'s `timestamp` property, which is not an `NSTimeInterval` but is instead a `CFTimeInterval` (note the different class prefix). This is the host time converted to seconds, which is the number of seconds since the device was turned on and therefore not a unix timestamp as expected.
This was causing issues with the `window.requestIdleCallback` timers as the timer code was expecting this `timestamp` property to be a unix timestamp in seconds which was causing the calculations to be done incorrectly and for the callbacks to never be called. The code does this calculation is here:
https://github.com/facebook/react-native/blob/4d920fe7c991eaec61d229a71df30b0f6c446d38/React/CoreModules/RCTTiming.mm#L262
As one of these is a valid unix timestamp and the other is a much smaller number (number of seconds since device turn on), the `if` statement following this calculation never passes and the callbacks are never called.
This regression seems to have been introduced with this pull request: https://github.com/facebook/react-native/pull/26114
## 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] - Fixed window.requestIdleCallback not firing on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/29895
Test Plan: I have tested this by patching my React Native code and testing that idle callbacks are correctly called. There is a reproduction case of the issue in the linked issue.
Reviewed By: NickGerleman
Differential Revision: D47381404
Pulled By: sammy-SC
fbshipit-source-id: fd166741889b0084e1def8dedf6e4018adfd570f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38279
Changelog: [Internal] - Make PointerEvent a subclass of EventPayload
This is another refactor diff in preparation of intercepting events in UIManagerBinding to accomplish the Pointer Capture APIs (and more) by making the PointerEvent struct implement EventPayload. Now that this struct will be passed to the event pipeline itself we'll be able to determine in UIManagerBinding that the event is a PointerEvent by dynamic casting and access the event's properties without converting to/from JSI values.
Reviewed By: NickGerleman, sammy-SC
Differential Revision: D47300801
fbshipit-source-id: 4d80378803af0c31dca068ef2b99e34fab426d84
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38276
Changelog: [Internal] Refactor Fabric event pipeline to accept typed event payloads
As a first step towards my project of managing the Pointer Capture API by intercepting events in UIManagerBinding I need infrastructure to be able to safely & efficently read the properties of the event payload which is what this diff lays the ground work of addressing.
Currently the events are passed from the EventEmitter all the way to UIManagerBinding with only a ValueFactory (std::function lambda) which is called to produce the jsi::Value. My diff introduces a new virtual base class, EventPayload, which provides the same functionality but in a member function, asJSIValue. To ease the transition to this new paradigm I also introduce the first concrete subclass of EventPayload: ValueFactoryEventPayload — which simply stores and calls a ValueFactory so that we can incrementally migrate to typed events (or frankly, continue to be used for events that we don't *need* to be typed, as the only real use-case in the beginning will be for Pointer Events).
This diff notably does not change any behavior and should behave the exact same way it did before — it is in later diffs where I will begin applying this to the pointer events.
Reviewed By: NickGerleman
Differential Revision: D47299631
fbshipit-source-id: d31d95a5fe09c3404800dd0da0322b198948a851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38295
Move constant to class instance so customers can use strongly typed name, feedback from D46159001
Changelog:
[Internal] [Changed] - Add module name constant to codegen'd class for downstream use
Reviewed By: christophpurrer
Differential Revision: D47095993
fbshipit-source-id: 741d0d837bf912d6b32e5f12c5df871563d46686
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38206
This test will ensure that the TurboModule interop layer works in Catalyst.
It will navigate to the sample legacy module screen, and ensure that all methods work.
Steps:
1. Open up Catalyst
2. Navigate to the Legacy Native Module example
3. Click "Run all tests"
4. Validate that all tests match expectations.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D46917689
fbshipit-source-id: 071f9324fa3719648c1a390bde4ba00a4e687e44
Summary:
Adds changelog for new patch.
## 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.2
Pull Request resolved: https://github.com/facebook/react-native/pull/38286
Test Plan: N/A
Reviewed By: cortinico, GijsWeterings
Differential Revision: D47364735
Pulled By: rshest
fbshipit-source-id: 8c884915aedb13929949a1a8bd72c389aa83d102
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38288
This wasn't compiling since we need to cast to the (unshared) base component type.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D47362923
fbshipit-source-id: 2116c16eb90ee9efbd9d0ec45655220c0f7fed9c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38287
Enable automatic (within Meta) sync checks between these duplicated definitions across the RN and Metro repositories, by using a common naming convention.
Changelog: [Internal]
Reviewed By: hoxyq
Differential Revision: D47361815
fbshipit-source-id: bb55e5a1c21bf44be9016150a56a9eaa3b33078b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38275
This bumps the version of Fresco to the latest major.
I add to add a couple of changes:
1. Some of the infra has been moved to a different package called `middleware` which I had to add
2. Flipper Fresco plugin has changed ownership, so I had to use the new coordinates.
Changelog:
[Android] [Changed] - Fresco to 3.0.0
Reviewed By: mdvacca
Differential Revision: D47337443
fbshipit-source-id: 1df78e624bcbf0200145fbee5780e2a1697fcb16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38233
When call ReactHost.destroy multiple times on same thread, the synchronization we have now can not protect us from concurrent issues such as ```ConcurrentModificationException```, to avoid this case this diff checks if ReactInstance has been reset, if so it means an early destroy has been called and we should not destroy again.
Changelog:
[Android][Changed] - Avoid duplicate destroy on same thread
Reviewed By: fkgozali
Differential Revision: D47276191
fbshipit-source-id: 2291b89cb980ca762abddb835e703abd095a93b3
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38274
Update oncall field on all of the react native android BUCK files
The goal is to prevent lint warnings
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47338271
fbshipit-source-id: 757a915458a2370dabe122fd3f4936409f8aef95
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38255
Remove package comment from JSCExecutor
This class was made public as part of D30346032, seems it's safe for it to be public
changelog: [internal] internal
Reviewed By: christophpurrer
Differential Revision: D47309285
fbshipit-source-id: 061aeb3a803ded73cad7d45909ab22fe7489c811
Summary:
*Auto-close* an issue when the version of React Native specified is **TOO OLD**.
Applies `Type: Too Old Version` label and closes such issues using `actOnLabel` workflow.
## Changelog:
[GENERAL] [ADDED] - Auto close issue if version is too old.
Pull Request resolved: https://github.com/facebook/react-native/pull/38041
Test Plan: - Should *auto-close* an issue with `Type: Too Old Version` label
Reviewed By: NickGerleman
Differential Revision: D47331471
Pulled By: cortinico
fbshipit-source-id: 516468299d6923ce72e073a3b7b8b8715d15d6e0
Summary:
### Motivation
I had a crash-causing error in our error reporting console (Bugsnag) that was extremely hard to debug due to the lack of specificity in the thrown error.
```
java.lang.NullPointerException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference
at com.facebook.react.bridge.ReadableNativeArray.getDouble(ReadableNativeArray.java:92)
at com.facebook.react.bridge.JavaMethodWrapper$4.extractArgument(JavaMethodWrapper.java:64)
at com.facebook.react.bridge.JavaMethodWrapper$4.extractArgument(JavaMethodWrapper.java:60)
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:356)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loop(Looper.java:214)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:919)
```
I noticed that `invoke` in `JavaMethodWrapper` tacks on the JS method name on other errors, so wanted to change this to handle NullPointerExceptions more gracefully too.
This helps make it easier to debug issues like https://github.com/facebook/react-native/issues/23126, https://github.com/facebook/react-native/issues/19413, https://github.com/facebook/react-native/issues/27633, https://github.com/facebook/react-native/issues/23378, https://github.com/facebook/react-native/issues/29250, https://github.com/facebook/react-native/issues/28262, https://github.com/facebook/react-native/issues/34001 and likely many more.
### After adding NullPointerException
Even after adding the NullPointerException, I got errors like this:
```
com.facebook.react.bridge.NativeArgumentsParseException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference (constructing arguments for UIManager.dispatchViewManagerCommand at argument index 0) with parameters [null, 4.0, []]
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:371)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:1012)
```
This helped, but still didn't help me easily find which library calling `dispatchViewManagerCommand` was causing this.
## Changelog:
[ANDROID] [CHANGED] - Wrap NullPointerExceptions when thrown by native code called from JS for readability
[GENERAL] [CHANGED] - Throw Error in dispatchViewManagerCommand when non-numeric tag is passed for easier debugging
Pull Request resolved: https://github.com/facebook/react-native/pull/38060
Test Plan:
Test change on our app via a beta release.
With these changes, we got better stacktraces like these:
### Java stacktrace
```
com.facebook.react.bridge.NativeArgumentsParseException: Attempt to invoke virtual method 'double java.lang.Double.doubleValue()' on a null object reference (constructing arguments for UIManager.dispatchViewManagerCommand at argument index 0) with parameters [null, 4.0, []]
at com.facebook.react.bridge.JavaMethodWrapper.invoke(JavaMethodWrapper.java:371)
at com.facebook.react.bridge.JavaModuleWrapper.invoke(JavaModuleWrapper.java:188)
at com.facebook.jni.NativeRunnable.run(NativeRunnable.java:-2)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:228)
at java.lang.Thread.run(Thread.java:1012)
```
### JS stacktrace (after dispatchViewManagerCommand change)
```
Error dispatchViewManagerCommand: found null reactTag with args []
node_modules/react-native/Libraries/ReactNative/PaperUIManager.js:120:21 dispatchViewManagerCommand
node_modules/react-native-maps/lib/MapMarker.js:68:67 _runCommand
node_modules/react-native-maps/lib/MapMarker.js:60:24 redraw
templates/Components/MapViewWithMarkers/PlaceMarker.tsx:88:32 anonymous
(native) apply
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:213:22 anonymous
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:111:14 _callTimer
node_modules/react-native/Libraries/Core/Timers/JSTimers.js:359:16 callTimers
(native) apply
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:427:31 __callFunction
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:113:25 anonymous
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:368:10 __guard
node_modules/react-native/Libraries/BatchedBridge/MessageQueue.js:112:16 callFunctionReturnFlushedQueue
```
Reviewed By: javache
Differential Revision: D47015785
Pulled By: cortinico
fbshipit-source-id: 33e0b8fbc7dc6a88d4c3383630126f99d2cf6098
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38256
Add RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support to DevSupportManagerBase for Android 14 change. See
https://developer.android.com/about/versions/14/behavior-changes-14#runtime-receivers-exported for details.
Without this fix, app crashes during launch because of :
```SecurityException: {package name here}: One of RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED should be specified when a receiver isn't being registered exclusively for system broadcasts```
Changelog:
[Targeting SDK 34] Added RECEIVER_EXPORTED/RECEIVER_NOT_EXPORTED flag support in DevSupportManagerBase
Reviewed By: javache
Differential Revision: D47313501
fbshipit-source-id: 12e8299559d08b4ff87b4bdabb0a29d27763c698
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38242
See proposal: https://github.com/react-native-community/discussions-and-proposals/discussions/681
**Removed script files**
I searched GitHub (and specifically `react-native-windows/macos`) to confirm these files are not referenced:
- `scripts/launchPackager.bat`
- `scripts/launchPackager.command`
- `scripts/.packager.env`
Interestingly, React Native CLI refers to a `.packager.env` at a different location (`node_modules/.bin/`), and includes modified copies of `launchPackager.command/bat`. This PR removes duplication with these.
Changelog: [iOS][Breaking] Metro will no longer be started when running builds via Xcode
Reviewed By: cortinico
Differential Revision: D47297469
fbshipit-source-id: 06c3602d58b21ed693c3daa763d99947a70bfc5a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38220
We ran an experiment to test different implementations of TurboModules HostObjects, as the current one has various inefficiencies, such as re-creating HostFunctions on every property access. The strategy we found to be most efficient and flexible longer-term is to represent the TurboModule with a plain JavaScript object and use a HostObject as its prototype. Whenever a property is accessed through the prototype, we cache the property value on the plain object, so it can be efficiently resolved by the VM for future accesses.
Changelog: [General] TurboModules are now exposed to JS as the prototype of a plain JS object, so methods can be cached
Reviewed By: sammy-SC
Differential Revision: D47258286
fbshipit-source-id: 4562ac5316164daaf673e713b35cb31315ff9652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38251
I'm deleting ArrayUtils from codebase, this file is not used neither internally or externally (as analyzed in github source)
I believe it's very safe to delete without following any deprecation process
changelog: [Android][Deleted] Delete ArrayUtils from codebase
Reviewed By: christophpurrer
Differential Revision: D47306287
fbshipit-source-id: 1f36ca46db107e21dc55191528cacf6f81cf63ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38249
Quick migration of ReactJsExceptionHandler to Kotlin.
It will documented in the next diffs of the stack (might rename it as well)
changelog: [internal] internal
Reviewed By: arushikesarwani94
Differential Revision: D47300786
fbshipit-source-id: ea15b4180c22f5759d327e43af1b7a5c077ea9f8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38241
In this diff I'm moving the ReactJsExceptionHandler interface into the react.interfaces package.
This bring consistence with the rest of bridgeless APIs
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D47277572
fbshipit-source-id: ad17b19de3571df4ea1545f45d5998912deac072
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38232
In this diff I'm completing the TaskInterface interface with subset methods from Task that should be exposed
changelog: [internal] internal
Reviewed By: cortinico
Differential Revision: D47267970
fbshipit-source-id: 8a51f94e3c42a1d396e002f75547665f320c3962
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38239
In D46840717 I made SurfaceMountingManager reset its context on stop as the Context may be keeping various other objects alive and was causing memory leaks.
This does cause a race condition if JS is still rendering at this time, as it needs to access to context to support things like PlatformColor.
Changelog: [Android] Fix crash on teardown in new architecture
Reviewed By: rshest
Differential Revision: D47290581
fbshipit-source-id: ef83c1d110d1156e39f2491fb62c82ec41c3b8e1
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38235
changelog: [internal]
Original commit changeset: faece0940b15
Original Phabricator Diff: D46086661
This PR broke 50 diffs. Let's back it out.
I will communicate this to the PR owner with an example of what went wrong.
This causes a slight difference in text render:
{F1043017930}
Reviewed By: javache
Differential Revision: D47284841
fbshipit-source-id: 29d28f62d3997740b2186bd60b327a0d009c4a6b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/38223
Before this change, the InteropLayer was adding the view to the registry right before invoking a command and right after the command was invoked. This model was too strict as some view commands may have async behaviors that make the lookup in the registry fail.
After this change, we are going to register the view when it's created and we are going to remove it when the view is deallocated.
## Changelog:
[iOS][Changed] - Update logic to add and remove views in the view registry for the interop layer.
Reviewed By: sammy-SC
Differential Revision: D47262664
fbshipit-source-id: 503f4e29e03bfc7ad861c1502129822b383ffcc0
Vincent Riemer
Samuel Susla
Ramanpreet Nara
Nick Gerleman
Sunbreak
Matt Oakes
Intl Scheduler
Christoph Purrer
Roy Berger
Nicola Corti
zerosrat
Lorenzo Sciandra
Pieter De Baets
Rob Hogan
Pieter De Baets
Tim Yung
Lulu Wu
David Vacca
Pranav Yadav
Harry Yu
Kun Wang
Alex Hunt
Riccardo Cipolleschi
Kudo Chien