Summary:
I wrote up a bunch of context for this in response to #27038 by fat. That comment is reproduced here in this commit message. You can see it in it's original contxt here: https://github.com/facebook/react-native/pull/27038
Okay, here is what I think is happening. For context, here is a diagram I have of how focus and blur propagates through the system. This might be interesting to refer back to as you go through the rest of my explanation.
ScrollView's scrollResponder is responsible for blurring text inputs when a touch occurs in the ScrollView but outside of the currently focused TextInput. The code for that is here:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/ScrollResponder.js#L301-L314
This happens on `scrollResponderHandleResponderRelease` aka, touch up.
It checks for what the currently focused textinput is by calling `TextInputState.currentlyFocusedField()`.
That function is a JS variable that is being updated by calls to `TextInputState.focusTextInput` and `TextInputState.blurTextInput`:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInputState.js#L36-L71
I added some console logs to those methods to see which ones are being called when running your repro (thanks for the repro!). **This is without your fix**
Click on and off:
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called
// Click on blank space
scrollResponderHandleResponderRelease blur input1
blurTextInput input1
TextInput's _onBlur called
```
Click on input1, then input 2, then off
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called for input1
// Click on input 2
focusTextInput input2
TextInput's _onBlur called for input1
TextInput's _onFocus called for input2
// Click on blank space
scrollResponderHandleResponderRelease blur input2
blurTextInput input2
TextInput's _onBlur called for input2
```
And now for the bug. Click on input 1, tab to 2, then off
```
// Click on input 1
focusTextInput input1
TextInput's _onFocus called for input1
// Tab to input 2
TextInput's _onBlur called for input1
TextInput's _onFocus called for input2
// Click on blank space
scrollResponderHandleResponderRelease blur input1
blurTextInput input1
```
Notice how `focusTextInput` was never called with input2 in the last example. Since this is the function that sets the `currentlyFocusedField` when we click on the blank space RN is trying to blur the first input instead of the second.
# The root cause
We are tracking the state of which field is focused in JS which has to stay in sync with what native knows is focused. We [listen to _onPress](https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInput.js#L1103-L1107) and call `TextInputState.focusTextInput` in that handler. However, we don't currently have anything listening to other ways for an input to become focused (like tabbing) so it doesn't end up updating the `currentlyFocusedField`.
We have the same problem with blur that we actually fixed the same way you did here in this PR:
https://github.com/facebook/react-native/blob/6ba2769f0f92ca75fb0eb60ccb8337920a9c31eb/Libraries/Components/TextInput/TextInput.js#L1182-L1189
If you look back at my diagram at the beginning of this post, you'll notice the missing edge from `TextInput._onFocus` to `TextInputState.focusTextInput`. That's the problem. :)
The reason this solution works is because this function **is** the notification from native that an input was focused or blurred. This solution is *fine* because this updates the `currentlyFocusedID` but isn't great because it both sets that value and **calls the native code to focus or blur again**. Luckily the native code doesn't send an event back to JS if you try to blur an already blurred TextInput otherwise we'd have an infinite loop.
# The correct solution
The correct thing would probably be to have all of this tracking in native code and not in JavaScript code. That's a pretty big change though and very out of scope. Something for our team to keep in mind for the future.
A short term term solution would be to refactor `focusTextInput` and `blurTextInput` to pull out the part that sets the `currentlyFocusedID` that we could call from `TextInput` directly from `_onFocus` and `_onBlur`.
# ^This short term term solution is what this commit is doing.
Changelog:
[General][Changed] TextInput no longer does an extra round trip to native on focus/blur
Reviewed By: RSNara
Differential Revision: D18278359
fbshipit-source-id: 417566f25075a847b0f4bac2888f92fbac934096
Summary:
This will allow us to catch cases where we use iOS 10-only APIs on iOS 9
Changelog: [Internal]
Reviewed By: TheSavior, mmmulani
Differential Revision: D18275225
fbshipit-source-id: dc9c515415208db40750be997173ce5bd6eb494f
Summary:
This implementation was replaced in January of 2018 by shergin. I believe everyone should have `RCTVirtualText` at this point, which should make this safe to remove.
Changelog:
[Internal][TextInput] Remove deprecated and unused legacyIOS implementation
Reviewed By: shergin
Differential Revision: D18296981
fbshipit-source-id: b5d5756e7bbc8141f1b826ab07c76a781ab03edc
Summary:
This if statement is older than June 2015. This prop is undocumented, not part of the flow type, not on our public docs, not in the flow type, not in typescript types, and I can't find any blog posts about it.
Changelog:
[Breaking][TextInput] Removing undocumented `inputView` prop. Use children instead.
Reviewed By: yungsters
Differential Revision: D18296894
fbshipit-source-id: 95373d24659e6f06e212095b57e8f6d713323c11
Summary:
I've been working on a new iOS experience with lots of text inputs and this has been driving me a bit nuts…
If you're in a scrollview with `keyboardShouldPersistTaps="handled"` and you tab through your text-inputs, you aren't able to tap outside of a given text-input to blur it (and dismiss the keyboard).
I wrote up a quick explanation and some repo steps here: https://snack.expo.io/BJBcKgrqB
The patch i came up with, after poking around for a little bit seems terrifying - so almost certainly not it. But if it's helpful at all - decided to just got ahead and submit it.
## Changelog
[iOS] [Fixed] - TextInput blur when tabbing in iOS simulator.
Pull Request resolved: https://github.com/facebook/react-native/pull/27038
Test Plan:
I tried to think of a way to test this in jest… but i didn't get very far sorry 😢
I did create a snack here so you can demo the issue: https://snack.expo.io/BJBcKgrqB
I also created two videos…
**Here's the text input not working when i try to blur it after tabbing in simulator**
**Here's it working after I applied this patch**
Thanks!
Differential Revision: D18262867
Pulled By: TheSavior
fbshipit-source-id: 4087f3a27a7e6a146f7f84d7c6e9e8e2b6adc75d
Summary:
Deletes the `selectionState` prop from `TextInput`.
It does not provide meaningful value over `onBlur`, `onFocus`, and `selectionState`.
Changelog:
[Breaking][TextInput] Removing `selectionState` prop, use `onBlur`, `onFocus`, and `onUpdate` instead.
Reviewed By: zackargyle, TheSavior
Differential Revision: D17879667
fbshipit-source-id: 03a4e239406932adad898d6d2a092e3bc2e6b064
Summary: Reverts D14176217 so we can do the partial React sync in the next diff which removes this API
Reviewed By: TheSavior
Differential Revision: D17828977
fbshipit-source-id: 7dd98c19890aeee0a153746ce65fd3b148b4ca7b
Summary:
In React Native there are three types of "Native" components.
```
createReactClass with NativeMethodsMixin
```
```
class MyComponent extends ReactNative.NativeComponent
```
```
requireNativeComponent('RCTView')
```
The implementation for how to handle all three of these exists in the React Native Renderer. Refs attached to components created via these methods provide a set of functions such as
```
.measure
.measureInWindow
.measureLayout
.setNativeProps
```
These methods have been used for our core components in the repo to provide a consistent API. Many of the APIs in React Native require a `reactTag` to a host component. This is acquired by calling `findNodeHandle` with any component. `findNodeHandle` works with the first two approaches.
For a lot of our new Fabric APIs, we will require passing a ref to a HostComponent directly instead of relying on `findNodeHandle` to tunnel through the component tree as that behavior isn't safe with React concurrent mode.
The goal of this change is to enable us to differentiate between components created with `requireNativeComponent` and the other types. This will be needed to be able to safely type the new APIs.
For existing components that should support being a host component but need to use some JS behavior in a wrapper, they should use `forwardRef`. The majority of React Native's core components were migrated to use `forwardRef` last year. Components that can't use forwardRef will need to have a method like `getNativeRef()` to get access to the underlying host component ref.
Note, we will need follow up changes as well as changes to the React Renderer in the React repo to fully utilize this new type.
Changelog:
[Internal] Flow type to differentiate between HostComponent and NativeMethodsMixin and NativeComponent
Reviewed By: jbrown215
Differential Revision: D17551089
fbshipit-source-id: 7a30b4bb4323156c0b2465ca41fcd05f4315becf
Summary:
We need to get rid of findNodeHandle calls so migrating scrollResponderScrollNativeHandleToKeyboard to take a ref to a host component.
I made this change with Flow, and tested by rendering UserJobApplicationForm
Reviewed By: mdvacca
Differential Revision: D17099280
fbshipit-source-id: 96af692006aace2c206f268f5416984b00f8a438
Summary:
We added the accessibilityState property as a more semantically rich way for components to describe information about their state to accessibility services. This PR removes the old accessibilityStates property.
<!-- Explain the **motivation** for making this change. What existing problem does the pull request solve? -->
## Changelog
[General] [Change] - Remove accessibilityStates property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26168
Test Plan: Ensure that RNTester accessibility examples function properly on both iOS and Android.
Differential Revision: D17152891
Pulled By: cpojer
fbshipit-source-id: d71d3cf0f2e0846979d2ba104b6c69e4e5725252
Summary: Include AndroidTextInputNativeComponent so we can rely on codegen and flow typing in a future diff.
Reviewed By: TheSavior
Differential Revision: D16903634
fbshipit-source-id: 767d7c854533d641eb7fcb2147bf584621581411
Summary:
The documentation from the Flow types' respective proptypes have been copied over to `TextInput`.
## Changelog
[Internal] [Changed] - Added documentation to TextInput's Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/26054
Test Plan: `yarn flow-check-ios` and `yarn flow-check-android` both pass.
Differential Revision: D16801435
Pulled By: TheSavior
fbshipit-source-id: 7f3d75ba149259d5bbf719375320e2e325188826
Summary:
This pull request moves `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`. This is in line with what is happening with other components.
## Changelog
[General] [Deprecated] - Moved `TextInput`'s proptypes to `DeprecatedTextInputPropTypes`
Pull Request resolved: https://github.com/facebook/react-native/pull/26042
Test Plan: Flow checks pass.
Differential Revision: D16782322
Pulled By: cpojer
fbshipit-source-id: c5f9caa402c0c5cd878e7fff502d380c7b468cbd
Summary:
We are working to remove constants from the view configs.
On June 21st I modified native to support both numbers and strings. D15911323
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D16697916
fbshipit-source-id: f346f37b2e664c2dd49e2a1308a0517f50284e4d
Summary:
On `textContentType` `newPassword` on ios, there is another property called `passwordRules` on ios 12 that can give hints to the os to generate a password with specific requirements like [here](https://developer.apple.com/password-rules/).
This is useful for apps that have a "register" screen with `emailAddress`/`username` and a `newPassword` fields, to let ios make a password that will satisfy the requirements and not one that might be not accepted after the user presses "register".
## Changelog
[iOS] [Added] - PasswordRules for new password textContentType input fields
Pull Request resolved: https://github.com/facebook/react-native/pull/25407
Test Plan: This is a bit harder, but to test you need to make an app that has associated domains with an apple-app-site-association file on that domain, enable iCloud Keychain on the test device, and then iOS will suggest a password, otherwise you will just get a warning on Xcode saying "Couldn't suggest password because of: blabla".
Differential Revision: D16028684
Pulled By: cpojer
fbshipit-source-id: d22426e07f1db45d1f79f5dad81f1465a9701f0b
Summary:
Add prop showSoftInputOnFocus to TextInput. This fixes#14045. This prop can be used to prevent the system keyboard from displaying at all when focusing an input text, for example if a custom keyboard component needs to be displayed instead.
On Android, currently TextInput always open the soft keyboard when focused. This is because `requestFocus` calls `showSoftKeyboard`, which in turn instructs `InputMethodManager` to show the soft keyboard.
Unfortunately even if we were to define a new input type that extends ReactEditText, there is no way to overcome this issue.
This is because `showSoftKeyboard` is a private method so it can't be overriden. And at the same time `requestFocus` needs to invoke `super.requestFocus` to properly instruct Android that the field has gained focused, so overriding `requestFocus` in a subclass of ReactEditText is also not an option, as when invoking `super.requestFocus` we would end up calling again the one defined in ReactEditText.
So currently the only way of doing this is to basically add a listener on the focus event that will close the soft keyboard immediately after. But for a split second it will still be displayed.
The code in the PR changes `requestFocus` to honor showSoftInputOnFocus as defined in Android TextView, displaying the soft keyboard unless instructed otherwise.
## Changelog
[Android] [Added] - Add showSoftInputOnFocus to TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/25028
Differential Revision: D15503070
Pulled By: mdvacca
fbshipit-source-id: db4616fa165643d6ef2b3185008c4d279ae08092
Summary:
As currently defined, accessibilityStates is an array of strings, which represents the state of an object. The array of strings notion doesn't well encapsulate how various states are related, nor enforce any level of correctness.
This PR converts accessibilityStates to an object with a specific definition. So, rather than:
<View
...
accessibilityStates={['unchecked']}>
We have:
<View
accessibilityStates={{'checked': false}}>
And specifically define the checked state to either take a boolean or the "mixed" string (to represent mixed checkboxes).
We feel this API is easier to understand an implement, and provides better semantic definition of the states themselves, and how states are related to one another.
## Changelog
[general] [change] - Convert accessibilityStates to an object instead of an array of strings.
Pull Request resolved: https://github.com/facebook/react-native/pull/24608
Differential Revision: D15467980
Pulled By: cpojer
fbshipit-source-id: f0414c0ef6add3f10f7f551d323d82d978754278
Summary: Allows iOS users to prefil from keyboard if they support safari autofill
Differential Revision: D15385599
fbshipit-source-id: 35d8a7a04c44d23d2aa27dffa02035b68818db7a
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries` have been rewritten to use relative requires with a few exceptions, namely, `vendor` and `Renderer/oss` since those need to be changed upstream. This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
See the umbrella issue at https://github.com/facebook/react-native/issues/24316 for more detail.
[General] [Changed] - Migrate "Libraries" from Haste to standard path-based requires
Pull Request resolved: https://github.com/facebook/react-native/pull/24749
Differential Revision: D15258017
Pulled By: cpojer
fbshipit-source-id: a1f480ea36c05c659b6f37c8f02f6f9216d5a323
Summary:
@public
This bumps Prettier to v1.16.4
Only format source files were updated.
Reviewed By: mjesun
Differential Revision: D14454893
fbshipit-source-id: 72f9872fe764a79dbf0d9fab9bebb1456b039f2f
Summary:
In API 26, autofill framework was introduced in Android.
Read more about Autofill at https://developer.android.com/guide/topics/text/autofill.
Now, if in case for some text input if developer wants to disable
autofill then he can take help from this `importantForAutoFill` prop
and pass `no` to it.
Also important of auto fill can be configured with this prop, like:
* `auto`: Let the Android System use its heuristics to determine if the view is important for autofill.
* `no`: This view isn't important for autofill.
* `noExcludeDescendants`: This view and its children aren't important for autofill.
* `yes`: This view is important for autofill.
* `yesExcludeDescendants`: This view is important for autofill, but its children aren't important for autofill.
Default value if `auto`.
Read more at: https://developer.android.com/guide/topics/text/autofill-optimize
Changelog:
----------
[Android] [Added] - Add prop to configure `importantForAutofill` in `TextInput`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22763
Differential Revision: D14121242
Pulled By: cpojer
fbshipit-source-id: aa4360480dd19f6dde66f0409d26a41a6a318c94
Summary:
TL;DR: Setting `autoComplete` will allow the system to suggest autofill options for the `<TextInput>` component.
Android Oreo introduced the AutoFill Framework, for secure communication between an app and autofill services (e.g. Password managers). When using `<TextInput>` on Android Oreo+, the system already tries to autofill (based on heuristics), but there is no way to set configuring options or disable.
The quick solution would be to just add the same Android attributes (`autofillHints` & `importantForAutofill`) in React Native TextInput, but that doesn't bond well with the cross-platform nature of the library.
Introduces an `autoComplete` prop based on HTML's `autocomplete` attribute, mapping to Android `autofillHints` & `importantForAutofill` and serving as a proper placeholder for autofill/autocomplete in other platforms:
Also gives you the ability to disable autofill by setting autocomplete="off".
Pull Request resolved: https://github.com/facebook/react-native/pull/21575
Differential Revision: D14102949
Pulled By: hramos
fbshipit-source-id: 7601aeaca0332a1f3ce8da8020dba037b700853a
Summary:
This is a new attempt to get #11251 merged. I just cherry-picked the relevant commits. TextInputs are set to always ignore responder termination requests, which is not desirable when they are enclosed inside a swipeable area like a ListView
Create a TextInput inside a ListView and set the `rejectResponderTermination` prop to false. Otherwise, all TextInputs should have the same behavior they do now.
[IOS] [ENHANCEMENT] [TextInput] - Add `rejectResponderTermination` prop to to TextInput. This enables TextInputs inside Swipeables to function properly.
Pull Request resolved: https://github.com/facebook/react-native/pull/16755
Differential Revision: D7846365
Pulled By: cpojer
fbshipit-source-id: eb21140061ae1f475fbd83fc63a23819e931787d
Summary: In D13408886, I landed a PR that broke the `autoFocus` prop. This diff fixes this prop by partially reveting some of the changes in that diff.
Reviewed By: TheSavior
Differential Revision: D13611258
fbshipit-source-id: 225b9b59b2500cfac092f13c273685aaeb599ab0
Summary:
This removes the use of the legacy context API in `TextInput`.
Nothing in OSS appears to make use of the `focusEmitter`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22220
Reviewed By: TheSavior
Differential Revision: D13408886
Pulled By: RSNara
fbshipit-source-id: 9ae597507ccc26a9bc944a44c1f51b91e73cd637
Summary:
Similar to what was done here https://github.com/facebook/react-native/pull/22376
This allows using things like async functions with text input event props.
Changelog:
----------
[General] [Fixed] - Make TextInput event prop types less strict
Pull Request resolved: https://github.com/facebook/react-native/pull/22673
Reviewed By: TheSavior
Differential Revision: D13492029
Pulled By: hramos
fbshipit-source-id: 84e1a776a7ac1ae7567fbf4105b2be9be330610e
Summary: This is one more step to remove `fbjs` from `react-native-github`. This changes both the internal and external code to use `invariant` from zertosh instead of the copy in fbjs.
Reviewed By: yungsters
Differential Revision: D13195941
fbshipit-source-id: 73564ca1715110e7da9c7ef56dc57374d61377e0
Summary:
Some of the flow types were incomplete. So, I referenced the code in `~/fbsource/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/views/textinput/` and in `~/fbsource/xplat/js/react-native-github/Libraries/Text/TextInput/` to make the flow types more specific.
I also fixed internal breakages. To avoid having to sprinkle `$FlowFixMe`s everywhere, I had to refactor some types, and some code.
Reviewed By: TheSavior
Differential Revision: D13121871
fbshipit-source-id: 9796aafc861544baf52d7ade823ab1be2d3f12d1
Summary:
Related to #22100
Enhance TextInput with callback event types.
This is a first draft and I will need more help on this one. Flow checks are successful now but I am not sure types are accurate though.
Moreover I find my separation approach kind of dirty for callback event types.
- All flow tests succeed.
[GENERAL] [ENHANCEMENT] [TextInput.js] - Flow types
[GENERAL] [ENHANCEMENT] [TextInputExample.android.js] - Fixing Flow types
[GENERAL] [ENHANCEMENT] [TextInputExample.ios.js] - Fixing Flow types
[GENERAL] [ENHANCEMENT] [XHRExampleFetch.js] - Fixing Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/22250
Reviewed By: TheSavior
Differential Revision: D13104820
Pulled By: RSNara
fbshipit-source-id: 3fbb98d0ec2b62be676f71ae1053933d9c78485e
Summary:
I noticed that the _onBlur method was not exactly similar to the _onFocus one in the TextInput component.
After digging, I found that the blurTextInput method in the TextInputState.js file was call twice in a raw instead of once when the textinput component should blur.
By removing this line, I fix this unecessary multiple call.
Pull Request resolved: https://github.com/facebook/react-native/pull/22156
Reviewed By: TheSavior
Differential Revision: D13105396
Pulled By: RSNara
fbshipit-source-id: 8e83461d8b288d8ee4047bc4a33c4480e193c349
Summary:
Back it out again. This time really not sure why this is breaking, but it seems to be production only. The error seems to be "RCTSinglelineTextInputView" was not found in the UIManager" but the relavent logic is not changed in this diff, just moved around, so unclear why it would trigger a failure.
Reverting to be safe. When we re-apply the diff, we'll need to test a full OTA to prod to verify the fix.
Reviewed By: blairvanderhoof
Differential Revision: D13108463
fbshipit-source-id: 5f877a0c1a08dc114ce45921d6d92bf619575977
Summary: D10515754 reapplied by backing out D12989604 and then fixed by manually forwarding the instance methods to the host function instead of using `forwardRef`. This also removes the need for the $flowFixMe.
Reviewed By: TheSavior
Differential Revision: D13048482
fbshipit-source-id: ff2447aff123e0960eddaef645f7dc976a426e14
Summary: Adds a basic test that would have prevented S168585. We should expand coverage of this and other components as well.
Reviewed By: TheSavior
Differential Revision: D13038064
fbshipit-source-id: 14cf4742efd53d7bca2a3f8d1c5c34ebc6227674
Summary:
This was failing due to issues with refs, which we were able to fix and then finally due to some jest tests that were failing due to things being null that shouldn't be which I couldn't easily figure out. Reverting the stack until we can actually solve it, hopefully with additional tests.
This was created by running:
```
$ hg backout c2fe2c46e538
fetching tree '' b9bbfc1925c6daf85ba3227d12f177aca9c0c054, based on 4257c76aefa84aaa17279e65aa7ca1174f4401e7, found via 02368b670953
connected to hg015.frc2.facebook.com
60 trees fetched over 2.91s
fetching tree '' c3c304df13399f0f1a29a668242da454fc1d8a97, based on b9bbfc1925c6daf85ba3227d12f177aca9c0c054, found via c2fe2c46e538
7 trees fetched over 0.03s
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
commit 4270328:50a65c5c2e27 backs out commit 4266783:c2fe2c46e538
1 files fetched over 1 fetches - (1 misses, 0.00% hit ratio) over 0.57s
[twsvcscm@sandcastle3265.ftw1 /data/sandcastle/boxes/instance-ide/xplat/js (50a65c5)]$ hg backout 02368b670953
fetching tree '' a46c8ca065f5b92cf375d7ed899fc5ca268ba4da, based on b9bbfc1925c6daf85ba3227d12f177aca9c0c054, found via bade4285eafb
connected to hg024.frc2.facebook.com
27 trees fetched over 3.21s
fetching tree '' 361548a090e81d18bab6f4fc16036c518cb4d7c1, based on a46c8ca065f5b92cf375d7ed899fc5ca268ba4da, found via bade4285eafb
41 trees fetched over 0.10s
merging react-native-github/Libraries/Components/TextInput/TextInput.js
8 files updated, 1 files merged, 0 files removed, 0 files unresolved
commit 4270329:dbaca0daf0ac backs out commit 4266782:02368b670953
14 files fetched over 7 fetches - (14 misses, 0.00% hit ratio) over 1.72s
[twsvcscm@sandcastle3265.ftw1 /data/sandcastle/boxes/instance-ide/xplat/js (dbaca0d)]$ hg backout bade4285eafb
connected to hg030.frc2.facebook.com
fetching tree '' 1b4a17164fdbfcad40139e46da4a9bfa8aa8def3, based on 361548a090e81d18bab6f4fc16036c518cb4d7c1, found via 5cfb25344385
7 trees fetched over 0.06s
merging react-native-github/Libraries/Components/TextInput/TextInput.js
20 files updated, 1 files merged, 0 files removed, 0 files unresolved
commit 4270330:2951740e5b32 backs out commit 4266781:bade4285eafb
33 files fetched over 14 fetches - (33 misses, 0.00% hit ratio) over 4.50s
[twsvcscm@sandcastle3265.ftw1 /data/sandcastle/boxes/instance-ide/xplat/js (2951740)]$ hg backout 5cfb25344385
connected to hg035.frc2.facebook.com
merging react-native-github/Libraries/Components/TextInput/TextInput.js
0 files updated, 1 files merged, 2 files removed, 0 files unresolved
commit 4270331:fffb4629a397 backs out commit 4266780:5cfb25344385
1 files fetched over 1 fetches - (1 misses, 0.00% hit ratio) over 4.03s
```
Reviewed By: yungsters
Differential Revision: D12989604
fbshipit-source-id: 703a7c9c1f5bdd710077e515bdff06fdb34502ec
Summary:
Types were moved out of TextInput into TextInputTypes for better re-use. Fixing the internal callsites.
This isn't much of a worry externally because these types aren't exposed as part of the public API
Reviewed By: RSNara
Differential Revision: D10517066
fbshipit-source-id: bade4285eafb3d7ab5ab1e4b0730c22d45925509
Summary:
This pull requests converts `TextInput` to an ES6 class, and in the process removes its usage of `prop-types` and `NativeMethodsMixin`.
The code (and some relevant types) for the native components have been moved to `TextInputNativeComponent.js`.
The rest of the flow proptypes have been moved to `TextInputTypes.js`.
Pull Request resolved: https://github.com/facebook/react-native/pull/21885
Reviewed By: RSNara
Differential Revision: D10515754
Pulled By: TheSavior
fbshipit-source-id: 5cfb25344385904b37a49582008c2a4b46db809d
Summary: Replaced each view manager access with a getViewManager() function call. This will later be used to lazily load view manager classes by allowing java to avoid sending the entire list of view managers to JS.
Reviewed By: QueryConnectionException
Differential Revision: D9695788
fbshipit-source-id: 949858aa2f0b0b00b68e260461ba8f1d085cf07f
Summary:
This PR is the result of running `yarn prettify` on the codebase - which caught a few files that were not prettified. This will make instructing people to run prettify a bit less complicated, since unrelated files will not show up in diffs.
Pull Request resolved: https://github.com/facebook/react-native/pull/21327
Differential Revision: D10046057
Pulled By: TheSavior
fbshipit-source-id: 2c771a3c758c72816c707e32ee2f4587e466f277
Summary:
This flow type is wrong, probably just a copy paste mistake.
Pull Request resolved: https://github.com/facebook/react-native/pull/21271
Differential Revision: D10006741
Pulled By: TheSavior
fbshipit-source-id: eba0116ec39ba00f000d9bf789ae9214990355a1
Summary:
Adding the new `textContentType` options from iOS 12. `newPassword` helps the OS know to put a password field into the keychain, and `oneTimeCode` hints that the field will take input from an SMS one time code.
Pull Request resolved: https://github.com/facebook/react-native/pull/21079
Differential Revision: D9813328
Pulled By: TheSavior
fbshipit-source-id: d2c04b41121b32f185af38ea4c642924e261a043
Eli White
Samuel Susla
Jacob Thornton
Andres Suarez
Tim Yung
Rick Hanlon
vasilich
Marc Mulcahy
Joshua Gross
empyrical
Pavlos Vinieratos
valerio.ponte
Shen Jin
James Ide
Peter van der Zee
Vishwesh Jainkuniya
Daniel Sainati
Cassio Zen
Connor McEwen
Ramanpreet Nara
Janic Duplessis
Christoph Nakazawa
Thomas BARRAS
gazoudoudou
Spencer Ahrens
Richard Cann
nd-02110114
Andrew Chen (Eng)
Chris Williams
