[Android] Improve consistency for overflowed TextInput

[redstar504]

Summary

The purpose of this PR is to improve consistency in the behavior of overflowed TextInput components across supported platforms.

Currently on Android, when a TextInput is rendered with a value that overflows the width of the TextInput, Android Native displays the end of the text line. Other platforms display the start and clip the end. This also applies to setting text programatically (ie. by setting the value through state for an unfocused TextInput).

This PR aims to normalize the behavior by updating the Android Native implementation to display the start of the line and clip the end, bringing it in line with the behavior of other platforms.

To achieve this, we can invoke scrollTo in the afterChangedText event using the existing TextWatcher for detecting text changes for the Android widget. To ensure this only applies to initial rendering and auto-filling, we condition on the field being unfocused. When the field is focused, the behaviour will not apply and therefore not effect regular keyboarding events.

This problem was discussed more thoroughly in the longstanding issue here: #14845

Changelog

[ANDROID] [Fixed] - TextInput not displaying start of text on render like other platforms

Test Plan

My submitted solution includes an example within the rn-tester package. Below I will provide videos displaying the behaviour both there, and within our production app where the issue was identified.

Before Change (RNTester)

fb-text-render-before-change.mp4

After Change (RNTester)

fb-text-render-after-change.mp4

Before Change (Production app)

ex-platform-test-before.mp4

After Change (Production app)

ex-platform-test-after.mp4

[facebook-github-bot]

Hi @redstar504!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,515,900	-45
android	hermes	armeabi-v7a	7,831,786	+71
android	hermes	x86	8,996,223	+77
android	hermes	x86_64	8,851,698	+134
android	jsc	arm64-v8a	9,140,207	-474
android	jsc	armeabi-v7a	8,331,809	-366
android	jsc	x86	9,195,180	-343
android	jsc	x86_64	9,453,282	-295

Base commit: e26092a
Branch: main

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Meta Open Source project. Thanks!

[facebook-github-bot]

@ryancat has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator.

[NickGerleman]

Do we know what React Native is doing to move selection in the first place, if this doesn't happen on stock Android? #14845 (comment)

Re-scrolling the text every time it is edited seems pretty broad. It would be better to understand where the behavior comes from instead.

[redstar504]

@NickGerleman Thank you for your comment. After further investigation, I have found that the issue is definitely caused on the RN side, due to the selection being manipulated during text updates:

react-native/ReactAndroid/src/main/java/com/facebook/react/views/textinput/ReactTextInputManager.java

Line 386 in cbe934b

view.maybeSetSelection(update.getJsEventCounter(), selectionStart, selectionEnd);

This method is always called with the text length for both arguments, effectively clamping the cursor at the end of the field. This does not occur on vanilla Android native, but it seems logical to place the cursor at the end when subsequently pressing on the field. It does however carry the side effect of scrolling to the end of the field.

While both scrolling and selection can act independently (i.e., we can set the selection to the end, and scroll to the beginning), if we do this too early in the update process, the TextInput appears to bounce between the end and the start of the input multiple times. This seems to be a result of setSelection occurring multiple times during rendering.

To minimize this, my solution uses View.post() to scroll to the beginning only after all TextInput management has completed. I should point out that by adding the !hasFocus condition, we are only introducing this behavior for initial rendering and subsequent state changes that modify the text while the input is unfocused. The behavior does not apply when conducting text edits, since in that case the input would be focused while text management is occuring.

Overall, the goal of the solution is to increase text readability on initial render, and when adding text programatically. I'm inferring that the user will not be as interested in seeing the beginning of the text immediately after editing it, so the behavior does not change in that regard.

[johnmlee101]

@NickGerleman what is the latest here?

[NickGerleman]

I still hold the concern that the solution proposed in this PR may have side effects beyond the problem we are targeting. It changes behavior, away from where the bug is happening.

You've identified this case, where RN is moving the selection without the user is telling it to. In this case, the framework is telling the EditText to change selection, though the user didn't.

Ideally, RN should not move selection in the EditText except when told to. It doing that is the root incorrect behavior which seems to cause this issue. I would accept a PR targeted at preventing these errant selection changes.

A recent PR that fixed a case of errant native selections (in a different scenario) is #37424

[redstar504]

@NickGerleman This issue stems from a couple of places. Yes, React Native forces the selection to the text length when the selection is empty, causing the view to scroll to the rightmost character. That is easy enough to change. However, disabling that behaviour unmasks an underlying quirk (or bug) of Android itself.

Android normally displays the beginning of the text input when you set a value. However, strangely, if you set or replace the value of a text input to null or to an empty string, and subsequently set a value using Editable.replace as is used in RN, it will also shift the selection to the end of the text. I am assuming this may be related to the behavior explained at the last sentence in the Android docs, however I am not sure whether this specific behavior was intended.

So even if we did not manipulate the selection on RN, we would still be stuck with the Android behavior. Text gets set to null or an empty string frequently in RN, therefore subsequent value changes will reflect themselves through a rightmost selection, which not within our control.

It seems like in this issue we're more concerned with scroll. Scroll and selection can be independent. In fact, I feel more accustomed to my cursor falling at the end of the text input when pressing on it (selection), as is the case in iOS. I also expect to see the beginning of the line of text when viewing text inputs (scroll).

It seems like we're a bit stuck here. Do we force selection to the beginning when it's not set by the user? Are we set on coupling selection with scroll, or can we consider managing them independently? Should we simply expose the scroll method to Javascript so the behavior can be managed by the developer?

[github-actions]

This PR is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This PR was closed because it has been stalled for 7 days with no activity.