Repository navigation
How to share focus with popovers and other sub-tasks #106923
Description
Activity
CC @justinmc
Hello @matthew-carroll. Thank you for filing this issue. Can you include the output of
flutter doctor -vas well as a minimal, reproducible example along with reproduction steps?The Flutter version doesn't matter for this. It's a question about the approach. All necessary information is in the ticket. I'd like to hear the perspective from someone working on text input, e.g., @justinmc, @gspencergoog, @LongCatIsLooong
That issue may or may not be related. But the root question here is how a Flutter developer should know when losing focus means "your input isn't active anymore" vs situations that mean "your input is still active, but something else has focus temporarily". You can see those examples in the original post.
the moment focus moves away from the field, the selection is gone
TextFieldis considered focused as long as a descendant in its focus tree is focused, even if theTextFieldis not the primary focus, because it mostly relies onhasFocusto determine if it's receiving input.When composing text, there are a number of occasions in which some kind of popover might appear.
If elements in the popover are themselves focusable and have to use dedicated
FocusNodes, then in theory as long as theseFocusNodes are descendants of theFocusNodeyou gave to theTextField,TextFieldshould still consider itself as focused and appear as focused. This may require the popover implementation to find the focus node that belongs to the text field, if the popover is implemented as a separateOverlayEntry, since you can't rely on the widget tree hierarchy to automatically do that for you.It sounds like you're saying that
FocusNodehierarchy might be different fromWidgethierarchy. Am I understanding you correctly?If so, don't
Focuswidgets automatically reparentFocusNodes such that aFocusNodein an overlay can't be a descendent of aFocusNodein the regular tree?Furthermore, what's the story around platform interop? You'll see in the original post that there are multiple situations where the popover is a system UI, e.g., a context menu or a compound character selection.
That's right. I think the
Focuswidget usesFocus.ofto build the focus tree. So if you want the text field to stay focused when something in the popover gains focus, right now you'll probably have to manage theFocusNodesubtree yourself.Furthermore, what's the story around platform interop? You'll see in the original post that there are multiple situations where the popover is a system UI, e.g., a context menu or a compound character selection.
As far as the text input plugin goes I think the flutter framework handles focus separately from the platform's focus system. For key input if the system decides to hand a key event to the FlutterView then the embedder sends the key event to the framework.
Can we get an official Flutter team example of each situation, so that everyone is clear on the intended approach? E.g., a case where focus moves to an in-app popover and back, and a case where focus moves to an OS popover and back?
I'm also wondering if Flutter should offer a generalized capability to achieve this
FocusNodehierarchy. We can handle a custom hierarchy when the same developer is developing the document editor and the popovers. But consider that super_editor is developing the document editor and app developers are creating any number of popovers. How do we deal with open-ended possibilities for this use-case?I'll add another detail to this issue. I started to implement custom management of a
FocusNode's parent. However, my custom parenting wasn't being respected. The parent-child relationship kept getting changed by something else.I discovered that
TextFieldpasses itsFocusNodetoEditableText, which then includes aFocuswidget within itself. Therefore, it looks likeTextFieldis forcing reparenting based on the widget tree, preventing me from solving this problem. Is there an intended workaround for this situation?29 remaining items
This issue is missing a priority label. Please set a priority label when adding the
triaged-frameworklabel.
There's a conflict in text-based focus behavior in Flutter and I'm wondering if there's an intended approach to this problem.
Typically, when entering text into something like a form field, the moment focus moves away from the field, the selection is gone. For example, you'll see a caret and type text into a "name" field. Then, focus moves to an "email" field. At this point, there is no caret or selection in the "name" field any longer, and there is a caret in the "email" field. However, this focus behavior is not universal.
When composing text, there are a number of occasions in which some kind of popover might appear. For example, a popover to select text styles, enter a URL for a link, or select a compound character. In these situations, the popover includes focusable elements, and the user should be able to move focus around those elements. But that focus change should not impact the selection within the text field. Additionally, the moment the popover disappears, focus should return to the text field with the selection unchanged.
Does Flutter have an approach for handling these different situations?
Visual examples:
Editing the link URL in a selection toolbar (this example use
SuperEditorbut without keyboard as the input source, not IME)Right-click on selected to show the context menu
Press and hold character key that can be written with different accents depending on the language (e.g. Portuguese)
