You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Keyboard focus is lost when popping multiple screens with Navigator.popuntil #48903
@gspencergoog we tested this in the most recent master but we haven't noticed any difference in the behavior, should we open a new issue or wait for an update?
It incorporates part of @chunhtai's fix (finding a focusable parent to focus), but I should probably incorporate the test that @chunhtai created here into that PR too.
@HerrNiklasRaab It looks like there is a fix for the keyboard_dismisser that works for the case you want.
That particular change in the focus code was made because without a valid scope for the node requesting to be unfocused, there isn't a way to determine what the next focused node should be. Unfocus is not about losing focus, it's about transferring focus to another node, since there can't really be a case where nothing has focus, or focus traversal stops working.
Because of this, you may notice that with keyboard_dismisser as it is now, that once the soft keyboard is dismissed, pressing TAB when there is a hardware keyboard connected will no longer move to the next available focus node until focus is explicitly given to a node that is in the focus tree.
This may not matter to you, since you're clearly interested in the mobile experience, but it does matter in other contexts (e.g. on the web, or a desktop app).
Reacted by Diego Rogel and Snæbjörn Valur Lilliendahl
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
gmoraja commentedon Feb 9, 2020
@gspencergoog we tested this in the most recent master but we haven't noticed any difference in the behavior, should we open a new issue or wait for an update?
chunhtai commentedon Feb 10, 2020
Taking a look
chunhtai commentedon Feb 10, 2020
Ok, I found the issue, My fix does not fix all the possible use cases.
Will put up another pr to make the focus traversal more robust
goderbauer commentedon Feb 19, 2020
@gspencergoog Does #50831 fix this or how does it relate to this issue?
gspencergoog commentedon Feb 19, 2020
It incorporates part of @chunhtai's fix (finding a focusable parent to focus), but I should probably incorporate the test that @chunhtai created here into that PR too.
gspencergoog commentedon Feb 26, 2020
But yes, #50831 fixes this.
Change Focus.unfocus to take a disposition for where the focus… (#50831)
HerrNiklasRaab commentedon Apr 11, 2020
Hey @gspencergoog, this change seems to break this plugin, just try the example an move the KeyboardDismisser ouside the MaterialApp:
https://github.com/drogel/keyboard_dismisser
Is it intended, that unfocus doesn't work outside of the MaterialApp?
I further described my problem there: drogel/keyboard_dismisser#1
gspencergoog commentedon Apr 13, 2020
@HerrNiklasRaab It looks like there is a fix for the keyboard_dismisser that works for the case you want.
That particular change in the focus code was made because without a valid scope for the node requesting to be unfocused, there isn't a way to determine what the next focused node should be. Unfocus is not about losing focus, it's about transferring focus to another node, since there can't really be a case where nothing has focus, or focus traversal stops working.
Because of this, you may notice that with keyboard_dismisser as it is now, that once the soft keyboard is dismissed, pressing TAB when there is a hardware keyboard connected will no longer move to the next available focus node until focus is explicitly given to a node that is in the focus tree.
This may not matter to you, since you're clearly interested in the mobile experience, but it does matter in other contexts (e.g. on the web, or a desktop app).
github-actions commentedon Aug 22, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.