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:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.
To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D27436402
fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
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
Summary:
pull out tag so it's easier to read
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407770
fbshipit-source-id: e7d2a3ce8e4ac55b6446cddc8c39e73a18fa7170
Summary:
One of the struggles with the LA engine is to make sure that LA doesn't break the StubViewTree. In particular, we have strict requirements that the "oldShadowView" with every mutation matches exactly what is in the shadow tree, so it appears that there is a linear progression of ShadowNodes for every mutation instruction.
This is a struggle to do with the current setup, requires some wacky code, and doesn't work properly. Instead of spreading REMOVE/DELETE (especially) or INSERT/UPDATE instructions across multiple keyframes, we now allow keyframes to have multiple "final" instructions to execute,
which makes it much easier to keep state consistent.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27407769
fbshipit-source-id: 3a709503dc30be69efc345690cb1920eb9591e9a
Summary:
Problem: In paper, there is a handy API called `[uiManager viewForReactTag:]`. Fabric does not have this mapping. The Fabric interop layer still relies on this Paper mapping.
Solution: As a workaround, re-create this mapping in the Fabric interop layer. Therefore, whenever Fabric interop layer asks a paper view manager to create a view, store a weak reference to the view in a `NSMapTable`. NSMapTable allows us to customize the strong/weak relationship. I've added a comment explaining that `RCTWeakViewHolder` only needs to be used for this special circumstance.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27438899
fbshipit-source-id: 94663ef06479a8c863ce58b0f36d42109fa1c4f3
Summary:
Problem: `RCTLegacyViewManagerInteropCoordinator.mm` handles view commands by looking up `RCTModuleData` from the bridge, and then dispatching that method. In bridgeless mode, `RCTModuleData` doesn't exist.
Solution: Instead of relying on `RCTModuleData` (which does a ton of things), manually create a `_moduleMethods` array to store the methods that view manager exposes. This manual creation code was copied from how `RCTModuleData` performs lookup.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27377257
fbshipit-source-id: c3e820808e6aca03bae6486d5510156b39462215
Summary:
Fabric/Paper interop expects bridge to be contained in `contextContainer`, and crashes if it's not there.
This diff avoids a crash, and instead fails silently. Future diffs in stack will enable `RCTComponentData` and `RCTLegacyViewManagerInteropCoordinator` to function without the bridge.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D27374809
fbshipit-source-id: 2c9e03a1eaf5bcaa57887b203221111015cf4de5
Summary:
Changelog: [internal]
Add support for a return value when calling JavaScript functions in UIManagerBinding.
Reviewed By: mdvacca
Differential Revision: D27470817
fbshipit-source-id: 38de92dd913af61d879f1cc5962d417f51da73b0
Summary:
Changelog: [internal]
These ShadowNode subclasses should not be further subclassed. compiler can produce smaller and faster code.
Reviewed By: JoshuaGross
Differential Revision: D27463255
fbshipit-source-id: cb10cc61a3d80731476ac0c51af7f9a47e3f9ab7
Summary:
Just makes it easier to log and inspect these values.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27407778
fbshipit-source-id: 68e93d100b56bc9065f0ff1370260412d729312d
Summary:
changelog: [internal]
Fabric is missing implementation of PlatformColor APIs. If it is used, it causes a crash.
Until it is implemented, let's remove abort statement and continue with transparent color.
Reviewed By: mdvacca
Differential Revision: D27395917
fbshipit-source-id: 50d541c5cacc10a7652f7f1ddc97e086a4ba8f03
Summary:
We need to do this to break a dependency cycle that would happen if we try to have `view` depend on `mounting` just to add some telemetry to `view`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26827446
fbshipit-source-id: 4c415ebf5be3a02c18c80ea8a4a77068cae0f0fe
Summary:
This diff changes the syntax of class variables in MapBufferBuilder class to make it consistent with standards
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27303495
fbshipit-source-id: b62067a07c5b2df1ae79b0134343d30ec819a55f
Summary:
This diff changes the syntax of class variables in MapBuffer class to make it consistent with standards
changelog: [internal] internal
Reviewed By: JoshuaGross, sammy-SC
Differential Revision: D27303497
fbshipit-source-id: 7581ce248559726c301ae96312fcb597a061ad5f
Summary:
This is a core part of the Timeline feature (aka Time Travel Debugger). With these new primitives, any external library can initiate "saving" all the previous interface changes (commits) and unwind to any previous one (in order to introspect and validate visual side-effects).
The next diff in the stack will implement UI for this feature integrated into Debug menu on iOS.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D25926660
fbshipit-source-id: 2e5f6892351d3053db8f64c1cf6ff445b0867ad7
Summary:
This diff contains the code from the 35 diff stack - D27210587
This diff implement and integrates Mapbuffer into Fabric text measure system
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27241836
fbshipit-source-id: f40a780df0723f27da440f709a8676cfcca63953
Summary:
In my haste to get out D27238439 (https://github.com/facebook/react-native/commit/aca0f418baf4890b8be3c1214be70819e4b88a95), parts of it are sloppy. Nothing critical and no known bugs, but we should clean up the commented code, and add back these asserts.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27266288
fbshipit-source-id: f242c26401dfc8851cb1ee0ef8911d19d9c1d9ae
Summary:
In the previous diff, we moved the destruction of a ShadowTree object from `UIManager::stopSurface` method. And the next logical step is to align `UIManager::startSurface` method with the symmetrical approach. Now `stopSurface` accepts a unique pointer to a ShadowTree and `stopSurface` returns it back to the caller; this way we can avoid returning a raw pointer from `startSurface`.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D27010533
fbshipit-source-id: b9211fb7e67763cc190d6b8c86cb866d20c6693d
Summary:
TextLayoutManager indirectly holds ShadowNodes, which could hold onto TextLayoutManager via a shared_ptr; so we probably have some reference cycles here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27238438
fbshipit-source-id: 033101fa1b20d3a3b20ec4bae63f938493ed5147
Summary:
TextLayoutManager indirectly holds ShadowNodes, which could hold onto TextLayoutManager via a shared_ptr; so we probably have some reference cycles here.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27238439
fbshipit-source-id: b0b65cc451891e75bafddb7a08aa34ddf86d6a35
Summary:
Changelog: [internal]
Introducing LeakChecker. A tool that checks if all native components have been cleaned up when surface is stopped.
**Known shortcomings**:
- LeakChecker is only enabled in debug builds and the existence of leaks is logged to console.
- For now, Leak Checker looks at N-1 screen. This is intentional as there is a known limitation of React that doesn't free up all shadow nodes when surface is stopped. Because of this, the use of LeakChecker is not intuitive and I'll work with React team to try to work around this.
- It doesn't help locating the leak, it only informs that leak is present. I'll be looking into ways to help locate the leak.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D26727461
fbshipit-source-id: 8350190b99f24642f8e15a3c2e1d79cfaa810d3d
Joshua Gross
Samuel Susla
Peter Argany
David Vacca
Valentin Shergin