Multiline TextInput key handling: add check for first responder #2215
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:
Consider a hypothetical situation where a multiline TextInput handles (by dequeueing from the event queue) Cmd+Enter. If the focus is on another control that also handles Cmd+Enter, then hitting Cmd+Enter will not reach this other control -- in fact it will perform the action for the former TextInput, as if it were focused!
performKeyEquivalent is documented to be called even if a view isn't first responder (this is for example how "Enter" binds to the default button on a dialog -- the default button doesn't need to be focused to respond to Enter), but since we override performKeyEquivalent to properly support certain keyboard shortcuts (like noted in #1867), the previous assumption on the actual use of performKeyEquivalent no longer holds -- it's only intended for keystrokes sent in focused state, so add that check.
Test Plan:
Manually tested affected scenario for correct behavior.