Summary:
The new C++ Differ has been validated on Android and iOS. Delete the old code path.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28904330
fbshipit-source-id: 2e0d8682f6b2a79f9758ed8b7b92809060835815
Summary:
Changelog: [internal]
Add an option to make all measure calls asynchronous.
Reviewed By: JoshuaGross
Differential Revision: D28934444
fbshipit-source-id: 57a320b03add0182b4646b13ed4b692b899ddea3
Summary:
Changelog: [internal]
Move call of getRelativeLayoutMetrics to lambda.
The reason for this is so we can make all of "measure" calls asynchronous.
Reviewed By: JoshuaGross
Differential Revision: D28933824
fbshipit-source-id: f77fc1d06d5cd4706d52a02253a3e754e8e8fa44
Summary:
Root nodes doesn't have a ComponentDescriptor that can be looked up via this mechanism, and we probably shouldn't be animating Root nodes anyway (?). This is a debug-only assert but could be causing issues in production.
The fix is simple - just don't animate any changes to a root node.
Changelog: [Internal]
Reviewed By: Nick177
Differential Revision: D28856396
fbshipit-source-id: 43fa0aa723b03b031fee22e0563eb63cc86239b3
Summary:
Virtual views that are flattened and don't "FormsView" on-screen should not be preallocated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28811419
fbshipit-source-id: 949dcbf4cf3791355c58af785603b35fa50f3f02
Summary:
Changelog: [internal]
There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells.
To make sure the race doesn't happen, state must be updated before dispatching onScroll event.
Android has implemented a different mechanism to tackle this issue in D28558380 (https://github.com/facebook/react-native/commit/b161241db2ef74d2e4bff36d4972f5f0312dcc44).
Reviewed By: JoshuaGross
Differential Revision: D28642737
fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
Summary:
Changelog: [internal]
Use getter function instead of accessing ivar. This makes for clearer APIs.
React part is implemented in https://github.com/facebook/react/pull/21553
Reviewed By: JoshuaGross
Differential Revision: D28675372
fbshipit-source-id: cf99f8482067bfc0fd57d39fda9656abd665bb69
Summary:
Changelog: [internal]
Introduces synchronous access to the runtime from RuntimeScheduler.
At the moment, this is not used anywhere.
In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor.
Reviewed By: mdvacca
Differential Revision: D28024380
fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary:
Changelog: [internal]
This is a mechanism that will guess event's React priority based on other events ongoing on the platform.
If an event happens within span of ContinuousStart -> ContinuousEnd and its category is unspecified, we deduce it's React priority to be default. All other events are discrete.
Special case: `onScroll`, which is always treated as "Default".
Reviewed By: JoshuaGross
Differential Revision: D28485060
fbshipit-source-id: d2eae63dbcf03271dfed97128a1590dd165a3ce2
Summary:
Changelog: [internal]
Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes.
Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`.
Reviewed By: JoshuaGross
Differential Revision: D28572283
fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
JS side expects the property name to be "actionName", and this change updates it to that.
Changelog:
[iOS][Fixed] - Use actionName in accessibility event callback
Reviewed By: JoshuaGross
Differential Revision: D28645999
fbshipit-source-id: 0e7a6c3e6c1b6c998f4b53fd89c744c84083dfb1
Summary:
Android was using rawProps received from JS, so no updates needed.
Updated iOS callsite to use the name of the action.
Changelog:
[General][Fixed] - Parse accessibilityAction props into object instead of string
Reviewed By: mdvacca
Differential Revision: D28614407
fbshipit-source-id: 209134f8fac65ca8516039e10ea502e57d52a7a7
Summary:
`isColorMeaningful` is the only place in xplat code that currently uses `colorComponentsFromColor`, which assumes that a color is an RGBA value. When implementing `PlatformColor` for windows, where colors might be complex patterns or effects, I'd like to keep the details of `SharedColor` isolated within `SharedColor`. This change moves `isColorMeaningful` into `color.cpp`, where each platform can provide an implementation that takes into account its platform specific color capabilities.
See https://github.com/microsoft/react-native-windows/pull/7801 for an example of window's SharedColor which can be either an RGBA value, or a name of a native color/brush.
## 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
-->
[Internal] [Changed] - Move isColorMeaningful to platform specific code
Pull Request resolved: https://github.com/facebook/react-native/pull/31557
Test Plan: This shouldn't change any of the code, its just moving the existing function - normal CI/automation should be plenty of validation.
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D28557698
Pulled By: mdvacca
fbshipit-source-id: 2a94850fe9c5037598107e1307f4153cee6491fb
Summary:
Changelog: [internal]
My suggestion is to simplify event dispatching to only two options, synchronous and asynchronous.
Why?
- Fabric has only been using one queue, `AsynchronousBatched`.
- Batching happens even on `AsynchronousUnbatched`. It just batches events until JS thread starts processing them instead of waiting for the main run loop.
- It will make it easier to reason about the code in the future once we start utilising different priorities for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D28603472
fbshipit-source-id: 14e3a9c15a012c550dc16a044c31d722051a2bdc
Summary:
Changelog: [internal]
Extend LeakChecker so it is available on Android (or any other platform as it is completely in C++ now).
Reviewed By: JoshuaGross
Differential Revision: D28600243
fbshipit-source-id: c77a003e3ffc6171e61c998508c9f34f10bb65ca
Summary:
After D28435078, TurboModules can conform to the RCTInitializing protocol, and implement the `-(void)initialize` method. This diff makes the TurboModule system execute the module's initialize method after the infra is done setting it up.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28435429
fbshipit-source-id: fe945d616b97ed89f48b914b064e518b122a7b7b
Summary:
While we are still waiting for Android results, we can safely ship this on iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28542478
fbshipit-source-id: 2673cc4bea0edbc7e4211be7bfec9779205d721b
Summary:
This diff has the bridge attach RCTCallableJSModules to our NativeModules.
Changelog: [Internal]
Differential Revision: D28395447
fbshipit-source-id: 01ca62442013826d28ba0f710e28a5963f5efb65
Summary:
Changelog: [internal]
Only moves methods around so public and private methods are grouped together.
Reviewed By: JoshuaGross
Differential Revision: D28381588
fbshipit-source-id: dae7f493b99845f66070689270bc7aef958fbecd
Summary:
Changelog: [internal]
This diff moves all calls to RuntimeExecutor to RuntimeScheduler. The calls are still immediately dispatched. Timing of events will not change.
The goal of this diff is to prepare infrastructure for Concurrent Mode.
Reviewed By: JoshuaGross
Differential Revision: D27937665
fbshipit-source-id: 434d78c95ccf23d8da41186d0dae91bff4eda384
Summary:
react-native-windows runs with a more strict set of warnings as errors. This fixes a bunch of warnings being hit while compiling core react-native code as part of react-native-windows. In particular warnings about mismatched signed/unsigned comparisons, lossy conversions, and variable names that conflict with names in outer scopes (yoga has a global for `leading` and `trailing` that conflicts with some local variable names)
## Changelog
[Internal] [Fixed] - Fix various C++ warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/31399
Test Plan: I've run these changes in react-native-windows. -- Shouldn't have any functionality difference.
Reviewed By: sammy-SC
Differential Revision: D28290188
Pulled By: rozele
fbshipit-source-id: 2f7cf87f58d73a3f43510ac888dbcb9ab177d134
Summary:
Changelog: [internal]
Cloning root shadow node didn't always trigger a layout because node was not dirtied. Checking if layoutConstraints are changed when cloning RootShadowNode
Reviewed By: JoshuaGross
Differential Revision: D28352238
fbshipit-source-id: 536afdeddf5d2019950ceb6664c10ee593ab5f02
Summary:
Builds on previous diff. Instead of running a single animation to completion, queues up an animation and then spams mutations that could conflict with the animation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28357892
fbshipit-source-id: 6ca83a56dded629d8a1444360f1d02037661a5ef
Summary:
Add unit tests for Layout Animations.
This first batch generates a random mutation, then animates it to completion.
I found one issue with UPDATE+REMOVE+INSERT animation consistency. That shouldn't cause any crashes in production, but is a chance to improve consistency of mutations overall - and could in theory point to memory corruption, though it's somewhat unlikely.
I ran with randomized seeds, found issues, fixed them, re-ran to ensure issues were fixed, rinsed and repeated. At the end I was able to run dozens of times (with random seeds) and found nothing.
The next step is to repeatedly generate mutations that conflict with ongoing animations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28343750
fbshipit-source-id: c1c60d89a31be3ac05d57482f0af3c482b866abe
Summary:
Changelog: [internal]
Prevent unnecessary copy of `RawEvent::eventTarget` which is `shared_ptr` inside `EventQueue::enqueueEvent` by passing in rvalue.
Reviewed By: JoshuaGross
Differential Revision: D28323219
fbshipit-source-id: 7f62e17df5c4264a15adf58f6142155a76de7aae
Summary:
Support ScrollAway in ReactScrollView for Fabric/non-Fabric.
Changelog: [Android][Added] Support for ScrollAway native nav bars added to ReactScrollView
Reviewed By: mdvacca
Differential Revision: D28308855
fbshipit-source-id: 9a922159ef50fb7c8e9c484a4b97ca57ab248496
Summary:
After this diff, every NativeModule that has `synthesize bundleManager = _bundleManager`, will get access to an RCTBundleManager, that it can use to read from/write to the bridge's bundle URL.
Changelog: [iOS][Added] - Attach RCTBundleManager to NativeModules
Reviewed By: PeteTheHeat
Differential Revision: D28086319
fbshipit-source-id: 6e4cd815d300e9036957ec8c743e947d2cb3f365
Summary:
Changelog:
[General][Added] Add support for "togglebutton" accessibilityRole
# Context
The role for ToggleButton, which is needed on Android to implement toggle buttons correctly, is not currently supported.
# What does this diff do?
Adds support for accessibilityRole `"togglebutton"`.
On Android, this maps to class `"Android.widget.ToggleButton"`.
iOS does not have an equivalent trait for togglebutton, so I set it to be the same as setting `accessibilityRole="button"` for iOS.
# Caveats - checked vs selected
It seems to me like this role currently requires that you set `accessibilityState={{checked: true/false}}`. The behavior is strange when setting `selected` state, I think because on Android ToggleButtons are meant to use `checked` to indicate toggled on/off.
This is tricky because typically on iOS if you have a toggle button, you would use `selected` instead of `checked`, so RN users are likely to mess this up.
Possible solutions:
1. document that you should use `checked` state on Android for toggle buttons (and maybe throw a warning if someone passes in `selected`).
2. have RN ignore it if someone passes in accessibilityState `selected`, if this role is used.
3. Have RN convert passed in `selected` state to `checked` on the Android side.
Reviewed By: nadiia
Differential Revision: D27976046
fbshipit-source-id: 4ce202449cf2371f4bf83c4db2d53120369ee7b0
Summary:
Recent changes to `MapBuffer` have broken the compilation on Windows.
This fix is similar to this recently-merged change: https://github.com/facebook/react-native/pull/31106
Side note - this PR only addresses a build break, but doesn't address the unsafe casting semantics in `MapBuffer`, which can still cause overflows.
## 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
-->
[General] [Fixed] - Fix compilation errors on Windows.
Pull Request resolved: https://github.com/facebook/react-native/pull/31363
Test Plan: RN now builds in Visual Studio on Windows.
Reviewed By: mdvacca
Differential Revision: D28028342
Pulled By: rozele
fbshipit-source-id: 77d8d4870c59b77acfc0ab2f4c3b7df40b59851d
Summary:
## Rationale
The TurboModuleManager should only be concerned with modules. The bridge and RCTInstance integrate the TurboModuleManager with the rest of React Native. Therefore, abstractions used by TurboModules that reach into the rest of React Native should be attached by the bridge or by RCTInstance.
## Changes
In this diff, we pull RCTViewRegistry attachment out of the TurboModuleManager. In bridge mode, it'll be attached to TurboModule by the bridge. In bridgeless mode, it'll be attached to TurboModules by the RCTInstance.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D28086320
fbshipit-source-id: 9d99835bdbb66bb6a41fbd0d8a3970cefae16b81
Summary:
When REMOVE animations finish, they are hitting asserts in StubViewTree because of UPDATEs and REMOVEs being out-of-order. By simply not forcing REMOVEs to happen before UPDATEs, this problem seems to go away.
Long-term (in a couple weeks, likely) I want to add unit tests to catch all cases like this, but I'm comfortable with this change since it does fix a known assert failure.
Changelog: [Internal]
Differential Revision: D28086223
fbshipit-source-id: eb77ea94d76e996d7b2cb37038ce6f2a9799f8b4
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
Changelog: [internal]
state infra uses rvalue references until this point. I assume the original author intended to rvalue reference even here.
This way, we avoid unnecessary copy.
Reviewed By: JoshuaGross
Differential Revision: D28057570
fbshipit-source-id: 19af480234d44acffcdbb22606607279e25c8aed
Summary:
Refactor a code block that is duplicated 2x. Logic stays the same besides renaming, and a ternary operator to decide between getting the children from "old" or "new" tree.
Tests can help us refactor knowing that the logic is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018994
fbshipit-source-id: d34a033444e67091e44ff6a747fd39846c165238
Summary:
There's a case here where we do a loop, with a map loopup, and nested map lookup inside of that. It's not particularly efficient and was done because we have multiple distinct pointers to distinct ShadowViews that are backed by the same ShadowNode. Now due to previous, recent refactoring, we can simplify this case a lot.
The code WAS correct before, just confusing and not particularly efficient. Tests can prove that this is still correct.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018996
fbshipit-source-id: a7c8148802650c88888960c9c099954e0f8bc357
Summary:
This is no longer true because of the "scope" mechanism.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28018995
fbshipit-source-id: 91470234bb15f7feeb92b41613b0bbdbe42ccb27
Summary:
I am deduping a duplicated block, and adding comments to explain when we create INSERT/REMOVE mutations immediately and when we defer creation.
Theoretically the ordering of mutations will be more consistent now, which ~shouldn't matter, but is probably a decent property to have. In particular, before, in some cases
both of these orderings were possible in various scenarios:
```
INSERT X -> Y
INSERT Y -> Z
```
and
```
INSERT Y -> Z
INSERT X -> Y
```
Both of those are fine/correct/won't cause issues on any known platforms. But now, at least for the two cases touched here, only this ordering will be produced:
```
INSERT Y -> Z
INSERT X -> Y
```
meaning we build the tree from the bottom-up (the "bottom" being the root) and do out-of-order inserts less frequently.
Again, the biggest part of this diff should be readability/refactoring/de-duplicating logic, but more consistent orderings is a nice-to-have.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28017926
fbshipit-source-id: 5941588d0c8bba8b0df7d0084d5d198f4b7c2427
Summary:
Unit test case seed 1167342011 encodes a case where the differ produces a DELETE and CREATE of the same node in the same frame, which we consider an error.
It turns out this was caused by nested "unflatten" operations and this bit of deleted code specifically. We were deleting an unmatched node from a parent call's dictionary of nodes,
which prevented it from being matched in the "old" tree later on.
This is only possible now that we attach pointers to the "other" ViewNodePair when they're matched, so we can check existence of that pointer instead of inclusion in dictionaries to decide if we need to DELETE/CREATE a node and its subtree.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D28003330
fbshipit-source-id: 305440ef20b921883c1d6e38a4a4072e5a7f95ac
Samuel Susla
Joshua Gross
Andrei Shikov
CodemodService FBSourceClangFormatLinterBot
Andrew Coates
Andres Suarez
Ramanpreet Nara
Kacie Bawiec
Igor Klemenski
Peter Argany