Summary:
- Just a small typo fix
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Typo in build.gradle
Pull Request resolved: https://github.com/facebook/react-native/pull/34517
Test Plan: - Check out the diff changes
Reviewed By: lunaleaps
Differential Revision: D39082272
Pulled By: cipolleschi
fbshipit-source-id: d62938d5a1e6802c6e7f44186adbbfa1a6715cf8
Summary: Changelog: [Internal] - Make AccessibilityInfo public type an exact object
Reviewed By: NickGerleman
Differential Revision: D38921820
fbshipit-source-id: 6f264595814a817fb1101788942f9127d9cc85c1
Summary:
Changelog: [Internal][iOS] Modularlize RCTBridgeModule.h 1/n - Move RCTBundleManager.h to its own file in ReactInternal target
# Why clean up RCTBridgeModule.h?
Clean up one unnecessary import of RCTBridgeModule.h.
RCTBridgeModule includes a lot of header files, and this header is imported everywhere. The ultimate goal is that files (especially React Native infra files) should only import only what they need and not import the entirely of RCTBridgeModule.h whenever possible.
This way, certain headers that are Bridge-only can be compiled out of the new architecture with a flag.
The other benefit of splitting up the headers like this is that it'll be much easier for developers to navigate between the .h and .mm files.
Reviewed By: philIip
Differential Revision: D38943262
fbshipit-source-id: 90876324de9fae25bf33c7aef820a32d7c6ce2f8
Summary:
Adds changelog for new patch.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Internal] [Changed] - add changelog entry for 0.69.5
Pull Request resolved: https://github.com/facebook/react-native/pull/34499
Test Plan: N/A
Reviewed By: dmitryrykun
Differential Revision: D39051081
Pulled By: cipolleschi
fbshipit-source-id: 857e24a19a77b85f0593945e6838216ceb5b0f5d
Summary:
This adds the Android only `rows` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `numberOfLines` prop to `rows`. This PR also updates the TextInputExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add rows prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34488
Test Plan:
1. On Android open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Fixed number of lines` section
https://user-images.githubusercontent.com/11707729/186300173-7de79799-25b8-48af-99c0-8e3abeae334f.mov
Reviewed By: christophpurrer
Differential Revision: D38981953
Pulled By: cipolleschi
fbshipit-source-id: d4d84b3c0dac7342ba9a65e2491928fbc61ff4f1
Summary:
https://github.com/facebook/react-native/issues/31056#issuecomment-786349025
>Re-implement accessibilityHint on Android so that rather that concatenate into the contentDescription, it sets the toolTipText property on the AccessibilityNodeInfo (not on the view). This is the closest analog to iOS's hint that Android has, as the text is announced after the contentDescription rather than part of it. It will will not adhere to users preferences on whether they want hints disabled or not, and still has no pause before it like real hints have, but it's far closer than using the contentDescription directly.
fixes https://github.com/facebook/react-native/issues/31056
## Changelog
[Android] [Fixed] - Re-implement accessibilityHint on Android to use AccessibililltyNodeInfo#setToolTipText instead of contentDescription
Pull Request resolved: https://github.com/facebook/react-native/pull/34427
Test Plan: https://user-images.githubusercontent.com/24992535/184837154-5c65dbf1-1031-4d56-ac1e-066af7e08edc.mp4
Reviewed By: christophpurrer
Differential Revision: D38982158
Pulled By: cipolleschi
fbshipit-source-id: 7a616e6df9f83bd21ca02cc26b5918986a1d64f8
Summary:
from the original design of `StyleSheet.setStyleAttributePreprocessor()` in https://github.com/facebook/react-native/issues/11138, the overwriting warning shows when the existing preprocess is be overwritten. the behavior changes from https://github.com/facebook/react-native/commit/33b385825c72. This PR revises the logic back to original design.
## Changelog
[Internal] [Fixed] - Show warning only when overwriting existing preprocessor in `StyleSheet.setStyleAttributePreprocessor()`
Pull Request resolved: https://github.com/facebook/react-native/pull/34479
Test Plan:
Unit Test
```
PASS Libraries/StyleSheet/__tests__/StyleSheet-test.js
setStyleAttributePreprocessor
✓ should not show warning when set preprocessor first time (2 ms)
✓ should show warning when overwrite the preprocessor (1 ms)
```
Reviewed By: dmitryrykun
Differential Revision: D38940676
Pulled By: cipolleschi
fbshipit-source-id: 80cf30fff62f4a02c17f7f42b3260a6011d5fc82
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:
The motivation of this PR is for the Alert to follow the same style override (`overrideUserInterfaceStyle` being light/dark) as the one used by the root window (`UIApplication.sharedApplication.delegate.window`).
This is something that has worked previously because `RCTPResentedViewController()` was used to present the Alert (the behavior has changed in f319ff321c). With the former approach, the alert would "inherit" the `userInterfaceStyle` of the view controller it was presented within (and that one, in turn, would "inherit" from `UIApplication.sharedApplication.delegate.window`).
With the current approach, the "style inheritance" does not work with the view controller being created [here](f3db6cc527/React/CoreModules/RCTAlertController.m (L24)).
Because this viewcontroller instance does not have where to "inherit" the styling from, the styling might be different from the rest of the app. This PR fixes that.
## Changelog
[iOS] [Fixed] - fix: RCTAlertController's UserInterfaceStyle to follow root window
Pull Request resolved: https://github.com/facebook/react-native/pull/34218
Test Plan:
Instead of
```
self.overrideUserInterfaceStyle = UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle;
```
you can do
```
self.overrideUserInterfaceStyle = UIUserInterfaceStyleDark;
```
and observe the result. So if the override is set, it'll manifest itself. If it's not set, the value of `UIApplication.sharedApplication.delegate.window.overrideUserInterfaceStyle` will be `UIUserInterfaceStyleUnspecified`, and it'll have no effect.
<details>
<summary>screenshot</summary>
</details>
Reviewed By: dmitryrykun
Differential Revision: D38660799
Pulled By: cipolleschi
fbshipit-source-id: c979266900e27be7a4732bdb6e9a496906534931
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of convertRawProp for std::optional since we can handle that in a fromRawValue specialization instead.
To make this work, we need to remove noexcept from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (57dd48b246) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: philIip
Differential Revision: D38938632
fbshipit-source-id: 1dc9a544ca679463a8aad5cc632bd918f42b15d1
Summary:
There are cases where we want to pass a union type into a TurboModule method which is handy to restrict certain arguments to a restricted set of values, e.g. restricting quality to ```'low'```, ```high``` or resolution to ```720```, ```1080```.
- We are not generating an ```union``` type in C++ but rather just cast type safe to the corresponding member type.
- We don't support mixed primitive union types at this time, e.g. ```export type ChooseSomething = 'One' | 'Two' | 3 | false;``` does not work.
- We can support mixed object union types such as ... ```export type ChooseObject = {} | {low: string};``` - which need special logic in the C++ TM to correctly parse the resulting jsi::Object
This is for C++ only, Java and ObjC are not supported atm.
Changelog:
[General][Added] - react-native-code-gen Add Union Type support for C++ TurboModules
Reviewed By: javache
Differential Revision: D38919688
fbshipit-source-id: 0fd37545b32b4f2059a8babda62dab4a85de37a9
Summary:
This PR bumps the Hermes cache keys because they got corrupted due to some sync delay between Hermes and React Native.
## Changelog
[iOS] [Fixed] - CI broken due to Hermes Commit
Pull Request resolved: https://github.com/facebook/react-native/pull/34491
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38976132
Pulled By: cipolleschi
fbshipit-source-id: 16df11ede8947d8376d316b126eefcf0177d16de
Summary:
Noticed this logging was broken when enabling the flag.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D38616851
fbshipit-source-id: acf0ab75918b389586cb713c2edf5a6bf83ee7a2
Summary:
This adds the `readOnly` prop to TextInput as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `editable` prop to `readOnly` so that `readOnly={false}` maps to `editable={true}` and `readOnly={true}` represents ` editable={false}`. This PR also updates the TextInputExample on the RNTest in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add readOnly prop to TextInput component
Pull Request resolved: https://github.com/facebook/react-native/pull/34444
Test Plan:
1. Open the RNTester app and navigate to the TextInput page
2. Test the `TextInput` component through the `Editable and Read only` section
https://user-images.githubusercontent.com/11707729/185295132-036443c8-1d5e-4567-a15e-5f1173cb0526.mov
Reviewed By: lunaleaps
Differential Revision: D38912786
Pulled By: necolas
fbshipit-source-id: faeb59ed8695732be682ec55406a2de0cb7e619a
Summary:
Changelog: [iOS][Internal] - Fix buttons property value for non-hoverable pointers
The previous diff ensured that on iOS you could run through the entirety of the non-hoverable pointer event attributes test but that also revealed some failing tests related to the `buttons` property when using a non-hoverable pointer. This diff fixes that by ensuring that we only forward the result of the `buttonMask` to `buttons` when the pointer is a mouse, and assume that it is an emulated left click otherwise.
Reviewed By: lunaleaps
Differential Revision: D38914239
fbshipit-source-id: c573e934d0e9c0ac2af4945dc5360840ddc87d4d
Summary:
changelog: [internal]
Call flushQueue directly from useAnimatedProps to avoid mismatch between `NativeAnimatedHelper.API.setWaitingForIdentifier` and `NativeAnimatedHelper.API.unsetWaitingForIdentifier`
Previously, animation queue only got called if every `setWaitingForIdentifier` call was matched by `unsetWaitingForIdentifier`. If an error is thrown, this is not the case and they get out of sync. WHen they get out of sync, they never recover and animation queue is never flushedddddd.
Reviewed By: yungsters
Differential Revision: D38938858
fbshipit-source-id: c38fdef05cc70ce274b8e16114ffe49cc2dcb9b3
Summary:
X-link: https://github.com/facebook/hermes/pull/793
Add a JSI API for constructing `ArrayBuffer`s from a user provided
`jsi::MutableBuffer`.
Changelog: [General][Added] Added ability to construct ArrayBuffers from existing memory buffers.
Reviewed By: jpporto
Differential Revision: D37744467
fbshipit-source-id: 9d9ece00d1dbde341846c45fa30c935b5fa81e9a
Summary:
As per title, the shallow checkout was breaking some workflows, so we are reverting it
## Changelog
[General] [Changed] - Revert shallow checkout
Pull Request resolved: https://github.com/facebook/react-native/pull/34480
Test Plan: CI should be green
Reviewed By: dmitryrykun
Differential Revision: D38940528
Pulled By: cipolleschi
fbshipit-source-id: 691faf2749911278923ca2d42c974e5307a06261
Summary:
ScrollView has special-case logic to dismiss keyboard on tap, controlled via the `keyboardShouldPersistTaps` property. The first click does not propagate to children of the scrollview if the tap causes the keyboard to be dismissed. This behavior is motivated by a soft keyboard on phones which takes away space from the viewport.
ScrollView historically determined if a soft-keyboard was open via querying if there was a focused TextInput. This meant that clicks to a ScrollView would be eaten, even on form factors using phsyical keyboards.
A couple years ago I added https://github.com/facebook/react-native/pull/30374 to only eat clicks when keyboard events have indicated that a soft keyboard is present. I special-cased Android out of the change, because of platform issues with its reliability of keyboard events.
After D38500859 (1e48274223) rolls out we can start to remove that special-casing, of devices which report "android" for Platform.OS.
Reviewed By: javache
Differential Revision: D38528887
fbshipit-source-id: a745b478b18abe4ef32cbdd8a14ca6dfdb5e738f
Summary:
If currently focused on a TextInput, clicking an item in a ScrollView takes two clicks.
This is because of `keyboardShouldPersistTaps`, which will fire despite a lack of keyboard events on Android due to special-casing.
This behavior is jarring in scenarios like VR where the soft keyboard is detached from the application. This change avoids eating taps, in this case, where a soft keyboard is open but not inset.
Reviewed By: genkikondo
Differential Revision: D38529237
fbshipit-source-id: a10c5dbf04e6288e0e9e0c805215054bc883339f
Summary:
Improve errors thrown when prop conversion fails by adding the property being converted. Removes the specialization of `convertRawProp` for `std::optional` since we can handle that in a `fromRawValue` specialization instead.
To make this work, we need to remove `noexcept` from a number of calls. This noexcept behaviour was making these exceptions effectively uncatcheable. The original motivation of D23787492 (57dd48b246) is correct, as we cannot reliably pass on exceptions to JS and assume that the state will be recoverable, so instead we log an error and carry on with the default value available. We should improve how the error gets reported to the user, as it will currently be hidden in logcat.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D37055069
fbshipit-source-id: 8ce121a9b187f068d3ab790c6fae66d53e6338d2
Summary:
- Fix a typo in the word "feture" (-> "feature")
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[iOS] [Fixed] - Typo in AppDelegate.mm
Pull Request resolved: https://github.com/facebook/react-native/pull/34462
Test Plan: - Read the diff change
Reviewed By: dmitryrykun
Differential Revision: D38900680
Pulled By: cipolleschi
fbshipit-source-id: cdc5fb183cb7f5485a553dde7ea381f27f83e903
Summary:
Changelog:
[iOS][Fixed] - When source maps are enabled, clean up temporary files from the build directory. Reduces bundle size by at least 1MB.
Reviewed By: cipolleschi
Differential Revision: D38866158
fbshipit-source-id: 0f46faf4e767bb7417b24f283fbe19cfa022941a
Summary:
This PR removes unused variable `NODE_MODULES_DIR` passed from `build.gradle` to `CMakeLists.txt` which causes the following CMake warnings to appear in the logs:
```
> Task :app:configureCMakeDebug[arm64-v8a]
C/C++: debug|arm64-v8a :CMake Warning:
C/C++: debug|arm64-v8a : Manually-specified variables were not used by the project:
C/C++: debug|arm64-v8a : NODE_MODULES_DIR
```
First I changed the value of `NODE_MODULES_DIR` to some non-existent path (i.e. `-DNODE_MODULES_DIR=/foo/bar`) to confirm that the variable is indeed unused. Then I completely removed it from `arguments` and the CMake warning disappeared.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[Android] [Fixed] - Removed unused variable `NODE_MODULES_DIR` from `build.gradle` in app template
Pull Request resolved: https://github.com/facebook/react-native/pull/34459
Test Plan:
1. Create a new RN 0.70.0-rc.3 app from template with `npx react-native@next init RN070RC3 --version 0.70.0-rc.3`
2. Set `newArchEnabled=true` in `settings.gradle`
3. Open `android` directory in Android Studio
4. Run Gradle Sync
5. Build the app
6. Search for `NODE_MODULES_DIR` in the logs
7. Notice the CMake warning
8. Remove the line from this PR
9. Build the app again
10. Search for `NODE_MODULES_DIR` in the logs
11. Confirm there are no occurrences
Reviewed By: neildhar
Differential Revision: D38864127
Pulled By: cortinico
fbshipit-source-id: b41440edcdba63945e3b08cef897a250686c13ba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34452
This will unblock the RN `test_android` CI Job as currently two versions
of `hermes-parser` are picked up during package resolution.
Changelog:
[Internal] [Fixed] - Blacklist sdks/hermes from Metro resolution
Reviewed By: cipolleschi
Differential Revision: D38856931
fbshipit-source-id: 49d941f762ba0ef953c5c42b0ca13ac1c74b5ba5
Summary: Changelog: [Internal] - Create a type declaration for AccsesibilityInfo for clearer signal when our public API types change
Reviewed By: yungsters
Differential Revision: D38712552
fbshipit-source-id: cc7c727d41fb03ca714cb05fd10dc32038374fd0
Summary:
Changelog: [iOS][Internal] - Apply pointer entering/leaving tracking to touch-initiated pointer events
This diff takes the refactoring done in the previous diff in this stack and applies it to the pointer events which are converted from discrete touch events. In addition this adds a check when an ActiveTouch is created to see if the pointer in question was hovering before the touch started or not, which is stored and leveraged once the touch is lifted to determine if we should treat the pointer as leaving the screen entirely or not.
Reviewed By: lunaleaps
Differential Revision: D38762330
fbshipit-source-id: 08452783e01bf5944c57b94a292805b2d69d4384
Jérémy Barbet
Paige Sun
Luna Wei
Harrison Spain
Gabriel Donadel Dall'Agnol
Lorenzo Sciandra
Lulu Wu
hurali97
fabriziobertoglio1987
Shawn Shihang Wei
Kudo Chien
Vojtech Novak
Pieter De Baets
Christoph Purrer
Marshall Roch
Riccardo Cipolleschi
Vincent Riemer
Samuel Susla
Neil Dhar
Nick Gerleman
Ravi Shah
Héctor Ramos
Dmitry Rykun
Michał Pierzchała
Tomek Zawadzki
Breadman Da
Nicola Corti
throwaway-fishery
