Summary:
This is the Android analogue to D30019833.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30029295
fbshipit-source-id: 13df0dfb915697eeedcc527dcdb6c246e89afb0c
Summary:
See previous diffs for context. This updates all of the relevant props structs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29855426
fbshipit-source-id: 30177c3380ef82ecf8f2a4321f128cfbe8a576e0
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
Currently, React Native throws an invariant violation error when a text string or number is supplied as a child. This is undesirable because core library components should be fault-tolerant and degrade gracefully (with soft errors, if relevant).
This change will work when a change in the host configs are landed (https://github.com/facebook/react/pull/21953).
Changelog: [internal]
Reviewed By: yungsters, sammy-SC
Differential Revision: D29894182
fbshipit-source-id: 827ff299991a476b57981382d196c7ee1396ec28
Summary:
Changelog: [internal]
Fabric didn't have prop [removeClippedSubviews](https://reactnative.dev/docs/view#removeclippedsubviews) implemented. This diff adds it. It is
Reviewed By: JoshuaGross
Differential Revision: D29906458
fbshipit-source-id: 5851fa41d7facea9aab73ca131b4a0d23a2411ea
Summary:
Changelog: [internal]
Original commit changeset: 390e773283a7
Original diff didn't resolve crash T82119127. Let's back this out and investigate again.
Reviewed By: mdvacca
Differential Revision: D29909878
fbshipit-source-id: 54b054f4a5c97b8f6369f8790c2cf32a56c4fbd2
Summary:
Changelog: [internal]
If task that is being executed schedules a new task with higher priority, the new task will be dropped from the queue. To fix this, we always check if the top of the queue is what was executed and only then remove it.
Example:
Let's say there is task A with priority "normal".
When we execute task A (which is not removed from the queue until later), it adds a task B with "immediate" priority.
So priority queue now has two tasks: [1: B, 2: A]
After task A finishes, inside workLoop, it will pop from top of the priority queue. But task A is no longer top of the priority queue (this is the bug) and it pops B. B is never executed and A is executed twice.
Reviewed By: ShikaSD
Differential Revision: D29841433
fbshipit-source-id: b2f1474fdfc7b3e2d42bae5b7f4ac7e6c3a37b54
Summary:
This diff exposes a new API in FabricUIManager called getInspectorDataForInstance. The goal of this method is to return React metadata for a Native view.
This data will be used from partner teams to build tools that uses React metadata in RN
Data returned from React: P429701924
changelog: [internal] internal
allow-large-files
Reviewed By: JoshuaGross
Differential Revision: D29747864
fbshipit-source-id: 8cb55573be08cb530f7e3c83eed8b4fcf43e7781
Summary:
This diff exposes a new struct InspectorData that will be used by FabricUIManager.getInspectorDataForInstance to return metadata of stacktraces.
See next diffs of the stack
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29764995
fbshipit-source-id: 6a2ab819623e379795e59002be0e4d40ac73b9a6
Summary:
Added to C++ props, but realized this is already implemented using C++ state in Android, so added to C++ state to keep this diff simpler. Keeping the C++ props change for future use.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29805267
fbshipit-source-id: c1fe2dc34af8bc69352ee48a5d60ba998194e3f7
Summary:
This diff refactors the AndroidTextInput.AndroidTextInput.color prop to use SharedColor instead of int
The purpose of this change is avoid a crash when using PlatformColor on TextInput
changelog: [intenral] internal
Reviewed By: JoshuaGross
Differential Revision: D29810595
fbshipit-source-id: 2a5a9c5ae66e8d5de8adb1c89ea62489190a91ee
Summary:
I'm hunting down the source of a perf regression on a screen and think that having these systrace sections could be handy for this and future investigations.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29802969
fbshipit-source-id: f4030261da8888ddeb32ae41b9cf2b25af6a5583
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Android react-native `TextInput` component does nothing if prop `keyboardType` is `url` value. This PR solves that problem.
## Changelog
[Android] [Added] - Add support to URI keyboard type in Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31781
Test Plan:
Before change:
{F630980679}
After Change:
{F630986399}
Reviewed By: lunaleaps
Differential Revision: D29517822
Pulled By: sshic
fbshipit-source-id: 1bda29584a3799570f34e772b5589b59ac80c524
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
#import is common in Objective C, but is a vendor-specific extension of C++, which breaks MSVC compat. Fix an #import that made its way into C++ code.
## 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] [Fixed] - Replace #import in C++ Header with #include
Pull Request resolved: https://github.com/facebook/react-native/pull/31805
Reviewed By: sammy-SC
Differential Revision: D29553429
Pulled By: javache
fbshipit-source-id: d609981f0c6a756eafb58d50e98975625d08de21
Summary:
When using lock-holder objects, it is typically required to conduct all unlocking and relocking through them. That way, the RAII lock-holder does not attempt to unlock an unlocked mutex should the code throw after unlocking but before relocking.
Changelog: [internal]
Reviewed By: sammy-SC
Differential Revision: D29238721
fbshipit-source-id: 2403ce8c9e86f96b56a35a456e017486a2854c74
Summary:
Changelog: [internal]
[This assumption](https://fburl.com/diffusion/yeqtvxru) in `~Scheduler` might not be completely correct. There can be a race between JS thread and main thread. With main thread settings animationDelegate_ to nullptr and JS thread reading the value. Even though they always happen one after the other, JS thread can have the value of animationDelegate_ in its cache line and changing it from main thread might not invalidate it right away.
Reviewed By: JoshuaGross
Differential Revision: D29237290
fbshipit-source-id: 6cb898caf7c225cf8162e7560921b563dec514b1
Summary:
Changelog: [internal]
[This assumption](https://fburl.com/diffusion/yeqtvxru) in `~Scheduler` might not be completely correct. There can be a race between JS thread and main thread. With main thread settings delegate_ to nullptr and JS thread reading the value. Even though they always happen one after the other, JS thread can have the value of delegate_ in its cache line and changing it from main thread might not invalidate it right away.
Reviewed By: mdvacca
Differential Revision: D29233092
fbshipit-source-id: 390e773283a745742d78152b9921c9ce21148a4c
Summary:
Changelog: [internal]
Remove `RuntimeScheduler` from `SchedulerToolbox` and all of its uses.
`RuntimeScheduler` needs to be allocated before `Scheduler` and therefore its presence in the toolbox is redundant.
Reviewed By: JoshuaGross
Differential Revision: D29134769
fbshipit-source-id: fa00c5dcc4b565d6941e6d742c6aefade37b31c4
Summary:
In the refactor in D28933824 (https://github.com/facebook/react-native/commit/6b601db8b83337415113a123d780fb64aa67af42), an early return was accidentally deleted. This causes incorrect measurements to be returned, which can break a few things including Text Inline Views.
Changelog: [internal]
Reviewed By: mdvacca
Differential Revision: D29122235
fbshipit-source-id: 76c8991132e22cd4e0fc1c277447c4dba751adfb
Summary:
Adding runtime type information adds greatly to the binary size, so react-native-windows builds without it. But some parts of the fabric code currently uses dynamic_cast, which means to use fabric we have to build with RTTI turned on. This PR removes the usages of dynamic_cast that are hit in release builds, which should allow react-native-windows to turn off RTTI in release builds.
Required for: https://github.com/microsoft/react-native-windows/issues/7981
One thing to note, the comment in ShadowNodeTraits indicates that core was reserving the first 16 bits. I'm adding two more. Is that ok? Should core be reserving more for future use?
## 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] [Fixed] - Remove uses of dynamic_cast in release builds
Pull Request resolved: https://github.com/facebook/react-native/pull/31694
Test Plan:
Verified that I can build react-native-windows with Fabric in release, without RTTI.
Boot / clicked around in RNW RNTester
Reviewed By: sammy-SC
Differential Revision: D29040383
Pulled By: JoshuaGross
fbshipit-source-id: e49286e59c4ba54faf0b4de5e244dfa1f7c3f193
Summary:
PreAllocation currently always happens at revision 0 (after ShadowNode creation), and all CREATE mutations are triggered for ShadowNodes at revision 1 or higher (since CREATE mutations are generated by the differ, it means that all ShadowNodes have revision 1 or higher when CompleteRoot is called). This means that between PreAllocation and CREATE, we /always/ expect at least one clone.
It is possible for a node to be "non-view-forming" at revision 0, causing view preallocation to be skipped, and "view-forming" at revision 1 (causing the CREATE mutation to be thrown away, since all CREATE mutations of revision 0 or 1 are thrown away). This causes a crash. It is extremely marginal, but there are repros in the wild.
Thus, I'm introducing one new UIManager and Scheduler delegate method that allows the mounting layer to be notified of clones. If a clone from rev 0->1 results in a node going from non-view-forming to view-forming, we can preallocate then, as well.
This resolves this crash, and allows us to keep experimenting safely with this View PreAllocation optimization. I believe all edge-cases are accounted for.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D29043426
fbshipit-source-id: dff11d3140ded1cbb02a5518a3aeb52dc812cc50
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
David Vacca
Ramanpreet Nara
jeswinsimon
Ikko Ashimine
Joshua Gross
Samuel Susla
Sota Ogo
Cody Unger
Kudo Chien
Adrián Cuesta
Luna Wei
Justin Huntington
Nick Gerleman
Yedidya Feldblum
CodemodService FBSourceClangFormatLinterBot
Andrew Coates
