Allow text inputs to handle native requestFocus calls #48547
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 9, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Differential Revision: D67953398
joevilches
force-pushed
the
export-D67953398
branch
from
0edf74c to
2c7e96a
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
force-pushed
the
export-D67953398
branch
from
2c7e96a to
fcc7559
Compare
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 9, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Differential Revision: D67953398
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
force-pushed
the
export-D67953398
branch
from
fcc7559 to
2f7c6b8
Compare
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 13, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Reviewed By: NickGerleman Differential Revision: D67953398
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 13, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Differential Revision: D67953398
joevilches
force-pushed
the
export-D67953398
branch
from
2f7c6b8 to
004c750
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 14, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Differential Revision: D67953398
joevilches
force-pushed
the
export-D67953398
branch
from
004c750 to
c467686
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
force-pushed
the
export-D67953398
branch
from
c467686 to
43470e4
Compare
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 14, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Reviewed By: NickGerleman Differential Revision: D67953398
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
joevilches
added a commit
to joevilches/react-native
that referenced
this pull request
Jan 14, 2025
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Reviewed By: NickGerleman Differential Revision: D67953398
joevilches
force-pushed
the
export-D67953398
branch
from
43470e4 to
b025f5c
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
Summary: For some unknown reason, we have been swallowing [`requestFocus`](https://developer.android.com/reference/android/view/View#requestFocus(int) calls since `TextInput` is a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason why I do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input. This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a `TextInput`. This is because Android will call `requestFocus` from [here](https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/view/ViewRootImpl.java;l=7868?q=performFocusNavigation) when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focus `TextInputs` since they go through `ExploreByTouchHelper` methods which we override to call the proper `requestFocusInternal()` method. **In this diff**: I move the logic in `requestFocusInternal()` into `requestFocus`. Reviewed By: NickGerleman Differential Revision: D67953398
joevilches
force-pushed
the
export-D67953398
branch
from
b025f5c to
896a98f
Compare
|
This pull request was exported from Phabricator. Differential Revision: D67953398 |
|
This pull request has been merged in 3420eb8. |
|
This pull request was successfully merged by @joevilches in 3420eb8 When will my fix make it into a release? | How to file a pick request? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
For some unknown reason, we have been swallowing [
requestFocus](https://developer.android.com/reference/android/view/View#requestFocus(int) calls sinceTextInputis a controlled component - meaning you can control this components value and focus state from JS. This decision was originally made pre 2015 and I cannot find the reason whyI do not think this makes sense. We can still request focus from JS, while allowing the OS to request focus as well in certain cases and we would still be controlling this text input.
This is breaking keyboard navigation. Pressing tab or arrow keys will no-op if the next destination is a
TextInput. This is because Android will callrequestFocusfrom here when handling key events. Notably, Explore By Touch (TalkBack) swiping gestures WOULD focusTextInputssince they go throughExploreByTouchHelpermethods which we override to call the properrequestFocusInternal()method.In this diff: I move the logic in
requestFocusInternal()intorequestFocus.Differential Revision: D67953398