Summary:
The fix in this diff seems simple, but it took some time to understand why this change fixed the issue that views animated use native driver out from their parent's layout are not getting touch events.
We introduced `overflowInset` to RN Android a while back to give each shadow node extra information to cover all its children's layout. These values (left, top, right, bottom extensions from the view's own layout) help us improve hit-testing algorithm used in touch events. We could ignore all subtrees that the touch point not in their parent's overflowInset box.
However, this was not working for native animation. When `userNativeDriver` is on, all animation happens without Fabric knows anything about them. The overflowInset is out of date with the final animated layout, which caused the issue that we ignored the animated view as we thought it's not under the pointer.
Here is a playground demo (P476407654) for the issue:
https://pxl.cl/1XfPL
We've tried to fix this by passing the final animated values via `passthroughAnimatedPropExplicitValues` added in D32539976. This is a prop that will get merged into `style` prop for [animation component](https://fburl.com/code/jybzfgu5). The transform values were already applied when measuring layout in [Pressability](https://fburl.com/code/5mect2k3), which uses [LayoutableShadowNode](https://fburl.com/code/qh8fufrw). However, this is not the case for overflowInset calculation. Hence, the fix here is to apply the transform matrix in Yoga before calculating the overflowInset.
Changelog:
[Android][Fixed] - Fix overflowInset calculation by using transform values
Reviewed By: ShikaSD
Differential Revision: D33806030
fbshipit-source-id: e438618e3d6e5b0333cff9ff9919b841d73b2e9d
Summary:
This was a bug, we are fixing it.
Move pointerEvents from formsStacking -> formsView and we are also removing "onLayout" from formsStackingContext
changelog: [internal] internal
Reviewed By: sammy-SC
Differential Revision: D33846660
fbshipit-source-id: 6b65a9a7815972e34dafbc48b3d732d9b02d5e9f
Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
This diff prevents view flattening for views that are handling some events in the JS side
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253124
fbshipit-source-id: acda2b12287f0a9c39a810b23a101765093ba217
Summary:
This diff updates the internals of Fabric to add support for onEnter/onExit/onMove events.
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D32253128
fbshipit-source-id: 5b30e927bda0328ba1332801f66a6caba77f949b
Summary:
Nearly all of these are identical and these compiler_flags are now centralized in rn_defs.bzl. This should have NO CHANGE on build configuration, the flags have just moved for now.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D31631766
fbshipit-source-id: be40ebeb70ae52b7ded07ca08c4a29f10a0ed925
Summary:
Changelog: [Internal]
Small optimization, we can avoid evaluating some properties if `formsStackingContext` is already set, because the end-result is always true.
Reviewed By: sammy-SC
Differential Revision: D30990925
fbshipit-source-id: 08f500aa4b75446a6c644e8821f84dbfccbfebb6
Summary:
changelog: [internal]
As per title, prevent view from flattening if `accessibilityViewIsModal` is true.
Reviewed By: jimmy623
Differential Revision: D30696223
fbshipit-source-id: 0c6bfc116458d1808f152cb13ba6c941c58f052e
Summary:
changelog: [internal]
LayoutAnimations only animates changes inside View and Paragraph nodes. This diff extends it to any node that's ViewKind.
Reviewed By: JoshuaGross
Differential Revision: D30603138
fbshipit-source-id: 63ca1e5df420149c4ba66151e97fea419fdfe631
Summary:
Ship libjsi as a standalone dynamic library. This prevents problems
with exception handling caused by duplicate typeinfo across multiple
shared libs, and reduces bundle size by removing duplicate copies of
JSI.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D30599215
fbshipit-source-id: abad1398342a5328daa825f3f684e0067cad7a96
Summary:
Changelog:
Add UIAccessibilityTraitUpdatesFrequently when the AccessibilityRole is set to progressBar. This trait tells the accessibility system where content may change with every percentage point, but without annoying the user with constant announcements.
Reviewed By: ikenwoo
Differential Revision: D30510587
fbshipit-source-id: e75690a2a56ce42476dc999383cf58c0811fcbdf
Summary:
This diff is part of a bigger effort to remove the RTTI flags.
To do so we need to remove occurrences of `dynamic_cast` and other functions that rely on runtime
type informations.
Changelog:
[Internal][Changed] - Removed extra asserts relying on dynamic_cast
Reviewed By: JoshuaGross
Differential Revision: D30483554
fbshipit-source-id: 92b31281841a92c7b43e918938248431265dd654
Summary:
Changelog:
Add the capability to set tabbar accessibilityRole which maps to the iOS's UIAccessibilityTraitsTabBar
Reviewed By: yungsters
Differential Revision: D30490752
fbshipit-source-id: f7561a8932306e133d2f65a5ab40ba0be3899ec3
Summary:
Changelog: [internal]
Logger needs to be supplied to YGConfig, otherwise the app crashes when Yoga tries to log.
Reviewed By: fkgozali
Differential Revision: D30394676
fbshipit-source-id: bda464a4e43cb815c00650e1fedf43fe0a06f973
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32042
This diff moves react_native_log out of utils to make it easier/possible to import from modules.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30411247
fbshipit-source-id: 5482761b259600df051a88c6eff1834c882e7230
Summary:
In this diff:
1. Convert the ReactNativeLogger to c function for the future compatibility.
2. Bind the log function from Catalyst app
3. Update the call site
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30271863
fbshipit-source-id: 4c0ea704cf19f53468a3b72631353959ea999884
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31998
Overall Context: We want to add a way to log errors (e.g. mustfix, warn, etc on the server with stack trace) without crashing the app (e.g. react_native_assert crashes the app).
This diff: I am writing very simple logger functions which will get resolved at build time depending on the platforms/apps.
Changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D30174404
fbshipit-source-id: 2e5bc865dd8576c5a758c56e080a1e582a8c3ada
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:
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:
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:
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:
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:
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:
[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:
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] 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:
Fix warnings about implicit type truncation.
## Changelog
[Internal] [Fixed] - Fix various C++ warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/31002
Test Plan:
Almost all the changes here are simply making explicit conversions which are already occurring. With the exception of a couple of constants being changed from doubles to floats.
With these changes I am able to remove a bunch of warning suppressions in react-native-windows.
Reviewed By: shergin
Differential Revision: D26900502
Pulled By: rozele
fbshipit-source-id: d5e415282815c2212a840a863713287bbf118c10
Summary:
We want to be able to instrument touch processing delays in JS, which does not have access to systemUptime; therefore we want a UNIX timestamp, which JS has access to and can compare to the touch time.
It only matters that there is relative consistency between multiple touch events in JS, which is still the case; so this should have no impact on product code.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26705430
fbshipit-source-id: 2acd52ae5873a44edf1e0cb126a9a6c87203d8fa
Summary:
For better cross-platform consistency, migrate usages of NDEBUG to REACT_NATIVE_DEBUG. See flags.h for explanation.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D26695203
fbshipit-source-id: df09af5a62044c711368954b5e9b3a114491e2ed
Summary:
Changelog: [Internal]
Adds react_debug dependency in Android.mk where it was missing
Reviewed By: mdvacca
Differential Revision: D26617400
fbshipit-source-id: 5ac799269b106eadd881d30490ac34bd2134a9b7
Summary:
Surprisingly, it's not that trivial to pass `LayoutContrants` to `YGNodeCalculateLayout` in a way that always works. The problem is that `YGNodeCalculateLayout` does not allow expressing the constraints explicitly, so we need to pass them as `YGStyle` properties of a root node. With this approach, we unconditionally apply them as `YGStyle`s as actual values or `Undefined` value (which overrides some other values that can be previously set by calling this function or other code). We also intentionally preserve `height` and `width` values because it's a common use-case when a component explicitly specifies its size.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26583550
fbshipit-source-id: 2cd506fbdc9e6a1a8f119d09ccfd34f876a13625
Summary:
See react_native_assert.{h,cpp}. Because of the BUCK+Android issue where NDEBUG is always defined, we use react_native_assert instead of assert to enable xplat asserts in debug/dev mode.
This migrates most of the codebase, but probably not 100%. The goal is to increase assertion coverage on Android, not to get to 100% (yet).
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D26562866
fbshipit-source-id: a7bf2055b973e1d3650ed8d68a6d02d556604af9
Summary:
In D26292378 (https://github.com/facebook/react-native/commit/81147b6f793fbc00b81501393371bb332641f4c8) we changed the way the layout constraints are specified to Yoga for measuring and layout. This is a second iteration of the change that slightly more correct and fixes other problematic cases we discovered. See also the commend in the code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D26412484
fbshipit-source-id: 06011982a63cd4d3b61ae295f9aba6f8dab6ca02
Summary:
Building ReactAndroid from source on Windows has recently hit the limitation of maximum path lengths.
At build time, during the `:ReactAndroid:buildReactNdkLib` task, the linker tries to access several of the intermediate binaries located deep in the tmp folder hierarchy, eg.
```
D:\r\ReactAndroid\build\tmp\buildReactNdkLib/local/armeabi-v7a/objs/react_render_components_progressbar/D_/r/ReactAndroid/__/ReactCommon/react/renderer/components/progressbar/android/react/renderer/components/progressbar/AndroidProgressBarMeasurementsManager.o
```
**Suggested fix:** for modules such as `react_render_components_progressbar` and `react_render_components_picker`, rename them to `rrc_progressbar` etc.
**NOTE**: this assumes that the fix from https://github.com/facebook/react-native/issues/30535 is in place. This regression happened while https://github.com/facebook/react-native/issues/30535 has been pending checkin.
**Other mitigations I've tried:**
- setting [`LOCAL_SHORT_COMMANDS`](https://developer.android.com/ndk/guides/android_mk#local_short_commands) for the problematic modules or `APP_SHORT_COMMANDS` for the root project. Turns out those commands don't work on the NDK version RN requires, but even after manually applying a [patch ](https://android-review.googlesource.com/c/platform/ndk/+/1126440) to my local copy of the NDK, these flags had no effect.
- moving the repo directory higher in the file system tree, and using short directory names `D:\r\...` was not enough
- creating virtual drive letters for specific long paths with the [`sust`](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/subst#examples) command is not workable, since they depend on the source folder structure, and get partly generated by the build system, which I can't plug into
- just enabling long path support on Windows is not enough, since the compiler toolchain doesn't support them.
## 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] [Fixed] - Fix source build on Windows machines vol. 2
Pull Request resolved: https://github.com/facebook/react-native/pull/30776
Test Plan:
Run `.\gradlew installArchives`
Before:
Now:
Differential Revision: D26194286
Pulled By: mdvacca
fbshipit-source-id: 778b5a0515148e2ace19e7902f74301831ebed94
Anandraj
Xin Chen
David Vacca
Andres Suarez
Samuel Susla
Kevin Gozali
Nicola Corti
Joshua Gross
Pieter De Baets
Neil Dhar
Jimmy Zhang
Sota Ogo
CodemodService FBSourceClangFormatLinterBot
Andrew Coates
Andrei Shikov
Kacie Bawiec
Valentin Shergin
Igor Klemenski
