Summary:
Changelog: [internal]
Implement RuntimeScheduler::getShouldYield and expose it through JSI.
For now we are only returning `false`. The value is backed by atomic_bool and in the future we will be able to indicate that React should yield to native.
JavaScript implementation:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L439-L441
Reviewed By: JoshuaGross
Differential Revision: D27648579
fbshipit-source-id: b9313e2efbd9daae8975357df9de803f24a35e89
Summary:
Changelog: [internal]
unstable_scheduleCallback needs to return reference to the created task so it can be cancelled later.
Reviewed By: mdvacca
Differential Revision: D27622779
fbshipit-source-id: 54160015c7f98e123d08c2e13efac4f498d3ba5e
Summary:
Changelog: [internal]
Add minimal implementation of schedule task. More features and proper scheduling will be added later.
Reviewed By: mdvacca
Differential Revision: D27622138
fbshipit-source-id: b2e4623d38e7217290a6a3c59ccc10a1c13e3a4f
Summary:
Changelog: [Internal]
Calls to `surfaceHandler.start()` and `setDisplayMode(DisplayMode::Visible)` in quick succession on different threads can cause a race condition between mount and commit operations.
The mountingCoordinator will try to mount an empty revision without any commits causing it to fail with:
```
TransactionTelemetry.cpp:108: function getCommitStartTime: assertion failed (commitStartTime_ != kTelemetryUndefinedTimePoint)
```
which is called from [Binding.cpp](https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp?lines=791-791&blame=1).
This change avoids this initial commit by verifying we had at least 1 revision commited before mounting it.
Reviewed By: sammy-SC
Differential Revision: D27430174
fbshipit-source-id: d208d55f02cd218a316d6fea62d0106c2bcb4be8
Summary:
This diff adds a new variable called "DisplayMode" into SurfaceHandler.cpp and FacebookAppRouteHandler.js. The purpose of DisplayMode is for the native pre-render system to notify React that the a surface is either being "pre-rendered" or "rendered"
When the surface is being "pre-rendered" (displayMode == "SUSPENDED"), react will create and commit React Trees, but it will not execute use-effect callbacks
When the surface is being "rendered" (displayMode == "VISIBLE"), react will create and commit React Trees and it will not execute all use-effect callbacks that weren't executed during "pre-rendering"
By default surfaces are going to be rendered with displayMode == "VISIBLE".
This diff should not create any change of behavior for now, this is the infra required to integrate the new offScreen API the react team is working on for pre-rendering system
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D27614664
fbshipit-source-id: f1f42fdf174c2ffa74174feb1873f1d5d46e7a95
Summary:
This diff extends startSurface and setSurfaceProps methods with the new parameter called displayMode
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D27669847
fbshipit-source-id: c2ddb690ca897e46e00f07b491b91bb2bc8e847d
Summary:
This diff moves DisplayMode out of SurfaceHandler, this is necessary in order to use it from react/uimanager package
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27669846
fbshipit-source-id: 274869d8f2907b1b159f51240440acece09a746f
Summary:
This diff updates initial props when DisplayMode changes in Fabric. This method will be called during pre-rendering.
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27607586
fbshipit-source-id: 7625943d57a786d6dfe30dd893e27704f51826d2
Summary:
This diff introduces a new fabric API called setSurfaceProps that will be used to call the new JS api "setSurfaceProps"
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D27607588
fbshipit-source-id: 36a19f728af244d7e72687d9305b1c568e2b8ec6
Summary:
Introduce a new debugging mechanism for the debugger. Outside of debug mode (you must defined `DEBUG_LOGS_BREADCRUMBS` manually to enable this feature) it will have no cost or binary size.
When the debug mode is enabled, it allows you to trace the call stack to trace what the differ is doing, making logs more useful.
Motivation: tracking down a tricky bug caught by D27585136 which originates in the differ.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27667885
fbshipit-source-id: ef75a9a1c8890f9bbe3e5b2e8a8ffcde92fb22c2
Summary:
Changelog: [internal]
Add config flags for RuntimeScheduler. Even with the flags, React will not be using it. Further changes on React side will be required.
Reviewed By: mdvacca
Differential Revision: D27616916
fbshipit-source-id: 296a040c2b6dd936dd9582e937e6db75e28f31a4
Summary:
Make these logs more readable/useful and add debug print of ShadowView hashes in one place.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27585135
fbshipit-source-id: 5f526856d893c32015d8b480522580732fda0cc6
Summary:
Turns out that ShadowViews that have different LayoutMetrics will have the same hash. Fix that.
This helps for debugging LayoutAnimations.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27585133
fbshipit-source-id: f0ac50619115150339089276e34fee5ddd0270bc
Summary:
Change the `TransactionTelemetryTest` to use a mock clock or change the tests to only test if at least x amount of time has passed.
Using a mock clock is the only way to make the test deterministic and be able to assert on the sub-results of the captured phases.
Changelog: [Internal] Change to the `TelemetryTest`. Neither changes the runtime behavior nor the API.
Reviewed By: sammy-SC
Differential Revision: D27618448
fbshipit-source-id: 0cbf51b050aabb75341112ea4a43bea0115082f9
Summary:
The `TransactionalTelemetryTest`s are flaky because they use a real clock and assert on how much time has passed (with a threshold, but that's no good either).
Using the real clock in the test is the cause for the test to be flaky because it depends on the assumption that it's the sole process running, never risking to be put in the process-queue of the OS. However, that's not the case and is why the test sporadically fails if the OS decided to schedule other threads/process in the middle of the test.
This diff allows parametrising the `TransactionTelemetry` class with the clock implementation so that tests can use a Mock Clock if desired (separate diff).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D27618516
fbshipit-source-id: 5a08e115b388398ca2b05b9d5ae0fd281dfe3b04
Summary:
Changelog: [internal[
Introducing RuntimeScheduler. A coordinator of work between native and React.
Reviewed By: mdvacca
Differential Revision: D27616818
fbshipit-source-id: e90d3d9ca8907be99e61f69e62e83cece8155050
Summary:
~Scheduler and ~SurfaceHandler both contain react_native_asserts that trip whenever we reload React Native with Fabric enabled. These asserts trip because of a memory leak in Fabric. These asserts do not run in production. We should fix the memory leak before re-enabling these assertions.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27481220
fbshipit-source-id: 15c3d46f7efab9ed67a70714efe44b74b0acd385
Summary:
The current test failures don't include the values passed to `EXPECT` which makes it difficult to understand if the test ended earlier or later then expected.
```
Failure: Value of: (commitDuration >= 1000 - threshold) && (commitDuration <= 1000 + threshold)
Actual: false
Expected: true
```
This diff uses the gtest `EXPECT_NEAR` to get exception messages including the delta:
```
Failure: The difference between telemetryDurationToMilliseconds(telemetry.getTextMeasureTime()) and 600 is 153, which exceeds threshold, where
telemetryDurationToMilliseconds(telemetry.getTextMeasureTime()) evaluates to 753,
600 evaluates to 600, and
threshold evaluates to 70.
```
This doesn't change the test's flakiness because of how sleep is implemented.
Changelog: [Internal] Test only change
Reviewed By: sammy-SC
Differential Revision: D27595206
fbshipit-source-id: f31bdd92ecc7271c9491dda18639ea08820f5730
Summary:
Changing back the values of DisplayMode, visible is the default value, it should be 0
changelog: [internal] internal
Reviewed By: ShikaSD
Differential Revision: D27596595
fbshipit-source-id: e5a17e22dc04d380f584bbb816106ab7d3388875
Summary:
Changelog: [internal]
`ShadowNode::Unshared` is preferred over `UnsharedShadowNode`. This diff removes last uses of the alias.
Differential Revision: D27407197
fbshipit-source-id: aa1440f80dcab523d61c186f2d3ce052f314e52c
Summary:
Goals are:
1. Catch errors in parsing during dev-mode in a way that is disruptive/grabs attention, but has enough information.
2. Use react_native_assert for hitting breakpoints (less useful for Android, more for iOS), and add LOGs for when this code is used in Android (more useful for Android, less useful for iOS).
3. Return sane defaults so that prod cases don't crash, and don't return totally garbage data.
I also found a couple cases where parsing was incorrect before; see WritingDirection and TextAlignment. This could impact some layouts and RTL/LTR potentially.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D27540903
fbshipit-source-id: 99e6949d97e8ef5520d008c1df3cbe408b5a43a4
Summary:
Changelog: [internal]
Default value for `snapToEnd` and `snapToStart` was incorrect in Fabric. This makes no practical difference as default value is never used (JavaScript always sets true or false).
Default value of `snapToEnd` is true.
https://reactnative.dev/docs/scrollview#snaptoend
Default value of `snapToStart` is true.
https://reactnative.dev/docs/scrollview#snaptostart
Reviewed By: PeteTheHeat
Differential Revision: D27505377
fbshipit-source-id: 73e88aa6ad13a851b8c401e9716fc9a650ec0098
Summary:
Changelog: [internal]
Add support for copying text. The implementation is copied over from old React Native renderer.
Reviewed By: JoshuaGross
Differential Revision: D27502474
fbshipit-source-id: 0d0df583f1adc584ca47e987f06bf78c32386fcc
Summary:
Temporarily disable due to build failures.
This is debug-only and I've never hit these asserts, so this should be safe; though it should be reenabled during active development of LA.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27505224
fbshipit-source-id: b3d6d2184d8f226d6f82d3fe0ae6303813c8356a
Summary:
Changelog: [internal]
This method is not designed to be subclassed. Let's make it non-virtual.
Reviewed By: JoshuaGross
Differential Revision: D27464824
fbshipit-source-id: b3186d1c4cf03226005f9a3caa9c002011798faa
Summary:
Changelog: [Internal] enable support for C++ 17.
C++ 17 in React Native targets.
Short and comprehensive list of C++ features:
https://github.com/AnthonyCalandra/modern-cpp-features#c17-language-features
Reviewed By: JoshuaGross
Differential Revision: D27431145
fbshipit-source-id: e8da6fe9d70e9b7343a8caec21cdbeb043478575
Summary:
To ensure that we're eventually deleting all ShadowViews from the StubViewTree and from the mounting layer, make sure that we always queue conflicts if they're DELETE instructions, including for virtual nodes.
I was able to hit this by running some extremely complex animations. It is extremely unlikely that even a single user is hitting this in prod. Therefore, while this is the right change to make, I don't expect (for example) OOMs to go down at all.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492935
fbshipit-source-id: bce332feb15229af271cc6e14b8367ebcb36536b
Summary:
This is more insurance against future changes than fixing any existing bugs. In a very small number of cases it looks like this sorting isn't working, for reasons that are not easily reproducible (way less than 1 in 10000 times for me, if that) and not obvious, since we're sorting vectors in a canonical and straightforward way.
Again, this insures that logic won't change in the future.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492936
fbshipit-source-id: 7f47e44ac1101915e1a0433c8f0a50a3c6a0c7b3
Summary:
When displaying instructions in debug logs, also print ShadowView hash to make it easier to reconstruct a series of events.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492938
fbshipit-source-id: 276a080a4afcfb4aa0aafc215e2ccd56ef849fcf
Summary:
Currently we compare StubViewTrees only in contexts where equality is expected. With additional debug flags turned on, we print a verbose summary of differences between trees.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27492937
fbshipit-source-id: 6851c2a4056cdbc9ae790070a3d86bb3f2b462fe
Summary:
Improve debuggability of ShadowViewTree failures by logging ShadowView hashes. This allows us to track down exactly where a change to the tree was introduced.
If necessary, if specific repros are found, logging can also be added to LayoutAnimations or other places to find out where a specific ShadowView version (identified by hash) was introduced.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27488766
fbshipit-source-id: f4866f771fc6494435fb46f09953ea69fb280a5b
Summary:
We have no evidence of this happening, but it matches other bail-out cases that already exist in this function. If we
fail something that would have been an assert in debug mode, bail out so we don't return garbage values in production.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27449775
fbshipit-source-id: 5b85016c9611484b615debec514d12a984e6b1ff
Summary:
This chunk of code is repeated 3x in the codebase with minor variations. Consolidate as `queueFinalMutationsForCompletedKeyFrame`.
Should be no changes in behavior.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407766
fbshipit-source-id: 196f0d4c7868007f0d103b024feb4450640a3f62
Summary:
This probably won't compile outside of debug mode, because variables are unused outside of asserts. Don't do any of this outside of debug mode.
This path is also a pessimisation, we shouldn't need to run it unless we're running in ultra-conservative debug mode.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407767
fbshipit-source-id: 71a8d025463c85d65cd2bc193a19953b97669d84
Summary:
Log final when synthetic final mutations are generated at the end of an animation.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407768
fbshipit-source-id: 0e9aface54bcca73dfa5ea263a8474db7c47c078
Summary:
Call getAndEraseConflictingAnimations recursively, to clean up any conflicting animations.
With a specific sequence of mutation instructions, it is possible that an animation on a tree is set up, and the entire tree needs to be cleaned up if a parent is deleted, say.
This can happen especially if rapidly mutating trees in such a way that invokes view flattening and unflattening (which is not recommended, but is certainly possible).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407776
fbshipit-source-id: 5125250f051c58870692f8fdc43ed23da5058a7f
Summary:
When playing around with issues in debug mode but without having a debugger attached, these logs are helpful.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407772
fbshipit-source-id: 2083901094d3bd2b0b6c6799baffcf5a60cf57ae
Summary:
When reconstructing a second animation based on a conflict with a first, we want to ensure we set 'viewPrev' of the second animation properly.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407777
fbshipit-source-id: 8fcc72c4c5fadaab4287824a944ad21230f2f97d
Summary:
In general, when an animation is interrupted or completed, we want to forcibly "flush" an update that will make the StubViewTree/mounting layer consistent with the ShadowTree.
However, in cases where a conflict creates a second animation and stops the first, we simply updated the "viewPrev" of the second animation and smoothly transition to it.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407774
fbshipit-source-id: 928363867d8994c9d69c53154a07bda94f954afa
Summary:
Detect conflicts not just when a node is updated, but when its parent is DELETEd or CREATEd.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407781
fbshipit-source-id: 719d9a8822bf691d9059073a30d8b5ccb50eece1
Summary:
This impacts Android only. It's not high-impact to check the consistency of these views and they can become "inconsistent" easily in a way that is not interesting or useful to us,
since we handle "virtual" views differently on the platform.
The need for these hacks should go away in the future if/when we account for virtual views in the differ, and stop sending redundant instructions entirely.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407779
fbshipit-source-id: 01a7ea5106ed5d94b908de03a6a710cc6275018d
Samuel Susla
David Vacca
Andrei Shikov
Joshua Gross
Micha Reiser
Ramanpreet Nara