Summary:
This diff refactors the class Runnable into a struct to make it work in OSS
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22963704
fbshipit-source-id: 2212c8f1e4a62b2bcad5c061709e29b247454fc1
Summary:
New mechanism to soft-crash, or crash, and collect diagnostics in the mounting layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22971260
fbshipit-source-id: 860cde3effa4a187f10f5dd1488dd41ace65e363
Summary:
Update FabricViewStateManager so that the caller can bail out of updates by returning null.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22966024
fbshipit-source-id: 31cd9ec8a9a9918fbb94844e30ed1a2fcc61997d
Summary:
Improve logging slightly.
One issue I ran into is that the "after" view hierarchy looks identical to "before" unless you schedule for the next UI tick.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22962116
fbshipit-source-id: c7a1e16e26d2aebefa3baf3acfef4e133b8fde70
Summary:
iOS will need to be implemented separately, but the shared C++ bits are in place.
Explanation: there is currently no way for the View layer to /know/ if an UpdateState call has succeeded or failed. Generally we just assume it succeeds, but if it fails we have no way of knowing or retrying.
This can cause some UI bugs. To mitigate this, I'm introducing a "failure" notification callback mechanism. The JNI bridging for this is a little complicated to avoid passing Runnable across the JNI, but it
should be much simpler on iOS.
In development this seems to make View components much more reliable.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22940187
fbshipit-source-id: 917f2932ae22d421f91fe8f4fca3f07dc089f820
Summary:
With BackgroundExecutor+State Reconciliation, it is pretty common to have races where View layer UpdateState calls are thrown away.
Theoretically this is /always/ possible since C++ doesn't retry failed UpdateStates, we just try once and then bail. This is part 1 of improving our mechanisms for ensuring that State stays up-to-date from the View layer.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22933927
fbshipit-source-id: 77b3b87402f772e3f149be0f9200e673bbed7b57
Summary:
Making error more explicit to assist in debugging.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D22929047
fbshipit-source-id: 4f26668a96868e7c5865a587142c3bcd10a26c90
Summary:
This diff creates the Android OSS build system for the module react/config
As part of this diff I also moved the module to react/config folder
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D22877264
fbshipit-source-id: 5b3c42580d2b1d73dc0abb48bcf4ff063b2f581f
Summary:
Hook up onSuccess and onFailure callbacks to LayoutAnimations.
Note that in non-Fabric RN, onSuccess is not known to work in Android. I could not find any uses of onFailure and it's not documented, so for now, it is only called if the setup of the animation fails.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22889352
fbshipit-source-id: 4306debb350388dd2b7a2cbfe295eb99723988e2
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make RM compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22875531
fbshipit-source-id: cc4cd2af875fe7eadfb3a8f4a9f16acf5fa415d8
Summary:
This diff removes the fb/xplat_init dependency from fabric onLoad class
This is necessary to make fabric compile in OSS
changelog: [Internal] Internal
Reviewed By: RSNara
Differential Revision: D22874850
fbshipit-source-id: 0c61a366e09ab072215ba2fe651f96ef4c2e455a
Summary:
EZ refactor in ReactViewBackgroundDrawable to remove an unnecessary class variable
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D22874851
fbshipit-source-id: 16808809b196cba0dab5c9972359d7786939a7ce
Summary:
If `__turboModuleProxy` is called with a second argument, we'll now forward that `jsi::Value` to TurboModuleManager on iOS and Android, so that the TurboModuleManager can eventually use this `jsi::Value` to read data required to perform method invocation on the TurboModule object.
**Note:** This diff is basically a no-op right now.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22828838
fbshipit-source-id: 19db2adcae6a58b4885fcd11bef23f9d5882bfce
Summary:
Unfortunately, the new codegen doesn't allow us to import types from other files. Therefore, I've inlined the interface specification of NativeAnimatedModule into NativeAnimatedTurboModule.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D22858790
fbshipit-source-id: 759bb960240afaba6b70c2730c3359b7e8c46c83
Summary:
This diff moves fabric C++ code from ReactCommon/fabric to ReactCommon/react/renderer
As part of this diff I also refactored components, codegen and callsites on CatalystApp, FB4A and venice
Script: P137350694
changelog: [internal] internal refactor
Reviewed By: fkgozali
Differential Revision: D22852139
fbshipit-source-id: f85310ba858b6afd81abfd9cbe6d70b28eca7415
Summary:
This instruments the following marker:
- MODULE_CREATE
**Note:** This marker isn't necessary to test the JS TurboModule codegen, since the JS codegen should only affect the C++ portion of the TurboModule infra. However, I implemented this while I was in this area of the code, for completeness.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D22679888
fbshipit-source-id: aa04822bd5a7c889813fcd13ca23c0b7a1d8444a
Summary:
In D17480605 (https://github.com/facebook/react-native/commit/689233b018bd533a7eecd38e38a7fb84b849cf88), I made all methods with void return types dispatch to the NativeModules thread. This diff makes the same change to methods with promise return types.
**Note:** The changes are disabled for now. I'll add an MC so that we can test this in production in a later diff.
Changelog:
[Android][Fixed] - Make promise NativeModule methods dispatch to NativeModules thread
Reviewed By: PeteTheHeat
Differential Revision: D22489338
fbshipit-source-id: d5b030871f9f7b3f48eb111225516521493cb05e
Summary:
Android's `VibrationModule` uses deprecated `vibrate(long milliseconds)` and `vibrate(long[] pattern, int repeat)` methods. Deprecation notes: [[1]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long)) [[2]](https://developer.android.com/reference/android/os/Vibrator#vibrate(long[],%20int)).
Changes in this pull request use recent `Vibrator` API for devices with API Level >= 26 (since mentioned methods were depreceted in API Level 26).
## 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
-->
[Android] [Internal] - Use non-deprecated `Vibrator` API in `VibrationModule`
Pull Request resolved: https://github.com/facebook/react-native/pull/29534
Test Plan: API is the same as before, but it uses recent `Vibrator` API.
Reviewed By: makovkastar
Differential Revision: D22857382
Pulled By: mdvacca
fbshipit-source-id: 6793a7d165fa73d81064865861ed55af2de83d52
Summary:
This diff cleansup unused code on AccessibilityInfoModule class
changelog: [Android][Deprecated] Remove code used by deprecated Android API levels
Reviewed By: JoshuaGross
Differential Revision: D22771912
fbshipit-source-id: f32808fa93f75c10324e8875b85fe4e541b284b8
Summary:
This diff removes code that was used to support android APIs < kitkat
changelog: [Android][Deprecated] Remove calls to Android API < Kitkat
Reviewed By: JoshuaGross
Differential Revision: D22771913
fbshipit-source-id: b9bba9e94fbc8e18889b821050dcd6eace4c202d
Summary:
After D22801173 (https://github.com/facebook/react-native/commit/9e6ba9ddb8608d4e3a4a80d0138600130b766d4c) has landed, the native mechanisms in NativeAnimated to delay queued items from immediate execution are no longer necessary.
Fabric and non-Fabric animations both look smooth after deleting this code.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22807906
fbshipit-source-id: 9241fff84376f6aa9a35049cc40dfd6561effaa1
Summary:
As a followup to D22743723 (https://github.com/facebook/react-native/commit/d53fc8a3cd44c7ec7e6eade985daf3d4feb2d736) on the iOS side, I implement a BackgroundExecutor that can be used from C++ to schedule layouts on their own thread, off the JS and UI thread.
This is a potential perf improvement that we will experiment with.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22826795
fbshipit-source-id: 899bd67fe1b86f52910951e9536b59a1414a304c
Summary:
This diff fixes the rendering of ART Shapes that uses null paths
changelog: [internal] internal fix
Reviewed By: JoshuaGross
Differential Revision: D22780163
fbshipit-source-id: 2aded726ad47fce243ec1c28fbd4c39dd71820ef
Summary:
See title. Basically during stopSurface a single BatchMountInstruction can contain both the Create and Delete MountItem for a single view, which will cause *only* the deletion to be executed.
There isn't really a way to prevent this and we're just trying to clean up as aggressively as possible, so we can safely ignore this.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22779189
fbshipit-source-id: c44fd736835b04c5de776346ec3d34afa4860199
Summary:
This exception will be more disruptive during development than necessary.
This can be upgraded again if there's a reasonable root-cause, but right now this error isn't actionable enough, is too common, and the repercussions aren't obvious.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22775734
fbshipit-source-id: 2cd9449f5b78025f7a230fbbd5f2e87bce183d04
Summary:
Enable registerSegment in Venice and verify bundle splitting works for Pokes with Venice.
Changelog: [Internal]
Reviewed By: ejanzer
Differential Revision: D22666115
fbshipit-source-id: 74ef830b802634b1019d4371873aba599438de37
Summary:
Due to subtle differences in lifecycle on the native side, as well as in JS, Fabric constructs partial graphs more frequently than non-Fabric RN did.
We still crash if we detect a cycle, which we check for more explicitly now; and we still always crash in non-Fabric. But if we detect a partial graph in Fabric,
we warn instead of crashing. We also print the state of the graph before crashing/warning, to assist in debugging in production.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D22752291
fbshipit-source-id: f452892678fbe7b5a49f93644d39d3b6ae5bda75
Summary:
Cleaning up the test for switching to the shared RuntimeExecutor, and removing the jsContext arg from Fabric's Android APIs entirely.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22026752
fbshipit-source-id: df70faa70eaa2a04717ae89e8ad3216dfd486a35
Summary:
The max heap size currently is 512 MB for OSS apps using Hermes on Android.
Some users (see https://github.com/facebook/hermes/issues/295) are experiencing
long pauses when reaching this ceiling.
Increasing this limit to 1 GB should reduce the frequency of these pauses occurring
for apps where the expected heap usage is near 512 MB.
Changelog: [Internal] Set Hermes's default max heap size to 1 GB
Reviewed By: mhorowitz
Differential Revision: D22577343
fbshipit-source-id: 2d7d688e38e95a082692dca52d010d0449a6e64b
Summary:
This could help somewhat with solving crashes in production.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D22631593
fbshipit-source-id: 2caebf1d6611d98764bccf5a6608040e5c892614
Summary:
This diff fixex a NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16.
changelog: [Android][Fixed] Fix NoSuchMethodException when calling DisplayMetricsHolder.initDisplayMetrics in Android API level <= 16
Reviewed By: fkgozali
Differential Revision: D22630603
fbshipit-source-id: d2a95445beb5745a89ee1eefdf0d24ce3e0b8893
Summary:
Changelog: [Internal] Fabric-specific internal change.
This diff introduces a new value for `YGPositionType`: `YGPositionTypeStatic`.
No part of Yoga, RN, Litho or CK uses this value yet. `relative` and `static` values behave the same way for now. We also do not change any defaults. So, it should be fine.
Reviewed By: SidharthGuglani
Differential Revision: D22386732
fbshipit-source-id: 39cd9e818458ac2a91efb175f24a74c8c303ff08
Summary:
When stopSurface is called, Fabric might be processing a commit and performing measurements even as the context is being removed from the FabricUIManager map.
Just return a 0 from `measure` if we can't get a context. This prevents crashes during teardown for measured views that will never be visible anyway.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22604716
fbshipit-source-id: 67be8d272afd35fc4c2b51b371939c5623e97f73
Summary:
This diff fixes a ConcurrentModificationException that is thrown when registering events in React Native.
This bug was introduced by D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2), before event listeners were registered in the NativeModule Thread, now they are registered in the UI Thread.
As part of this diff I change the type of mListeners variable to use CopyOnWriteArrayList instead of ArrayList because this variable is accessed from different threads. This will prevent the exception to happen, but additionally we need to verify if the change of threading made in D22483508 (https://github.com/facebook/react-native/commit/80f13412e548c8666b6ad770e6d3d5c54a717bc2) will cause any other issue (e.g. events not being delivered becuase the listeners are registered too late in the UI Thread)
changelog:[Internal]
Reviewed By: JoshuaGross
Differential Revision: D22599747
fbshipit-source-id: 5c5e46710c4a559badbd713f536e6e6e464fda23
Summary:
Apparently it's possible for `!isEmpty()` to be true and `peek` to be non-null, but for `poll()` to be false. It doesn't really make sense to me, and I don't have a repro, but that's what logs are showing.
I suspect a teardown race condition or /maybe/ a Fabric/non-Fabric handoff race condition. Neither of those make a ton of sense, though.
The mitigation is fairly straightforward: we are just much more cautious with how we treat the queue and assume everything could be null.
This impacts Fabric and non-Fabric equally.
Changelog: [Internal]
Reviewed By: motiz88
Differential Revision: D22593924
fbshipit-source-id: 7748121951a64941fa6da2bd25ebf070be6dc89c
Summary:
This diff refactors the destruction of the ReactInstanceManager when the app is experiencing low memory.
As part of this refactor, I setup an experiment to understand at what level of memory pressure is convenient to destroy the RN bridge.
The experiment is divided in six levels described in the following table:
https://pxl.cl/1dzx8https://www.internalfb.com/intern/qe2/fb4a_react_native_memory/android_fb4a_instance_unload_pressure_v2/setup
changelog: [internal] Internal
Reviewed By: JoshuaGross
Differential Revision: D22577553
fbshipit-source-id: 37f8f561099a1ba6239795f5907090ced3b5dd18
Summary:
This diff changes the InitialLifeCycleState used when initializing RN in FB4A from BEFORE_RESUME to BEFORE_CREATE.
The value of this field is used during the teardown of RN to determine if RN is actually running or not
The intention of this change is to represent the right behavior of RN during initialization, also this will allow RN to be turn down in case of memory pressure when the bridge has been initialized but before the user has navigated to a RN screen (preloading)
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D22577555
fbshipit-source-id: e54ef596cfe4429745611fe6022eb000051a93d0
Summary:
When a native module registers itself as a lifecycle event listener, ReactContext will immediately call `onHostResume` if the activity is already in a resumed state. We rely on this behavior for things like NativeAnimatedModule, which only enqueues the frame callback in onHostResume. However, ReactContext only does this if `hasActiveCatalystInstance()` returns true - which makes sense, because we don't want to notify listeners if the instance has been destroyed. But in bridgeless mode, `hasActiveCatalystInstance` returns false, and we never call `onHostResume` in this case.
This diff fixes an issue where native driver animations don't work the first time you navigate to a screen with bridgeless mode enabled.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22560314
fbshipit-source-id: 1a60cb482896308e21d6e438eb9a7314f580ad04
Summary:
There are potential race conditions in the old implementation that could result in operations being executed out-of-order when the user transitions between Fabric/non-Fabric screens.
Specifically, if the non-Fabric path queues up a batch of operations to execute on the next UI tick, it is possible that Fabric lifecycle events fire /before/ that next UI tick and synchronously execute a batch of animation operations on the UI thread, before their predecessors have executed.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D22564633
fbshipit-source-id: 91c24547d5a682e61fc0c433302667330349a5f1
David Vacca
Oleg Lokhvitsky
Joshua Gross
Ramanpreet Nara
Anton Bryukhov
Lulu Wu
Emily Janzer
Riley Dulin
Valentin Shergin