Summary:
Allow JS to keep track of mostRecentEventCount and pass it into each event or prop update. We really don't want to separately keep track of that data.
In non-Fabric, the ShadowNode will keep track of the mostRecentEventCount associated to prop updates. In Fabric, that happens on the C++ ShadowNode.
Changelog: [Internal] Simplification to TextInput native state
Reviewed By: mdvacca
Differential Revision: D20374573
fbshipit-source-id: 385fba6ec69a071c78832a686b397699a6c55d67
Summary:
See D19204032. In some cases the View might not have a ThemedReactContext, it may be wrapped, so we use a previously-created helper to get the correct context from the View or we throw a soft exception.
Changelog: [Internal] Fabric change
Reviewed By: mdvacca
Differential Revision: D20355126
fbshipit-source-id: 469a3b7f8f2d3b98236f3170dd62c4a6e7e1e46f
Summary:
Work around crash in Android TextInput when default colors are null.
This likely indicates that the Context is corrupted in some way, so this is not a permanent solution.
Changelog: [Internal] Raise soft exception is default platform text color isn't defined
Reviewed By: mdvacca
Differential Revision: D20351080
fbshipit-source-id: d912c9348272c2f3a3b8d571d465d482060efe5a
Summary:
Fixed some typos in the comment.
## Changelog
[Internal] [Fixed] - Fixed typo in the comments
Pull Request resolved: https://github.com/facebook/react-native/pull/28269
Test Plan: Changes are only made in the comments, so test is not necessary.
Reviewed By: cpojer
Differential Revision: D20342637
Pulled By: shergin
fbshipit-source-id: f6e7dd538ee54c43e1570c35e1f8c4502054e328
Summary:
This diff fixes the rendering of the TextInput RNTester examples in catalyst app.
The root cause of the bug is that we were parsing the props of the text using the TextAttributeProps class, this is incorrect because TextAttributeProps is a holder of the C++ TextAttributes and not TextProps, but the name is confusing.
As a consecuence there was some mistmaches of types during parsing and that was throwing an exception in some examples.
I created the task T63643819 to refactor these classes to make this cleaner.
I'll be working on T63643819 next week, now I want to unblock this bug.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D20320969
fbshipit-source-id: 7b47546ba4f34df2a7fa151ab200823ea2eeb696
Summary:
On Android, when changing the props on TextInput component, there are cases where behavior is incorrect.
ex: there were two other PR requests to fix the following issues:
1) TextInput doesnt respect the autoCapitalize prop when keyboardType is set to "default"
2) Password visibility is broken
But those PRs ended up breaking a transition from phone-pad to default
Root cause
- The issue is that the bits that Android defines to store the InputType flags are reused.
- For example, the previous issue: TYPE_TEXT_FLAG_CAP_WORDS and TYPE_NUMBER_FLAG_DECIMAL are both using 0x00002000 bit. So when switching input types from phone-pad to default (text), it is not known if this bit should be cleared. It could have been set for capitalize or for indicating the num pad should be generic.
the solution is to always unset the TYPE_CLASS flags before setting the keyboardType so the user has the correct keyboard.
Changelog: [Fixed] TextInput transition from phone-pad to default
Reviewed By: JoshuaGross
Differential Revision: D20263334
fbshipit-source-id: 0b283fbd6314bf10b90f760917447d2439aaa147
Summary:
For backwards-compatibility with Paper, we're implementing a feature in Fabric that will allow TextInputs to use the default padding from the theme in Android.
Note that this uses some pretty ugly hacks that probably shouldn't be used inside of components at all: looking directly at rawProps, overriding props/Yoga styles in the component descriptor, etc. I would (personally) really like to kill this feature entirely unless and until we can find a more elegant solution.
Changelog: [Internal]
TextInputs are still not pixel-perfect with Paper, but they're much closer, and the underline visual glitchiness is no longer an issue.
Reviewed By: mdvacca
Differential Revision: D20109605
fbshipit-source-id: 543282843e0a9f03a504d72d7a014431099bd64c
Summary:
Right now, `requestFocus()` is a no-op if the EditText view thinks it's already focused. In certain cases, though, we still want to focus the view even if it's already focused - for example, if TalkBack is enabled and you dismiss the keyboard, you want to be able to tap on the TextInput again to bring back the keyboard, even though the View never thinks it lost focus.
What I'm doing instead is basically disregarding the View's current focus state if we *would* focus the TextInput, which is in 3 circumstances:
- When the view is attached to a window, if autofocus is true
- When the focus is being requested by JS
- When the focus is being requested by an accessibility action from the OS
Changelog: [Android][Fixed] Change how TextInput responds to requestFocus to fix a11y focus issue
Reviewed By: mdvacca
Differential Revision: D19750312
fbshipit-source-id: 30b9fab40af4a083fa98f57aba7e586540238bea
Summary:
This diff refactors Text and Text input components in Fabric to support customizable emojis
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D19679391
fbshipit-source-id: 358aa97064209d28d317ba4ca5fff84245c9b1bb
Summary:
Follow up to https://github.com/facebook/react-native/issues/27803. To keep consistency between the implementations this also implements autoFocus natively on Android. This will allow removing the JS auto focus logic completely.
## Changelog
[Android] [Fixed] - Implement native TextInput autoFocus on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27924
Test Plan: Test using the TextInput example in RN tester.
Differential Revision: D19674506
Pulled By: TheSavior
fbshipit-source-id: 9cbb517fc69bccd11f5292a1ccb4acea2e3713e9
Summary: Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Reviewed By: mdvacca
Differential Revision: D19614184
fbshipit-source-id: 5dd4945223d10785f8fe171e06d6f7ef42f9d834
Summary:
Migrate ReactTextinputManager to support bridgeless mode by accessing the EventDispatcher through the UIManagerHelper instead of from ReactContext.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19456326
fbshipit-source-id: 5e9643793cd764e29964f565db24cdea683ac032
Summary:
We should have been calling this already. Trivial fix. The intent of the view command was always to update selection, I just forgot to add it. See test videos.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D19548178
fbshipit-source-id: 14a1bdc11d84c05f2435c48c3bb96b64e8c68cb4
Summary:
A previous PR broke toggling between visible and non-visible password (basically once a password field was made visible, future updates to the keyboardType were effectively ignored, so the password would always be visible).
Original PR: https://github.com/facebook/react-native/pull/27523
Changelog: [Internal]
Reviewed By: mdvacca, rodrigos-facebook
Differential Revision: D19527245
fbshipit-source-id: a5ab343c8a0c6a608171dbfa5afc7536ff241826
Summary:
This PR makes it possible for subclasses of `ReactTextInputShadowNode` to control the construction of the "dummy" `EditText` instance that `ReactTextInputShadowNode` internally uses to determine the expected height of the view. This PR does not change the default behavior, it just opens up that default to being overriden.
This is useful in the case of custom views that have different behavior from a "default" `EditText` instance (`new EditText(context)`). For example, it might have a different style applied.
As a side benefit, this change also makes it easy to have subclasses not apply the default theme, which can allow the custom view to avoid a longstanding crash issue (https://github.com/facebook/react-native/issues/17530).
## Changelog
[Android] [Added] - Allow overriding `EditText` construction in `ReactTextInputShadowNode`
Pull Request resolved: https://github.com/facebook/react-native/pull/27782
Test Plan: All tests pass.
Reviewed By: mdvacca
Differential Revision: D19450593
Pulled By: JoshuaGross
fbshipit-source-id: 8d2ce6117246fc3e2108623312b38583af5722b3
Summary:
Fix for https://github.com/facebook/react-native/issues/27510.
Setting the `InputType.TYPE_CLASS_TEXT` flag when `keyboardType` is null or default breaks autoCapitalize. Handle the case when `keyboardType` is null, default, or invalid type.
## Changelog
[Android] [Fixed] - Fix setting keyboardType from breaking autoCapitalize
Pull Request resolved: https://github.com/facebook/react-native/pull/27523
Test Plan:
Added keyboardType prop to RNTester as so
```
<TextInput autoCapitalize="words" keyboardType="default" style={styles.default} />
```
Reviewed By: makovkastar
Differential Revision: D19132261
Pulled By: JoshuaGross
fbshipit-source-id: be66f0317ed305425ebcff32046ad4bff06d367f
Summary:
This diff fixes the rendering of TextInput component for Android 4 devices.
This bug was caused by D18196901, when we changed the base class of ReactEditText from EditText to AppCompatEditText.
The root of the problem is that AppCompatEditText wraps the ReactContext received as a parameter in the construction of the View into a ContextWrapper object. This break the implicity assumption that the method View.getContext will return the same context that was used during the construction of the view.
https://android.googlesource.com/platform/frameworks/support/+/dd55716/v7/appcompat/src/android/support/v7/widget/AppCompatEditText.java#55
Changelog: [internal]
Reviewed By: ejanzer
Differential Revision: D19204032
fbshipit-source-id: eefb562b1da22e6cc58c75845c87dd032d727f49
Summary:
Google recommends to extend AppCompat widgets, and Android Studio suggests the change. This PR changes ReactEditText to extend AppCompatEditText.
## Changelog
[Android] [Changed] - ReactEditText extends AppCompatEditText
Pull Request resolved: https://github.com/facebook/react-native/pull/27039
Test Plan: CI is green
Reviewed By: mdvacca
Differential Revision: D18196901
Pulled By: hramos
fbshipit-source-id: 1484ae3da1be5776d0431dab3d4bb7ddbe5b8b7c
Summary:
UpdateLocalData and UpdateState return an `extra data` object, which in the case of TextInput contains padding. In Paper, the padding was always set on this object; in Fabric, it generally is not. However, the ViewManager was unconditionally setting the padding on the view, regardless of whether or not padding was set. We just check the padding values before setting now. This fixes an issue where the padding would be reset when the user started typing in Fabric.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18875261
fbshipit-source-id: d7cb87c07f47ab522e32cd34a4ca6ed5fea2e832
Summary:
In Paper this call causes Yoga to remeasure the tree. We don't need to do this in Fabric, and all the data contained in `ReactTextInputLocalData` is already set on the underlying EditText View.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18870491
fbshipit-source-id: a982a708b810d45f70ad4981a963bb4ae798c83c
Summary:
When the TextInput is updated on the Java side, make sure C++ State gets updated. We do this by making sure that the AttributedString data-structured in mirrored in Java and in C++.
In practice, the AttributedString is copied into Java a few times during initialization, and then after then, 99% of the time Java is writing without receiving updates from C++. This means that we should optimize the Java-to-C++ update path most aggressively in the future.
However, it turns out that for now, at least, we can't reuse NativeWritableMaps/NativeWritableArrays because they're consumed on the C++ side and can't be modified after that. This is a perf improvement for the future.
This allows us the user to edit any fragments, and the changes will flow through C++ State. This also allows us to edit across multiple Fragments.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18785960
fbshipit-source-id: 97b283ec411081eca4d2d7a4cce2b31b5e237c42
Summary:
Fix and simplify `AndroidTextInputShadowNode::getAttributedString` so that it (1) works, and (2) is aligned with the equivalents in the old Java code.
The issue is that we weren't picking up `text` attributes since we're only traversing children and not the TextInput node itself. If a `text` attribute is present it needs to be treated as its own Text node.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739830
fbshipit-source-id: 4b3bc81dbe8c241c2e06fe5be1f9b50e49132890
Summary:
In AndroidTextInput, support codegen'd ViewCommands in native and add three commands that will eventually replace usage of setNativeProps on Android.
TextInput will use these commands in a future diff.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18612150
fbshipit-source-id: 5d427040686e8c5ab504dd845bc8ef863f558c35
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
Summary:
This PR https://github.com/facebook/react-native/pull/22723 cached selections, so if you had a cached selection indicies, but updated the text to be an empty string, then this would crash.
As reported in https://github.com/facebook/react-native/issues/25265 and other issues of `setSpan(4 ... 4) ends beyond length`
## Changelog
[Android] [fixed] - Crash in TextInput
Pull Request resolved: https://github.com/facebook/react-native/pull/26680
Test Plan:
```
input.setNativeProps({ text: "xxx", selection: {"begin": 0, "end": 3}});
input.setNativeProps({ text: ""});
```
Differential Revision: D18189703
Pulled By: cpojer
fbshipit-source-id: 67d9615a863fd22598be8d6d4553dec5ac8837ed
Summary: This diff fixes the issue with view paddings in Fabric introduced in D17081799. In Paper setting padding on a view was only supported for Text and TextInput components (see https://fburl.com/codesearch/6r6lu5vd). We want to keep Fabric backwards compatible, so we delegate setting the padding to the view manager instead of setting it directly on the view. In this way we can have a no-op implementation in the base view manager and implement this method only in view managers that support setting padding (ReactTextInputManager and ReactTextViewManager at the moment).
Reviewed By: JoshuaGross
Differential Revision: D17665011
fbshipit-source-id: 38bc56278e002bd34881cfcb9ed79df579f79e28
Summary:
When using a medium (500) font weight on Android the wrong weight is used for the placeholder and for the first few seconds of input (before it gets text back from JS). To fix it I refactored the way we handle text styles (family, weight, style) to create a typeface to be more like the `Text` component.
Since all these 3 props are linked and used to create the typeface object it makes more sense to do it at the end of setting props instead of in each prop handler and trying to recreate the object without losing styles set by other prop handlers. Do do that we now store fontFamily, fontStyle and fontWeight as ivar of the ReactEditText class. At the end of updating prop if any of those changed we recreate the typeface object.
This doesn't actually fix the bug but was a first step towards it. There were a bunch of TODOs in the code to remove duplication between `Text` and `TextInput` for parsing and creating the typeface object. To do that I simply moved the code to util functions in a static class. Once the duplication was removed the bug was fixed! I assume proper support for medium font weights was added for `Text` but not in the duplicated code for `TextInput`.
## Changelog
[Android] [Fixed] - Fix medium font weights for TextInput on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26434
Test Plan:
Tested in my app and in RNTester that custom styles for both text and textinput all seem to work.
Repro in RNTester:
```js
function Bug() {
const [value, setValue] = React.useState('');
return (
<TextInput
style={[
styles.singleLine,
{fontFamily: 'sans-serif', fontWeight: '500', fontSize: 32},
]}
placeholder="Sans-Serif 500"
value={value}
onChangeText={setValue}
/>
);
}
```
Before:
After:
Reviewed By: mmmulani
Differential Revision: D17468825
Pulled By: JoshuaGross
fbshipit-source-id: bc2219facb94668551a06a68b0ee4690e5474d40
Summary: Today, View Managers are all initialized as soon as we start up the app. Making them lazy, so that we only intantiate them when they are really needed
Differential Revision: D17329940
fbshipit-source-id: 821bf121f04d58c7b871c7923fed81d8c735f8b4
Summary: Support existing, backwards-compatible AndroidTextInput component for minimal support of TextInput on Android.
Reviewed By: shergin, mdvacca
Differential Revision: D17086758
fbshipit-source-id: 25726f22229e0d5dfe96eb36b386a5317601283d
Summary:
Changing showSoftKeyboard and hideSoftKeyboard to be protected, as we need this change for an internal control that extends ReactEditText.
## Changelog
[Android] [Changed] - part of our react native platform, we have a control that extends ReactEditText and we need to be able to override these 2 methods.
Pull Request resolved: https://github.com/facebook/react-native/pull/25964
Test Plan: The change has been in Microsoft's branch of RN for almost 2 years, and since it's a relatively small change we've done a quick sanity check in RNTester prior to this PR, making sure the TextInput page loads fine and it's functional.
Differential Revision: D16686878
Pulled By: cpojer
fbshipit-source-id: 63035ee9c58e93bc0fa40e5bec318df05322c6c5
Summary:
I believe there's a mismatch between the type definitions and the expected prop in Android for `TextInput`'s `autoComplete` prop.
* Android is expecting `autoComplete`.
* JS types are expecting `autoCompleteType`.
* Latest documentation documents `autoCompleteType`.
Prop added here: https://github.com/facebook/react-native/commit/179d490607620a988a53aacb01031ed300d4ac66
This change updates the JS types to match what Android is expecting (`autoComplete`). Can update documentation if this is the approach we'd prefer (rather than updating Android to expect `autoCompleteType`).
## Changelog
[Javascript] [Fixed] - Update types for `TextInput`'s `autoComplete` prop.
Pull Request resolved: https://github.com/facebook/react-native/pull/25549
Test Plan:
Before:
* Pass invalid value to `TextInput`'s `autoComplete` prop, see no type errors on JS side, and Android blows up with:
```sh
Invalid autocomplete option: foobar
updateViewProp
ViewManagersPropertyCache.java:95
setProperty
ViewManagerPropertyUpdater.java:132
updateProps
ViewManagerPropertyUpdater.java:51
updateProperties
ViewManager.java:37
```
After:
* Pass invalid value to `TextInput`'s `autoComplete` prop, see PropType warning for `autoComplete` prop.
Differential Revision: D16220809
Pulled By: mdvacca
fbshipit-source-id: e25e198cbcbe721c8d71f069bba293856bf5f36d
Summary:
This diff migrates the usages Nullable and NonNull annotations to AndroidX instead of javax.
The purpose of this change is to bring consistency in the annotations used by the core of RN
Reviewed By: makovkastar
Differential Revision: D16054504
fbshipit-source-id: 21d888854da088d2a14615a90d4dc058e5286b91
Summary:
This diff fixes a crash caused by an IllegalStateException thrown from the `TextView.onEditorAction()`. This could happen if we don't return false from the `OnEditorActionListener.onEditorAction()` and Android will fallback to the default behaviour, which will try to search and focus the next/previous view in case of `EditorInfo.IME_ACTION_NEXT` or `EditorInfo.IME_ACTION_PREVIOUS` accordingly. Because ReactEditText prevents requesting focus from Android (`ReactEditText.requestFocus()` returns false), the following piece of code from `TextView.onEditorAction()` will crash the app:
```
} else if (actionCode == EditorInfo.IME_ACTION_PREVIOUS) {
View v = focusSearch(FOCUS_BACKWARD);
if (v != null) {
if (!v.requestFocus(FOCUS_BACKWARD)) {
throw new IllegalStateException("focus search returned a view "
+ "that wasn't able to take focus!");
}
}
return;
} else if (actionCode == EditorInfo.IME_ACTION_DONE) {
InputMethodManager imm = InputMethodManager.peekInstance();
if (imm != null && imm.isActive(this)) {
imm.hideSoftInputFromWindow(getWindowToken(), 0);
}
return;
}
```
To prevent this we have to catch `EditorInfo.IME_ACTION_NEXT` and `EditorInfo.IME_ACTION_PREVIOUS` inside `OnEditorActionListener.onEditorAction()` and prevent the default Android behaviour.
Reviewed By: mdvacca
Differential Revision: D16180306
fbshipit-source-id: 6118257c16a7a4a205ae05da671cd76d3a18d565
Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary:
Similar to D15909582, this change makes the Android TextInput take strings for the value of autoCapitalize and not just numbers. As we are going to stop sending view configs from native and instead hardcode them in JS we can't do that anymore.
In this commit we are supporting the old style as well as the new style.
Changelog:
[Android] [Internal] - Supporting autoCapitalize as string to clean up internal TextInput.js file
Reviewed By: mdvacca
Differential Revision: D15911323
fbshipit-source-id: b236fdb314489cc1ef33f9214ff2d6b0e28b7310
Summary:
There's an issue with TextInput on Android where if you have TalkBack enabled, double tapping doesn't focus the text input. It turns out this is because we ignore all focus events that aren't from JS in ReactEditText. This diff makes an exception for the accessibility click event.
I think this should also fix https://github.com/facebook/react-native/issues/17624
Reviewed By: lunaleaps
Differential Revision: D15818103
fbshipit-source-id: 354728b58f1023c4d44edd48337c8daa8ea15c0c
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:
We're working on a custom EditText that supports some rich text editing, and one of the places where our logic has to be different from the textinput provided by RN is the text setting logic:
https://github.com/facebook/react-native/blob/7abfd23b90db08b426c3c91b0cb6d01d161a9b9e/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactEditText.java#L377
However, some of the important members are private and our subclass cannot access them (we work around this now with reflection). It would be nice if we could work with them directly, either using getters and setters or by changing the access. Let me know what you think about this. Thanks.
## Changelog
[Android] [Added] - allow custom maybeSetText logic for ReactEditText subclasses
Pull Request resolved: https://github.com/facebook/react-native/pull/24927
Differential Revision: D15431682
Pulled By: cpojer
fbshipit-source-id: 91860cadac0798a101ff7df6f6b868f3980ba9b1
Summary:
Resolve#24690
This is very simple unicode detecting. Should I improve this solution creating StringsUtils for detecting unicodes in whole react-native project ?
[Android][Fixed] onKeyPress method is calling, when user type emoji
Pull Request resolved: https://github.com/facebook/react-native/pull/24717
Differential Revision: D15238388
Pulled By: cpojer
fbshipit-source-id: 038b1040e1c44fd6f9401a3988a782f5778e1209
Héctor Ramos
Joshua Gross
Jesse Katsumata
David Vacca
Michael Yoon (LAX)
Emily Janzer
Janic Duplessis
Rick Ratmansky
Matt Chowning
Jason Safaiyeh
Dulmandakh
Marco Munizaga
Andres Suarez
Oleksandr Melnykov
Ram N
Onti Vals
Dan Gilbert
Eli White
Emily Janzer
valerio.ponte
Vojtech Novak
Uilque Messias
Piotr Trocki
