-
Notifications
You must be signed in to change notification settings - Fork 83
Description
Is your feature request related to a problem? Please describe.
Suppose you have a CodeEditor widget and some toolbar with some buttons nearby.
Let's say user is editing a text inside CodeEditor. Then user wants to tap a button on a toolbar, for example to paste some text into cursor position so user can keep typing after the inserted thing is pasted. However, doing so (pressing any button or other UI element that can have focus) removes focus from CodeEditor. On mobile, this hides the on-screen keyboard; on desktop, this prevents any further keyboard input to affect CodeEditor content until focus is re-established. Both represent very poor user experience since after this user has to click inside CodeEditor to re-obtain focus and re-position cursor to exactly where it's been before clicking the button.
If instead of CodeEditor, a TextField is used, clicking any button does NOT remove focus in both mobile and desktop builds. Only way to move keyboard focus is pressing "back" button on mobile (which hides on-screen keyboard) or clicking on a different text input field.
Describe the solution you'd like
TextField focus behavior should be replicated - any element that can't use keyboard should not steal focus from CodeEditor. This is possible because this is how it works with TextField.
Describe alternatives you've considered
I worked around it by using FocusScope to catch runaway focus and reassign it to the editor. It works in a sense that keyboard doesn't disappear now, however interactive selection is still lost and I need a workaround to catch it before disappearing to handle button editor clicks. So ideally it should not lose selection on losing focus or should not let focus run away at all like TextField does.
Additional context