GNOME Bugzilla – Bug 788258
Make logout, shutdown, and restart dialogs easier to use with keyboard
Last modified: 2021-07-05 14:03:52 UTC
Created attachment 360564 [details] [review] Set default keyboard focus in modal dialogs for shutdown and logout Through our support, bug reports, and user testing, we've found that many users prefer to use the keyboard to confirm shutdown, logout or select restart whenever possible on a variety of F/OSS desktop environments. In GNOME-shell, currently, this use case is confusing. In the user testing, we've found it wasn't very discoverable. You can't confirm the action by pressing enter. The only keyboard input that would indicate an interaction with the dialog box is a tab. There is no cultural motivation from Unity users to try the tab button here, which we will have a large number of. Through user testing we found it takes four keypresses to confirm shutdown from the model dialog. To confirm shutdown, the user has to hit tab, then arrow left, right twice or tab twice again to shutdown, and then press enter. In other environments (Unity for example), pressing enter confirms shutdown and arrowing left or right will select restart or other actions -- one keypress for shutdown, two for restart! GNOME 3.26 users can initiate the shutdown and logout dialogs via keyboard from the overlay. Matthias Clasen suggested that improving keyboard navigation would make sense in particular when the dialog is triggered via keynav. Our testing indicates that users also use the keyboard here when triggering the dialog with the mouse. Hitting a key or short sequence of keys is easier to build muscle memory around. The enter key (and left/right arrow) present an easier muscle memory target than clicking a button in the middle of the screen. I'm attaching a patch to streamline keyboard navigation and make the navigation more discoverable. The patch sets an initial selection on the action matching what the user chose from the system menu or overlay. This makes it so the user can press enter to confirm and the arrow keys to select other actions. Suggestions or improvements welcome!
My suggestion was to set a visible initial focus only when the dialog wast triggered by keynav, and leave things as they are now if it is opened by mouse action.
Created attachment 360582 [details] screenshot Here's a screenshot of the patch in action. While I'm keen to accommodate users who are transitioning over from Unity, I'm a little nervous about encouraging keyboard interaction for something potentially destructive like shutdown. What would happen in the case where an application is inhibiting shutdown? Could a user quickly hit return without looking, and lose their work?
Review of attachment 360564 [details] [review]: ::: js/ui/endSessionDialog.js @@ +77,3 @@ confirmButtons: [{ signal: 'ConfirmedLogout', + label: C_("button", "Log Out"), + is_default: true }], Coding style: camelCase @@ +492,3 @@ let signal = dialogContent.confirmButtons[i].signal; let label = dialogContent.confirmButtons[i].label; + let is_default = dialogContent.confirmButtons[i].is_default; Dto ::: js/ui/modalDialog.js @@ +120,2 @@ addButton: function (buttonInfo) { + let button = this.dialogLayout.addButton(buttonInfo); addButton() is supposed to handle the 'default' field already, but this broke when splitting ModalDialog in commit 1c7a3ee61b1892b56. This should be fixed separately, I filed bug 788282 for that.
I like Florian's patch for fixing addButton(). Allan: I'm also keen to avoid unwanted shutdowns! I'm not super nervous about the keyboard interaction here, since users coming from the system menu will generally have clicked to bring up the dialog. This means they will have time to see the list of inhibiting apps on the way to the <enter> key. There is one issue with the current version of my patch. If you trigger the shutdown dialog via keyboard (say from the overlay), a long press on enter will release after the dialog opens. The dialog is only waiting on a key up event, where a full press-release cycle is needed to be sure.
(In reply to Allan Day from comment #2) ... > While I'm keen to accommodate users who are transitioning over from Unity, > I'm a little nervous about encouraging keyboard interaction for something > potentially destructive like shutdown. What would happen in the case where > an application is inhibiting shutdown? Could a user quickly hit return > without looking, and lose their work? One solution to this could be to put keyboard focus on cancel by default, possibly only in the case where an application is inhibiting shutdown.
Another way to simplify the keyboard navigation is show a simplified version of the dialog (e.g., a dialog with only two buttons: cancel and do-X) when the action comes from a gnome-shell search. For example, when I activate the reboot action, the shell shows a dialog with only the cancel/reboot buttons.
Reboot isn't exposed as separate search result though (but the keyword will match the "Power Off" action when bug 786987 lands)
(In reply to Alessandro Bono from comment #6) > Another way to simplify the keyboard navigation is show a simplified version > of the dialog (e.g., a dialog with only two buttons: cancel and do-X) when > the action comes from a gnome-shell search. For example, when I activate the > reboot action, the shell shows a dialog with only the cancel/reboot buttons. That's a nice idea. It might be a bit unpredictable to have different dialogs depending on where you come from, though...
I spoke with Jakub about this issue yesterday. We're both happy to go ahead with the proposed solution. However, I would like to see keyboard focus set on the cancel button in cases where an application is inhibiting shutdown.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.