Summary:
iOS did not support the implementation of Korean word-wrap(line-break) before iOS14.
If the attribute applied, the word-wrap of Korean will works.
## 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] [Added] - Line break strategy for Text and TextInput components
Pull Request resolved: https://github.com/facebook/react-native/pull/31272
Test Plan:
1. Test build and run on above iOS 14.
2. Test it does not affect existing text components when set default(none) strategy.
3. Test whether word-wrap works with Korean when set hangul-word strategy.
<img src="https://user-images.githubusercontent.com/26326015/112963967-d7f70c00-9182-11eb-9a34-8c758b80c219.png" width="300" height="" style="max-width:100%;">
Reviewed By: javache
Differential Revision: D39824809
Pulled By: lunaleaps
fbshipit-source-id: 42cb0385221a38c84e80d3494d1bfc1934ecf32b
Summary:
D31464478 enabled clang-format by default across projects, but opted out directories with a lot of formatting errors. This removes the opt-out, so clang-format is run in that directory as well.
Changelog:
[Internal][Changed] - Remove clang-format opt-out for Libraries
Reviewed By: lunaleaps
Differential Revision: D40310275
fbshipit-source-id: abe154ab466798fbfa010364a3627f40ca18b179
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/34944
In react-native-windows, the ability to detect a press event on a virtual span is dependent on setting a native only `isPressable` prop.
This modifies the Text component to include `onPressIn` and `onPressOut`. As a side-effect, this will also lazily initialize the pressability config when `onPressIn` or `onPressOut` only is set.
Changelog:
[General][Fixed] - Pressability for text with only `onPressIn` / `onPressOut` props
Reviewed By: yungsters
Differential Revision: D40264432
fbshipit-source-id: 583b210127d8f020ad98030d4a5381c302e88d2a
Summary:
Sync the changes in `types/react-native` https://github.com/DefinitelyTyped/DefinitelyTyped/pull/62394 to here as required by lunaleaps
## Changelog
[Internal] [Added] - Sync new changes in `types/react-native`
Pull Request resolved: https://github.com/facebook/react-native/pull/34794
Test Plan: Tested in `types/__typetests__/index.tsx`
Reviewed By: cortinico
Differential Revision: D39846101
Pulled By: cortinico
fbshipit-source-id: cebe62aa97f764d9a10c8371936870c515fb9be3
Summary:
This adds support for the `verticalAlign` style attribute, mapping the already existing `textAlignVertical` attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android on the RNTester in order to facilitate the manual QA of this.
## Changelog
[Android] [Added] - Add support for verticalAlign style
Pull Request resolved: https://github.com/facebook/react-native/pull/34567
Test Plan:
1. On Android open the RNTester app and navigate to the Text page
2. Check the text alignment through the `Text alignment` section
https://user-images.githubusercontent.com/11707729/188051914-bf15f7eb-e53f-4de5-8033-d1b572352935.mov
Reviewed By: jacdebug
Differential Revision: D39771237
Pulled By: cipolleschi
fbshipit-source-id: d2a81bec1edd8d49a0fcd36a42fea53734909739
Summary:
React Native's TS definitions are currently mostly stored in one monolithic file. This change splits the definitions up to correspond to the source files they came from, and are placed next to the source files. I think this should help inform, and make it easy to update the TS declarations when touching the Flow file.
I noticed as part of the change that the typings have not yet removed many APIs that were removed from RN. This is bad, since it means using the removed/non-functional API doesn't cause typechecker errors. Locating typings next to source should prevent that from being able to happen.
The organization here means individual TS declarations can declare what will be in the RN entrypoint, which is a little confusing. Seems like a good potential next refactor, beyond the literal translation I did.
Changelog:
[General][Changed] - Place TS Declarations Alongside Source Files
Reviewed By: lunaleaps, rshest
Differential Revision: D39796598
fbshipit-source-id: b36366466fd1976bdd2d4c8f7a4104a33c457a07
Summary:
This PR adds support for number values for `fontWeight` as requested in https://github.com/facebook/react-native/issues/34425.
## 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
-->
[General] [Added] - Added support for number values in fontWeight.
Pull Request resolved: https://github.com/facebook/react-native/pull/34598
Test Plan:
```js
<Text style={{ fontWeight: 900, color: 'red' }}>
Hello World
</Text>
```
Reviewed By: jacdebug
Differential Revision: D39268920
Pulled By: cipolleschi
fbshipit-source-id: 9bb711677bf173f9904b74f382659042856efd83
Summary:
This adds the `id` prop to `Text`, `TouchableWithoutFeedback` and `View` components as requested on https://github.com/facebook/react-native/issues/34424 mapping the existing `nativeID` prop to `id`. As this components are inherited by others this also adds the `id` prop support to `Image`, `TouchableBounce`, `TouchableHighlight`, `TouchableOpacity` and `TextInput`.
This PR also adds android tests ensuring that the `id` property is passed to the native view via the `nativeID` prop, these tests were based on the existing `nativeID` tests ([NativeIdTestCase.java](https://github.com/facebook/react-native/blob/main/ReactAndroid/src/androidTest/java/com/facebook/react/tests/NativeIdTestCase.java)).
## Changelog
[General] [Added] - Add id prop to Text, TouchableWithoutFeedback and View components
Pull Request resolved: https://github.com/facebook/react-native/pull/34522
Test Plan: Ensure that the new `id` prop android tests pass on CircleCI
Reviewed By: lunaleaps
Differential Revision: D39089639
Pulled By: cipolleschi
fbshipit-source-id: 884fb2461720835ca5048004fa79096dac89c51c
Summary:
This adds support for the `userSelect` style attribute, mapping the already existing selectable attribute as requested on https://github.com/facebook/react-native/issues/34425. This PR also updates the TextExample.android and TestExample.ios on the RNTester in order to facilitate the manual QA of this.
## Changelog
[General] [Added] - Add support for `userSelect` style
Pull Request resolved: https://github.com/facebook/react-native/pull/34575
Test Plan:
- open the RNTester app and navigate to the Text page
- Check the `Selectable Text` through the Selectable text section
<Image src="https://user-images.githubusercontent.com/22423684/188112863-65acd145-76b0-47ba-8bc6-f72298077096.png" height="600" width="300" />
Reviewed By: yungsters
Differential Revision: D39252798
Pulled By: jacdebug
fbshipit-source-id: f7fabf20ee68778d75461f511c56f94d0d756d9c
Summary:
BaseViewManager.setPointerEnter was never called on ReactTextViews, and thus text views would not receive hover events.
Changelog:
[Internal][Fixed] - Add pointer events to text view config
Reviewed By: lunaleaps, javache
Differential Revision: D38557546
fbshipit-source-id: cfc0e5442efbd7c76d1b47acf56496d10ef78cf5
Summary:
At the moment we are having a bug that whenever we hit a "Done" button in an input field, a value is not submitted back, so the users cannot complete their work. Here is an example:
https://pxl.cl/28xFq
To fix it, we call a textInputShouldSubmitOnReturn method on Accessory button click.
Changelog
[IOS][Fixed] - Fix keyboard accessory button not triggering onSubmitEditing
Reviewed By: dmitryrykun
Differential Revision: D38152974
fbshipit-source-id: fc026dffd641966cd3d342d95a56c43c71008036
Summary:
The `NSMutableAttributedString` was initialized with the same backing store as the cached attributed string on the shadow queue (background thread), but then passed to the main thread and ultimately the JS thread.
This explicitly copies the mutable attributed string into an immutable one on the shadow thread before passed off to other threads, which hopefully will address the `convertIdToFollyDynamic` crash that always includes `RCTBaseTextInputShadowView` touching an attributed string on the shadow queue in the trace.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38133150
fbshipit-source-id: f371da5d17a32c3341287cd3e9730b31a98495f9
Summary:
A crash encountered in react-native-macOS is very similar to one fixed by https://github.com/microsoft/react-native-macos/pull/489#discussion_r451789471 (see discussion), and it's possible this `replacement` string also suffers from sharing the same backing store as the attributed string (maybe only when the range encompasses the entire string?) and therefore should be copied as well.
Changelog:
[iOS][Fixed] - Possible fix for convertIdToFollyDynamic crash in RCTBaseTextInputView and RCTEventDispatcher
Reviewed By: sammy-SC
Differential Revision: D38064551
fbshipit-source-id: 9c15f2a980155ab3cbb3fde79fcb93b24ee2091a
Summary:
This method assumes a semicolon existed before the closing bracket (`>`), but only does on iOS. This instead puts the content before the closing bracket, which is always there on both platforms.
Changelog:
[macOS][Fixed] - Fix exception thrown by [RCTTextView description] on macOS
Reviewed By: sammy-SC
Differential Revision: D38074642
fbshipit-source-id: f46d15c2bf2d966d1c1430568f083e4d501d4b40
Summary: Add annotations to function parameters required for Flow's Local Type Inference project. This codemod prepares the codebase to match Flow's new typechecking algorithm. The new algorithm will make Flow more reliable and predicatable.
Reviewed By: evanyeung
Differential Revision: D37353648
fbshipit-source-id: e5a0c685ced85a8ff353d578b373f836b376bb28
Summary:
[A recent fix](https://github.com/facebook/react-native/pull/33076) to Android to set focusable to true when accessible is true, and this caused several components not to work correctly.
This JS change essentially reverts the default back to Text not being focusable unless it is explicitly set. Android's "auto" behavior is better than setting `accessible=true`, and it's also the behavior React Native has had since accessibility on Android was implemented.
# Wall of Text Explanation
Explanation From Brett's comment [here](https://www.internalfb.com/diff/D35908559?dst_version_fbid=700876567897063&transaction_fbid=477905564133412)
blavalla
Generally speaking, "accessible" in react native maps to "focusable" in Android views, and the default value for "focusabe" for a TextView (and actually all views) is "auto" not "false". The difference here is that "false" is telling the system to explicitly disallow focus on this element, where as "auto" is telling the system that it's up to whatever service is trying to focus to determine if it should or not.
In the case of text, Talkback generally does default to focusing on Text when it's set to "auto", though it also does try to combine this text together with other not-explicitly focusable siblings and roll the focus up to some common ancestor element.
In the case of TetraButton here, I would expect the default behavior would be that the text is "auto" focusable, so Talkback would combine the text here with the parent <TetraPressable> (which is explicitly focusable via accessible="true").
...
[This diff](https://github.com/facebook/react-native/pull/33076) was to fix the issue with "disabled" not properly announcing on text views, which was commonly occuring due to the description-combining feature described above. Basically, when Talkback decides to combine not-explicitly-focusable elements together, it ignores properties like "disabled", "selected", etc. so when combined only the text is transferred.
The "fix" here was to make sure that if disabled was set, that an element was always explicitly focusable so that it wouldn't be eligible to be combined with others. I think that as a general concept makes sense, but the fix actually surfaced an issue that is likely a much older bug.
This line in <Text>
```
accessible={accessible !== false}
```
Is basically always setting accessible="true" unless it's explicitly set to false, and has been in there for years. It was likely added to force text to be accessible by default for iOS. But until [this diff](https://github.com/facebook/react-native/pull/33076) this line was basically a no-op for Android, since setting accessible="true" on text would do nothing at all.
[This diff](https://github.com/facebook/react-native/pull/33076) changed this so that setting accessible="true" worked how you'd expect, by making the view explicitly focusable, which was necessary for the disabled behavior to work properly. But that means that now by default all text views are explicitly focusable on both iOS and Android, and this there is likely many components that were built that don't expect this to be the case.
It doesn't seem like the right fix here is to revert this behavior to its previous state, as it wasn't working how anyone would expect it to if they looked at the code, and it seems like we were relying on some fairly undocumented behavior of Talkback to get it to work how we wanted. If we truly only wanted accessible="true" to be set on all TextViews for iOS, we should be explicit about it and do a platform check before setting that property. If we didn't want this to be iOS-specific, then everything is now actually working as originally intended.
For reference, this is the diff that introduced the default-accessible text - https://www.internalfb.com/diff/D1561326, and the description makes it clear that this was only tested on iOS, and the behavior was explicitly trying to map to iOS norms such as not allowing nested accessible elements.
Changelog:
[Android][Fixed] Make Text not focusable by default
Reviewed By: ryancat
Differential Revision: D36991394
fbshipit-source-id: c45d2ada72bb2d6ffeee6947d676a07fb8899449
Summary:
Removes the `propTypes` member from the `Image`, `Text`, and `TextInput` components.
They have been deprecated since React Native v0.66.
Changelog:
[General][Removed] - Removed `Image.propTypes`, `Text.propTypes`, and `TextInput.propTypes`.
Reviewed By: kacieb
Differential Revision: D33750298
fbshipit-source-id: 085f83ad838196bdd531b097b8ce5957270c3ad1
Summary:
changelog: [internal]
Introduce a way to execute `onKeyPress` synchronously. This feature is experimental and will be changed in the future. It is not decided if marking native events as "sync" is going to be path forward with synchronous access.
NOTE: This is experimental API.
Reviewed By: ShikaSD
Differential Revision: D32882092
fbshipit-source-id: 68c66a9bb7c97758219e085c88a77f3c475c1eb3
Summary:
react-native-windows currently needs to maintain a fork of TextNativeComponent to wire through a native-only prop for `isPressable`.
The reason we do this on Windows is that we implement an optimization so we only attempt to hit test a virtual Text node if it is actually pressable, leading to significant perf improvement for pointer events (e.g., onMouseEnter / onMouseLeave) on Text.
Changelog:
[General][Added] - Native-only prop to optimize text hit testing on some RN platforms
Reviewed By: JoshuaGross
Differential Revision: D32564637
fbshipit-source-id: bf47c68d94a930d2c620cb3b1584355c5e412bd4
Summary:
Links under `reactnative.dev` that ended with `.html` lead to Page not found.
Fixed the url so that users get sent to the appropriate url.
## 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
-->
[General] [Fixed] - Fixed dead links in the comments.
Pull Request resolved: https://github.com/facebook/react-native/pull/32619
Test Plan: - Changed links are accessible
Reviewed By: lunaleaps
Differential Revision: D32528978
Pulled By: cortinico
fbshipit-source-id: e039d18188371cf5240b37049e431329e28b1b8b
Summary:
fixing oncall issue: https://fb.workplace.com/groups/rn.support/permalink/7241260632589156/
in this diff, we add the properties to the native views that are needed for the `onScroll` event.
`UITextField` is not a `UIScrollView` unlike `UITextView`, so we need to add these dummy properties
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32523147
fbshipit-source-id: 1d4f227f498fa1c333e2d6c457484b559ca18f7e
Summary:
Deprecates `prop-types` from React Native.
Existing use cases will be presented with a warning to migrate to the newly published `deprecated-react-native-prop-types` module.
In a subsequent release, these will be removed from React Native.
Changelog:
[General][Changed] - Accessing `Image.propTypes`, `Text.propTypes`, `TextInput.propTypes`, `ColorPropType`, `EdgeInsetsPropType`, `PointPropType`, or `ViewPropTypes` now emits a deprecation warning.
Reviewed By: kacieb
Differential Revision: D29019309
fbshipit-source-id: 21e518e588fa05c498cc75ba81f69cfa8a9d0613
Summary:
i saw this a lot in the codebase, it's not optimal bc we're using two selectors when we only need one.
fastmod --extensions m,mm '\[\[(.*) alloc] init]' '[${1} new]' --dir xplat/js/react-native-github/*
i manually updated the callsites that this codemod couldn't handle (e.g., where there were more than one of these instances in a single line)
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D31776561
fbshipit-source-id: 1b16da240e8a79b54da67383d548921b82b05a9f
Summary:
This pull request aims to remove iOS 11 version check which is no longer needed.
The minimum iOS deployment target for React Native is `iOS 11` but we still have iOS 11 version check like below.
```
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 110000 /* __IPHONE_11_0 */
if (available(iOS 11.0, *)) {
```
> React Native apps may target iOS 11.0 and Android 5.0 (API 21) or newer.
ref: https://github.com/facebook/react-native#-requirements
------
If there is a team motivation to remove the deprecated methods and classes before iOS 10, I can continue the work in this pull request or in the continuing pull requests.
We have deprecated warnings for these in the project.
- `UIUserNotificationSettings`
- `UILocalNotification`
- `topLayoutGuide` and `bottomLayoutGuide`
- `automaticallyAdjustsScrollViewInsets`
## Changelog
[iOS] [Changed] - Remove iOS 11 version check
Pull Request resolved: https://github.com/facebook/react-native/pull/32151
Reviewed By: sammy-SC
Differential Revision: D30877917
Pulled By: yungsters
fbshipit-source-id: d903ea5d557beeb65ef87bfce572e4db3532b3c5
Summary:
hyphenationStrategy must be one of one of Layout#HYPHENATION_FREQUENCY_NONE, Layout#HYPHENATION_FREQUENCY_NORMAL, Layout#HYPHENATION_FREQUENCY_FULL: (https://developer.android.com/reference/android/widget/TextView#setHyphenationFrequency(int))
Thus "high" and "balanced" are not only redundant, but actually don't do what the value indicates - Layout#BREAK_STRATEGY_BALANCED (constant value: 2) and Layout#BREAK_STRATEGY_HIGH_QUALITY (constant value: 1) are only meant to be used for android:breakStrategy
Changelog:
[Android][Changed] - Remove `"high"` and `"balanced"` as values for `android_hyphenationFrequency` on `Text`
Reviewed By: JoshuaGross
Differential Revision: D30531096
fbshipit-source-id: 1a0b6e733bb21ce6b2f104a2025a79c16de3cfea
Summary:
Updates previous variant that was crashing a surface to the non-crashing variant.
Now it prints error in console and modifies value to be 0.
Changelog: [General][Fixed] Clamp negative values for `numberOfLines` in <Text> component
Reviewed By: yungsters
Differential Revision: D30129658
fbshipit-source-id: fda47a262365573514d3e1e4bf8a26f6d30cdae0
Summary:
Negative `numberOfLines` prop is not supported by Android and causes a crash during layout measurement. This change adds a check in JS to catch the error earlier.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D30047103
fbshipit-source-id: 4248a0f573c3b6facd25c7ae6ce007a357a1469b
Summary:
When maxLength is defined in <TextInput>, if the last character at max length is an emoji, the content of the input is cleared:
{F620865178} {F620865237}
Related Github issues:
https://github.com/facebook/react-native/issues/10929https://github.com/facebook/react-native/issues/10964
## Root cause:
When NSString was created, unicode characters were 16-bit long, so Objective-C considers every unicode character as 16-bit. However, unicode was later extended to more than 16bit, for example, emojis, which causes NSString substring method cuts off at the wrong position.
Example:
```
NSString *s = @"abc{emoji:1f601}";
NSInteger len = s.length; //length is 5 (as {emoji:1f601} occupies two 16-bit characters)
NSString *s3 = [s substringToIndex: 3]; //s3 is "abc"
NSString *s4 = [s substringToIndex: 4]; //s4 is null!
```
If string s, "abc{emoji:1f601}", is entered in <TextInput>, which has max length 4, it will truncate the string to the first 4 characters, "cutting" the emoji in half which causes encoding error and returns null. The text input is cleared.
## Solution:
If the character at max length is longer than 16-bit, truncate the character BEFORE it instead. In the previous example, truncate till index 3 instead of 4. The end result will be "abc" and the emoji is dropped.
## Changelog:
[iOS] [Fixed] - <TextInput> content is reset when emoji is entered at the max length
Reviewed By: p-sun
Differential Revision: D28821909
fbshipit-source-id: 4720d864970b554160ed5388f65b352ce95a6199
bang9
Oleksandr Melnykov
Nick Gerleman
Eric Rozell
Daksh Bhardwaj
Aelita
Gabriel Donadel Dall'Agnol
Tim Yung
Nick Gerleman
fabriziobertoglio1987
ankit-tailor
Viraj-10
Genki Kondo
Christoph Purrer
Oleh Malanchuk
Tony Du
Pieter Vanderwerff
Kacie Bawiec
Pieter De Baets
Phillip Pan
Diego Pasquali
Minsik Kim
Tim Yung
MaeIg
Andres Suarez
Samuel Susla
Eric Rozell
Jesse Katsumata
Liron Yahdav
David Vacca
Xiankun Cheng
Ken Tominaga
Andrei Shikov
Shuhao Zhang
