Repository navigation
Interaction between modals, scrolls, and focuses #34025
Description
Description
The way Flutter handles the interaction between modals, scrolls and focuses is different from native Android.
Below are two videos recorded on a native Android app:
- When a dialog pops up, the on-screen keyboard
- a) does not disappear
- b) is rendered hidden behind the overlay
- When the dialog disappears, the previously focused widget
- c) keeps its focus
- d) is not scrolled into view
- e) In addition to c), if the keyboard was not screen before the dialog, resuming focus does not bring it up.
Related issue
#33152 tried to make ModalScope resume its previous focus when its next route is popped. This PR solved only c), violating everything else, and even broke some tests by violating d).
Why is this important
Contenxt menu. When the user is editing and right clicks the text to bring up a context menu
- It requires c) so that the text field is not unfocused
- It prefers a), or at least e), so that the screen doesn't go through multiple sudden metric changes.
Dialog. In addition to the reasons above,
- It prefers d) so that when the user is editing, scrolls down, and pops up a dialog that's at the bottom of the page, the screen doesn't scroll back to the top when the dialog disappears.
Suggestion
If we only want to ensure basic support for context menu, it shouldn't be too hard if we add some special management of focus and input connection onto context menu popups, so that a), e), c), and even d) can be fixed for context menu.
In order to fix a) c), d) and e) for all modals including dialogs, we might need to allow focus scopes to manage their own focuses, which will be a much bigger change that might be breaking.
Fixing b) is probably impossible in a single-view Flutter app, and need to be discussed after Flutter supports easy multi-view.


Activity