Summary:
This diff removes the feature flag ReactFeatureFlags.enableSpannableCache and it's already disabled MC
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449840
fbshipit-source-id: 69a514b611c1179f2160a1bfd4c4199538738448
Summary:
Remove feature flag: ReactFeatureFlags.enableScrollEventThrottle
This feature has been disabled for a while
changelog: [internal] internal
Reviewed By: javache
Differential Revision: D39449184
fbshipit-source-id: c5ad0d43462422d284e14302fb9d7b39aa37da70
Summary:
Changelog: [Internal] - Make sure `onChildEndedNativeGesture` is called for view managers that call `onChildStartedNativeGesture`
This affects `JSTouchDispatcher`, `JSPointerDispatcher` as they track what view is reporting native gesturing handling.
This is a bug that view managers never shared the fact that they've stopped managing a native gesture. Both `JSTouchDispatcher`, `JSPointerDispatcher` get around this by manually resetting their internal flag on ACTION_DOWN event (we will get rid of this in a later diff)
Reviewed By: javache
Differential Revision: D38850609
fbshipit-source-id: ef4afb591249bb621f42667608dc1ef20424b65c
Summary:
When a view is rendered with a combination of `overflow: hidden` and `borderRadius: >0`, the `ReactViewGroup` would apply the border radius using Canvas `clipPath`. In Android graphics, clipPath is not an anti-aliased operation and caused aliasing artifacts.
Changing the method to a bitmask using the `PorterDuff` method results in the same functionality, but with hardware accelerated antialiasing.
https://github.com/facebook/react-native/issues/24486
Changelog:
[Android][Change] - Views with overflow: hidden and borderRadius: >0 now render anti-aliased borders.
Reviewed By: javache
Differential Revision: D38914878
fbshipit-source-id: 45ac7e4aece7a76c4216412175e49d3d73b6f391
Summary:
This is an attempt to fix the broken `test_buck` as the `/textinput` target now needs to access the Kotlin stdlib dependencies
## Changelog
[Internal] - Fix test_buck by providing exported deps for textinput target
Pull Request resolved: https://github.com/facebook/react-native/pull/34436
Test Plan: Will wait for a CircleCI result
Reviewed By: cipolleschi
Differential Revision: D38782473
Pulled By: cortinico
fbshipit-source-id: 72265c34092372189d75df732b64a1e370453472
Summary:
Some custom logic is applied to workaround a platform bug where velocity may be incorrect on Android P. [The bug in question](https://issuetracker.google.com/issues/112385925) appears to have been fixed before Android `Q` was released, so we shouldn't *need* to apply the workaround on other versions.
As described in https://github.com/facebook/react-native/issues/34226 the workaround can adversely affect certain scroll behaviors, which can easily be reproduced when you briefly scroll one direction then quickly fling the opposite direction (see the video in the linked ticket).
This PR changes the workaround to *only* be applied on Android P, in order to avoid causing weird scroll behavior on versions that are not actually affected by the bug the workaround is working around.
## Changelog
```
[Android] [Fixed] - Fix occasionally incorrect ScrollView fling behavior
```
Pull Request resolved: https://github.com/facebook/react-native/pull/34233
Test Plan:
- Repro the strange fling behavior in the current version (See video attached in https://github.com/facebook/react-native/issues/34226)
- Verify that the string fling behavior is fixed with this patch
- Verify that fling behavior still works as expected on Android versions affected by the [original bug](https://issuetracker.google.com/issues/112385925), and those immediately following it (to verify that the bug being worked around was, in fact, fixed as expected).
Reviewed By: javache
Differential Revision: D38287277
Pulled By: ryancat
fbshipit-source-id: 2c786872c4d41655b3849bb92e02f1f16c663b41
Summary:
Changelog: [Android][Fixed] - Fix such that when the scrollviews call `onChildStartedNativeGesture`, they appropriately call `onChildEndedNativeGesture` to unlock the native gesture such that `JSTouchDispatcher` or `JSPointerDispatcher` will continue to emit events.
### How did we find this issue?
As React Native is adding pointer event support for different input types, we noticed after pressing and dragging on a ScrollView, hover events would not fire.
### Why was this not an issue before?
This was always an issue -- it was just that `JSTouchDispatcher` worked its way around it by explicitly setting `mChildIsHandlingNativeGesture = false` on a `ACTION_DOWN` event, [code pointer](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSTouchDispatcher.java#L76). Similarly, `JSPointerDispatcher` [copied this logic](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/main/java/com/facebook/react/uimanager/JSPointerDispatcher.java#L106).
With new hover support in `JSPointerDispatcher` no similar workaround was put in (or even a good place to insert).
### What's next?
* As a follow-up, we should look at removing this workaround (at least for `JSPointerDispatcher`)
* By searching for usages of where we `notifyNativeGestureStarted`, it looks like `ReactDrawerLayout` and `ReactSwipeRefreshLayout` both do and don't call the symmetric `notifyNativeGestureEnded`. This will likely be an issue in the future (or maybe if we remove the workaround)
Reviewed By: mdvacca
Differential Revision: D37977982
fbshipit-source-id: 0d18767f4debbf24cfb24b54df1310f6f96a0d03
Summary:
Subclassing a ViewManager means an additional PropsSetter class is generated (and other overheads). Instead we can use a Factory/Provider to construct ReactTextViewManager, since we don't actually need a subclass.
Changelog: [Internal]
Reviewed By: rshest
Differential Revision: D36411098
fbshipit-source-id: 11c5ba5c9683a3ae4741cf61338f1983c69d9b69
Summary:
This diff fixed a NPE in horizontal scroll view when calling scrollToEnd API in side effect.
The problem here is we may trigger side-effects before the required view got mounted for performance reasons. We've been fixing this with retry logic on those side-effects and we've already done this in vertical scroll view. This is to fix on the horizontal scroll as well.
Changelog:
[Android][Fixed] - Fixed HorizontalScrollView API scrollToEnd causing NPE in side-effects.
Reviewed By: lunaleaps, JoshuaGross
Differential Revision: D37571847
fbshipit-source-id: 0a4dc38381008350fd09908aa3ebb64e3e65a424
Summary: Changelog: [Internal] - We can now remove the '2' suffix as we had an internal implementation that was not truly aligned with W3C pointers but used the same name. We have aligned the internal types to match w3c so we can now remove the suffix that differentiates them.
Reviewed By: vincentriemer
Differential Revision: D37545813
fbshipit-source-id: 6f2336ae9e314066c340161113268c1f28621a71
Summary:
setFocusable(int) was added in Android O, and setHyphenationFreqauency was added in M.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D37462117
fbshipit-source-id: e59d2de49dbdcddfdba25def6bb39695c65efe89
Summary:
Fix crashes that can occur on older versions of Android due to not-yet-implemented APIs.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D37321713
fbshipit-source-id: a27aaf4b28e19a86f4cb10808162102177b9f306
Summary:
D36784563 (https://github.com/facebook/react-native/commit/ec307e0167deca7f17640cd3c5a60f6be5f47b62) caused some issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Changelog
[Android] [Fixed] - Revert PR 33924 because of issues with TextInputs with numeric keyboard types not respecting the secureTextEntry prop
Reviewed By: makovkastar
Differential Revision: D36994688
fbshipit-source-id: 89cd556ca1cf8fd89560aeb9ead129607b4c13c6
Summary:
This diff fixes the rendering of transparent borders in RN Android views
The fix clips the view ONLY when there is a border color that's non transparent
This change unifies the rendering of transparent and semitransparent borders for Views between RN Android, iOS and Web
Changelog: [Android][Fix] Fix rendering of transparent borders in RN Android
Reviewed By: JoshuaGross
Differential Revision: D36890856
fbshipit-source-id: 38fc2ae215f136160a73ca470e03fada8cb81ced
Summary:
In the constructor we should get the default gravity params (as we did previously) and then never change these; thus, we can also make these fields final. These are used in `initView` during construction and upon recycling to reset vertical and horizontal alignment to their defaults.
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36885646
fbshipit-source-id: 2f4d0b125b8645a380a08965e08db3ba1f12cae3
Summary:
Right now, when we change the keyboardType on android between between default and email, the value keyboard type stays as email (specially noticeable with the key next to the spacebar, that changes between the comma (`,`) to the at sign (`@`)).
This is because the mask we are using when updating the input is only taking into account the class, and not the flags nor the variations.
We don't apply all masks because it may interfere with flags assigned by other props, like multiline or secure text entry. Therefore, we have created our own mask, taking into account all the variations and flags that the keyboardType prop may set. This may be hard to maintain, since whenever we add any other keyboard type, we have to take these flags into mind.
The error I was trying to fix was in particular regarding going back and forward from email, but this fix may solve other similar issues with other keyboard styles.
## Changelog
[Android] [Fixed] - Fix a bug where the keyboard, once set as email, won't change back to default.
Pull Request resolved: https://github.com/facebook/react-native/pull/33924
Test Plan: In order to test this PR, any test code with a TextInput, and a way to change the value of the keyboardType should work. We should be able to see how the keyboard changes to the correct type without staying, for example, on the email state.
Reviewed By: lunaleaps
Differential Revision: D36784563
Pulled By: makovkastar
fbshipit-source-id: 74d7b61b3c07feea4e4050d7a07603a68b98e835
Summary:
tldr; `ReactEditText` and Android's emoji support in Android's AppCompat 1.4.0 / 1.4.x conflict in an odd way, causing NPEs.
`ReactEditText` defines an `InternalKeyListener`, `mKeyListener`, that it uses to make sure input from all keyboards works correctly. This listener is normally initialized at the end of the constructor.
Unfortunately, some versions of `AppCompatEditText`, most notably the version in the App Compat `1.4.0-alpha0x`, the [minimum version required for the Play Store's emoji compliance](https://developer.android.com/guide/topics/ui/look-and-feel/emoji2#appcompat) call `setInputType` from `AppCompatEditText`'s constructor. `ReactEditText` operates on the key listener inside of `setInputType` and since the `AppCompatEditText` constructor is called via call to `super` before the key listener is initialized, these versions of app compat can cause NPEs when used with React Native.
The fix is simple; check to see if `mKeyListener` is null, and initialize it if it is. This is necessary in both the constructor and inside of `setInputType`.
## 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
-->
https://github.com/facebook/react-native/wiki/Changelog
[Android] [Fixed] - NPE in `ReactEditText.setInputType` when React Native is used with some versions of a AppCompat 1.4.x. (and possibly others)
Pull Request resolved: https://github.com/facebook/react-native/pull/33920
Test Plan:
1. Build an app with both React Native and load it inside an app that is using AppCompat 1.4.x
2. Add a text field using React Native.
3. Open the screen of the app that contains the text field.
If you're working from this branch, you'll be fine. If you're working from main you'll get an NPE.
I can put together a test repo if needed.
Reviewed By: kacieb
Differential Revision: D36802622
Pulled By: cortinico
fbshipit-source-id: e7646da9a1ef0e0334152aecab0f972ca25092ec
Summary:
Followups to View Recycling diffs to improve things / clean up things a bit. This also fixes memory warnings which were not hooked up before.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36707792
fbshipit-source-id: 410e70bf0eeec5569566138af547e1601394d0e6
Summary:
See previous diff for details on general approach and benchmarks.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D36676887
fbshipit-source-id: b177dcd19f1ea687bf7d2d4f2f637d2924723340
Summary:
RN-Tester is currently crashing at startup time due to an NPE.
This PR fixes it.
## Changelog
[Android] [Fixed] - Fix NPE on `ReactEditText` due to null mFabricViewStateManager
Pull Request resolved: https://github.com/facebook/react-native/pull/33910
Test Plan: Tested locally that RN Tester runs both in Debug and in Release
Reviewed By: cipolleschi
Differential Revision: D36666440
Pulled By: cortinico
fbshipit-source-id: f004ff228fb4f9ff339aac606858d47de3706426
Summary:
There's no need for this to be a setter/getter, as there are no side-effects, and it means we can use the same helper method to read it as other feature flags.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D36595602
fbshipit-source-id: d27c01bd39d03606a6f8c17ba181a8cd0bf58dbb
Summary:
In D36345402 (https://github.com/facebook/react-native/commit/56e9aa369f5c13af38cf80ba47e9eb29d835ec89) I changed the behaviour for mount items to be skipped if they were just setting zero values. AndroidTextInput is the only component that I'm aware of that has non-zero padding by default, and we account for this when creating the native shadow node. This optimization broken TextInput use-cases that explicitly request zero-padding, since we end up ignoring it.
To keep this optimization, explicitly init ReactTextInput's padding to 0, but only in Fabric. `updateState` was the closest thing I could find to a Fabric-only callback, once it's fully rolled out, we can also move this to the constructor.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545775
fbshipit-source-id: 07bb96032c69d7e350980b0b975e637b66c307ed
Summary: Changelog: [Internal] - Bypass dispatching an event if no view along the hierarchy is listening to it. Only applied for touch-based interactions. Next change will add optimization for mouse interactions
Reviewed By: vincentriemer
Differential Revision: D35739417
fbshipit-source-id: 134ffefef3bb4f97bf3e63b6bccc0caca464dfbd
Summary:
* Make inner classes static where possible
* Make member variables final when set from constructor
* Remove Nullable on `mFabricViewStateManager` and associated checks
* Remove `createInternalEditText` which has moved to the ShadowNode (paper-only)
Changelog: [Internal]
Reviewed By: genkikondo
Differential Revision: D36545807
fbshipit-source-id: 85517511d1734f0e55de5caa012e32feb40e8492
Summary:
ViewManager does a null-check already, and so inside the `updateState` method, we can safely assume this parameter is no longer nullable.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D36545806
fbshipit-source-id: 92eefa518f11c17b91aa3da2e14066d36fa4f4c2
Summary: Changelog: [Android][Fixed] Scroll views would still receive scroll events when nested in a view with `pointer-events: "none"`
Differential Revision: D36423921
fbshipit-source-id: 87b8a236e15dda7b648b6fc649187e95a9a2cc42
Summary:
Currently on Android, React Native can only accept font resource IDs which it internally converts into Typeface objects. This change allows ReactFontManager to be passed a Typeface at runtime to enable e.g. downloading fonts on demand.
Changelog:
[Android][Added] - Ability to pass a Typeface object to ReactFontManager in addition to a font resource ID
Reviewed By: makovkastar
Differential Revision: D36138123
fbshipit-source-id: b314e8c7fc28174b5caa017076b6eb3d4f6dbaa8
Summary:
This Change fixes a possible null exception as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The exception may happen as `mFabricViewStateManager` is accessed during
the constructor of the superclass, and is not yet initialized.
- For reference, commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
Possible null exception as `mFabricViewStateManager` is accessed during
the constructor of the superclass, white it is not yet initialized.
This commit #e21f8ec34984551f87a306672160cc88e67e4793 fixes the crash which was already happening, accessing of mFabricViewStateManager before initialization, and left another one of the call of the same nature.
## 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
-->
Fix: accessing `mFabricViewStateManager` before initialization.
[JavaScript] [Fixed] - accessing `mFabricViewStateManager` before initialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/33769
Test Plan: no external tool was used.
Reviewed By: javache
Differential Revision: D36205441
Pulled By: cortinico
fbshipit-source-id: f3fca69224c7794757514f026a5293b213986186
Summary:
Now that the PFH node has been renamed this updates the pfh label.
Produced via `xbgs -l -e '"pfh:ReactNative_CommonInfrastructurePlaceholde"' | xargs sed -i 's/"pfh:ReactNative_CommonInfrastructurePlaceholde"/"pfh:ReactNative_CommonInfrastructurePlaceholder"/'`
Reviewed By: jkeljo
Differential Revision: D35374087
fbshipit-source-id: 61590f69de5a69ec3b8a0478f6dd43409de3c70b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33535
Hack to support Kotlin functions in Buck compilation: adds Kotlin stdlib as a dependency to make sure upstream targets include Kotlin jvm internal classes.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D35284430
fbshipit-source-id: 0d29ad30386514c8df5376d0a6809d3105f0cd0f
Summary:
Updates `ReadableMapBuffer` to conform to `MapBuffer` interface, to allow interchangeable use of `Readable/WritableMapBuffer` in the code.
Notable changes:
- MapBuffer.Entry getters are now represented as Kotlin properties and appended `Value` suffix (e.g. `entry.getInt()` becomes `entry.getIntValue()` in Java, or `entry.intValue` in Kotlin)
- `ByteBuffer` is imported in constructor instead of on demand. This method doesn't copy the data as the bytes are read directly from native heap, and benchmarking a 500-byte `MapBuffer` shows no difference in import speed.
- Internal logic of `ReadableMapBuffer` uses `UShort` kotlin type for key retrieval, for more correct representation of values.
- Explicit exception throws are replaced with `require` and `check` methods for `IllegalArgumentException` and `IllegalStateException` (default FB conversion).
The change also updates `ReadableMapBuffer` usages to `MapBuffer` interface where possible (virtually everywhere except JNI methods).
Changelog: [Android][Changed] - Adopt `MapBuffer` interface for `ReadableMapBuffer`
Reviewed By: mdvacca
Differential Revision: D35218633
fbshipit-source-id: 515dd974c27b2978ade325b2e1750ab8f068a20a
Summary:
While it would be better to be able to do all of the ownership metadata at the Buck macro level, that proved to be more work than expected.
This diff adds the corresponding pfh label to all targets in `xplat/js/react-native-github` that have a Supermodule label. Once the migration is complete the Supermodules labels will be able to be removed.
Reviewed By: cortinico
Differential Revision: D35221544
fbshipit-source-id: d87d5e266dfb5e6ee087251dc34dff5db299bbaf
David Vacca
Luna Wei
Harrison Spain
hurali97
Nicola Corti
Thuong Tran
Joshua Gross
Daniel Leong
Tony Du
Pieter De Baets
Xin Chen
Ron Edelstein
fabriziobertoglio1987
Charles Dudley
Daniel Espino García
Andy Zolyak
Derek Thurn
Mike Masam
Carmi Grushko
Moti Zilberman
Chris Olszewski
Andrei Shikov
