Summary:
When you have a numeric non-multiline `TextInput` and a `returnKeyType` is `done` we automatically add an input accessory view ([implementation](603cc48ceb/Libraries/Text/RCTTextInput.m (L269)#L315)).
That view has a done button which triggers [handleInputAccessoryDoneButton](603cc48ceb/Libraries/Text/RCTTextInput.m (L317...L320)) which currently directly sends `endEditing:` to the text field / text view. As a consequence, the [textInputShouldReturn](603cc48ceb/Libraries/Text/RCTTextInput.m (L118...L121)) is not called and we dismiss the keyboard even if the `blurOnSubmit` value is `false`.
Confirm that the keyboard is not dismissed when you tap on Done button on this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit={false}
/>
```
and that the keyboard is dismissed for this `TextInput`:
```
<TextInput
keyboardType={'numeric'}
returnKeyType={'done'}
blurOnSubmit
/>
```
Closes https://github.com/facebook/react-native/pull/15438
Differential Revision: D5601462
Pulled By: javache
fbshipit-source-id: 24e4048e2e66d1a42fa97d83b4a3eb61e5d817ea
Summary:
Several changes here. The `Text.md` and `PixelRatio.md` files were appended to the autodocs during site generation. This seemed excessive for just two files, so I've just merged the content into the autodocs themselves. It should help us simplify the website generation process in the future.
I've also merged IssueGuidelines.md and PullRequestGuidelines.md into the Contribution/Maintainers guidelines to improve their visibility.
Finally, I renamed Help to Community in the nav bar.
Ran the website locally, and verified every page rendered as expected: the Community page, Contributing page, Maintainers page.
Closes https://github.com/facebook/react-native/pull/15374
Differential Revision: D5567400
Pulled By: hramos
fbshipit-source-id: e06056edb12c9a17319fe1af46b2ef3a2e1b5854
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary: Because of some rebase issue `reactAccessibilityElement` was implemented with old invalid name, which breaks some accessibility features.
Reviewed By: mmmulani
Differential Revision: D5458283
fbshipit-source-id: 1e66a2f54c1f1a85118c9432b68895679a10059c
Summary: This fixes pretty bad issue when contentSize is calculated based on an intrinsic horizontal (width) limitation, not on a real/current horizontal (width) one.
Reviewed By: mmmulani
Differential Revision: D5422114
fbshipit-source-id: 0eb582aeb59d29530990d4faabf2f41baa79c058
Summary: Previous implementation was not quite correct (because it was framed by hacky event handling) and caused some issues with new ScrollView improvements (autoscroll to focused TextInput).
Reviewed By: javache
Differential Revision: D5414439
fbshipit-source-id: 72d1f23170340c453b939dca8b72422822acc1d7
Summary:
This diff unifies `selection` prop between single line and multi line text inputs.
Besides that, this diff improves the selection event handling, makes it more robust and predictable.
(See inline comments.)
Reviewed By: mmmulani
Differential Revision: D5317652
fbshipit-source-id: db5b0d2c0b80268e479ba866980e14b444079386
Summary:
iOS has tendency to skip `textInputDidChange` event (irregulary, across all dispatch ways: target-action, delegate, notification center)
when text input looses focus. Usually it happens when autocorrection applies some changes automatically on loosing focus, but I think these are bunch of different cases.
So, the workaround is pretty simple: if there was no `textInputDidChange` event between `shouldChangeText` and `didEndEditing`, we create it manually.
Previously these workaround complicate our business logic, now they was decoupled in separate adapter.
Reviewed By: mmmulani
Differential Revision: D5317651
fbshipit-source-id: 138143213e8752fe9682229c51685aef614c00dd
Summary: The implementation of `clearTextOnFocus` was unified and moved to baseclass.
Reviewed By: javache
Differential Revision: D5299489
fbshipit-source-id: ff166f9bb0673ff8766f20b677f56810f64d7b2d
Summary: The implementation of `clearsOnBeginEditing` was unified and moved to superclass.
Reviewed By: javache
Differential Revision: D5299396
fbshipit-source-id: 98c5494a782cbe4df5b2d6021828eb7b2012f6dc
Summary:
Now the business logic of `blurOnSubmit` is pretty simple and lives inside `RCTTextInput`,
whereas UIKit hacks/workarounds lives inside `RCTBackedTextInputDelegateAdapter`.
Reviewed By: javache
Differential Revision: D5299397
fbshipit-source-id: 6a9d4194324ff9446c74fdb32ad5357e849e471d
Summary: This method was identical between two subclasses, so it was moved to baseclass.
Reviewed By: javache
Differential Revision: D5297401
fbshipit-source-id: 8f56bef33f9ab0184f69da76177b5e8da10d7514
Summary:
Nothing behavioral changed in this diff; just moving code around.
`RCTBackedTextInputDelegate` is the new protocol which supposed to be common determinator among of UITextFieldDelegate and UITextViewDelegate
(and bunch of events and notifications around UITextInput and UITextView).
We need this reach two goals in the future:
* Incapsulate UIKit imperfections related hack in dedicated protocol adapter. So, doing this we can fix more UIKit related bugs without touching real RN text handling logic. (Yes, we still have a bunch of bugs, which we cannot fix because it is undoable with the current architecture. This diff does NOT fix anything though.)
* We can unify logic in RCTTextField and RCTTextView (even more!), moving it to a superclass. If we do so, we can fix another bunch of bugs related to RN imperfections. And have singleline/multiline inputs implementations even more consistent.
Reviewed By: mmmulani
Differential Revision: D5296041
fbshipit-source-id: 318fd850e946a3c34933002a6bde34a0a45a6293
Summary:
This replaces all uses of `React.createClass` with `createReactClass` from the `create-react-class` package, attempting to match use of `var` and `const` according to local style.
Fixes#14620
Refs #14712
Closes https://github.com/facebook/react-native/pull/14729
Differential Revision: D5321810
Pulled By: hramos
fbshipit-source-id: ae7b40640b2773fd89c3fb727ec87f688bebf585
Summary:
Standard only-numeric (number pad) keyboard on iOS does not have any "Done" or "Enter" button, and this is often very badly hurt user experience.
Usually it can be solved by implementing custom `inputAccessoryView`, but RN does not have built-in support for customizing it.
So, this commit introduced limited support only for "Done" button (returnKeyType="done") and it should suite very well for the vast majority of use cases.
This is highly requested feature, see more details here:
https://github.com/facebook/react-native/issues/1190
Reviewed By: mmmulani
Differential Revision: D5268020
fbshipit-source-id: 90bd5bffac6aaa1fb7c5c2ac539b35b04d45918f
Summary:
Nothing really changed except that there is no code duplication in this part anymore.
More unification is coming!
Reviewed By: mmmulani
Differential Revision: D5144435
fbshipit-source-id: 390f795be3228907b254f8656783232013c36abe
Summary: Some basic same to both classes functionality was moved to base class, and it is just a beginning.
Reviewed By: mmmulani
Differential Revision: D5144429
fbshipit-source-id: 56c6400d46f4cf3c0058fe936cba524dd5d490df
Summary: RCTBackedTextInputViewProtocol is supposed to unify interface of backed text inputs which will make them accessible from managers and wrapper views.
Reviewed By: mmmulani
Differential Revision: D5144428
fbshipit-source-id: 473e7364d4af2edcd87c5555200e1325c38a8214
Summary: We have to have RCTTextView and RCTTextInput as much unified as possible, and this is a small step in this direction.
Reviewed By: javache
Differential Revision: D5143877
fbshipit-source-id: ee8fcab6093fe5d994c85110b07ea16e64fed262
Summary: `UITextField` surprisingly does not have `editable` property (only UITextView does), so we have to implement it ourselfs.
Reviewed By: javache
Differential Revision: D5153070
fbshipit-source-id: 5a76c623fc5c7c3eec10c600c942cf82c93833cd
Summary: This regression was recently introduced when RCTTextField was splitted into two classes.
Reviewed By: mmmulani
Differential Revision: D5313055
fbshipit-source-id: 1027ddeed7ea9a4bf6f30b0182092f42588b83e3
Summary:
Fixes#13691.
Prior to this change, VoiceOver generally didn't say anything when selecting a multiline TextInput. The only exception was VoiceOver would announce the TextInput's placeholder if it had one set.
After this change, VoiceOver announces the following for multiline TextInputs:
- The TextInput's content.
- The TextInput's placeholder if the TextInput doesn't have any content in it.
- The fact that the TextInput is a textfield.
- The cursor position if the TextInput is being edited.
This is similar to the behavior of single line TextInputs.
This change achieves this by disabling `RCTTextView` as an accessibility element. `RCTTextView` is a subclass of `RCTView` so VoiceOver doesn't recognize this as a textfield. Instead, VoiceOver now sees the child `RCTUITextView` which is a subclass of `UITextView` so VoiceOver does recognize it as a textfield. Additionally, an `accessibilityLabel` implementation was added to `RCTUITextView` in order to take the value of the placeholder into account.
Verified the announcements of TextInputs with various props:
- No placeholder and no content
- Just a placeholder
- Just content
- Both a placeholder and content
Did this for both singe line inputs and multiline inputs. For setting content in multiline inputs, I tested both using the `value` prop and passing children. All other props being equal, these configurations resulted in similar announcements.
I verified that the following accessibility props work the same on singleline and multiline TextInputs:
- `accessible`
- `accessibilityLabel`
- `accessibilityTraits`
- `accessibilityViewIsModal`
- `onAccessibilityTap`
- `onMagicTap`
Additionally, my team has been using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/14200
Differential Revision: D5185727
Pulled By: shergin
fbshipit-source-id: 94271e6c8b089eb82006b52fe7917649d69e74af
Summary:
Sometimes, when we implement some custom RN view, we have to proxy all accessible atributes directly to some subview which actually has accesible content. So, in other words, this allows bypass some axillary views in terms of accessibility.
Concreate example which this approach supposed to fix:
https://github.com/facebook/react-native/pull/14200/files#diff-e5f6b1386b7ba07fd887bca11ec828a4R208
Reviewed By: mmmulani
Differential Revision: D5143860
fbshipit-source-id: 6d7ce747f28e5a31d32c925b8ad8fd4b98ce1de1
Summary:
Motivation:
* We maintain two different implementation of <TextInput> (multilined and singlelined), this change makes the implementations much similar which will help us to support and improve both of them in the (near) future;
* We have to have separated RCTView-based container view for (TextField) to support sofisticated bordering and so on;
* It opens to us possibility to unify UITextView and UITextField subclasses and remove code duplication across RCTTextView and RCTTextField;
* Making things decoupled in general will allow us to fix existing bugs with events.
Reviewed By: mmmulani
Differential Revision: D5083010
fbshipit-source-id: 2f2d42c2244d2b39256c51480c1f16f4e3947c01
Summary: Now padding, border and intinsic sizes are computed same way as for singlelined text input.
Reviewed By: mmmulani
Differential Revision: D5075880
fbshipit-source-id: 1bc2fd479c13a003c717b1fc3d9c69f4639d4444
Summary: Previosly `borderWidth` did not affect actual content inset (which was a problem).
Reviewed By: mmmulani
Differential Revision: D5072483
fbshipit-source-id: d43cba7414a9335b9f9fd4d1565d7aee403cce0e
Summary: Because we believe in Objective-C.
Reviewed By: javache
Differential Revision: D5070920
fbshipit-source-id: 17e2335c829f2e5857981c5028e3bcecbe5dc13f
Summary:
Singleline <TextInput> now has intrinsic size which is equal to size of placeholder.
And if <TextInput> does not have placeholder it still has intrinsic height.
So, we don't need to set the size up manually every single time anymore!
(Multiline <TextInput> already has this feature.)
Reviewed By: mmmulani
Differential Revision: D5069971
fbshipit-source-id: f65c1062a812259b66d287929314dc571dc1f3ee
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4989881
fbshipit-source-id: 674bb98c89ada1fca7b3b20b304736b2a3b8304e
Summary:
cc hramos
Pretty sure I've hit all of the places where AppRegistry is called in CRNA-pastable examples. Let me know whether you think we need to approach the version lag differently, I figure a caveat is as natural a place to call it out as any.
If you end up finding anything else that needs tweaking before cherry picking, I'm happy to push that up here too.
Closes https://github.com/facebook/react-native/pull/13744
Differential Revision: D5071038
Pulled By: hramos
fbshipit-source-id: 4a4a6f2a73079aca627f17d75a4e4b395ecbd4a8
Summary:
`contentSize` was removed from both iOS and Android, tests was updated.
USE `onContentSizeChange` INSTEAD.
Why?
* It always was a hack;
* We already have dedicated event for it: `onContentSizeChange`;
* `onChange` has nothing to do with layout actually;
* We have to maintain `onChange` handler as fast and simple as possible, this feature complicates it a lot;
* It was undocumented feature;
* We already have native auto-expandable <TextInput>, so it illuminates 99% current use cases of this feature.
Reviewed By: mmmulani
Differential Revision: D4680300
fbshipit-source-id: 337836deef0767e5f26350f5a8ce73adb4146a02
Summary:
This PR solves issue #13618.
Selectable text still behaves the same way:
```jsx
<Text selectable={true}>yo yo yo</Text>
```
Text that is not selectable and has a custom tooltip now do not include the copy item:
```jsx
import * as React from 'react';
import { Text } from 'react-native';
import ToolTip from 'react-native-tooltip';
const MyComponent = () => (
<Text>
<Text>This is my text.</Text>
<ToolTip
actions={[
{text: 'My', onPress: (): any => null },
{text: 'Context', onPress: (): any => null },
{text: 'Menu', onPress: (): any => null },
]}
underlayColor='transparent'
longPress={true}
arrowDirection='down'
>
<Text>You can long press me for a tooltip.</Text>
</ToolTip>
<Text>This is the rest of my text</Text>
</Text>
);
export default MyComponent;
```
Closes https://github.com/facebook/react-native/pull/13619
Reviewed By: shergin
Differential Revision: D4936900
Pulled By: ericvicenti
fbshipit-source-id: 82028b0958c37d63b8a80882196295be4aebecb4
Caleb Meredith
Valentin Shergin
Danil Gontovnik
Hector Ramos
Adlai Holler
Pieter De Baets
Seth Fitzsimmons
Marc Horowitz
Yu Wang
Andrew Imm
Adam Comella
Adam Perry
Eric Vicenti
Gabriel Bull
Andrew Y. Chen
Brian Vaughn
