GNOME Bugzilla – Bug 728151
Power Off (misnamed as Logout) keyboard shortcut - dialog isn't always keyboard accessible, is delayed, must be dismissed twice, etc.
Last modified: 2016-12-09 17:15:27 UTC
When pressing Alt+Ctrl+Delete there's a delay before the logout dialogue is shown. From the system journal: Apr 14 09:11:09 localhost gnome-session[746]: gnome-session[746]: WARNING: Client '/org/gnome/SessionManager/Client1' failed to reply before timeout Apr 14 09:11:09 localhost gnome-session[746]: WARNING: Client '/org/gnome/SessionManager/Client1' failed to reply before timeout When I click Poweroff or Reboot, the dialogue disappears then quickly reappears and the poweroff/reboot is carried out as expected. This delay isn't present when the logout dialogue is launched via the menu or by executing `gnome-session-quit --poweroff` from terminal. I saw this issue with 3.10.x and also now with 3.12.0. Downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1049308
*** Bug 767526 has been marked as a duplicate of this bug. ***
Just to be clear: * This brings up the Power Off dialog, not the Log Out one. The option in the Keyboard preference is misnamed. Please consider having properly named options for both, * The 2nd reappearance of the dialog also occurs when click Cancel/pressing Esc, in which case we have to dismiss the dialog twice... references: https://bugzilla.gnome.org/show_bug.cgi?id=671979 - 'we need to call Power Off instead of Log Out', with no rationale and no corresponding relabel of the option https://bugzilla.gnome.org/show_bug.cgi?id=767526 - more recent report (closed as dupe, but) with some more info and a video screencast of all the problems Thanks
In GNOME 3.20, this bug impacts users who are unable to use a mouse. Because in addition to what was stated in comment 2, the 2nd appearance does not seem to be keyboard accessible. Pressing Escape does nothing for me. Neither does Tab. Moreover, all other keyboard interaction ceases working. If you pressed Ctrl+Alt+Del and then realized you didn't want to power off your system after all, you are out of luck if you cannot click. (This issue was mentioned on the Orca mailing list because this dialog is inaccessible due to the above reasons.)
(In reply to Joanmarie Diggs (IRC: joanie) from comment #3) Thank you for adding that. I hadn't, and might never have, noticed that the keyboard apparently doesn't work there. But... it seems it _did_ work when I tested it: in my screencast https://bug767526.bugzilla-attachments.gnome.org/attachment.cgi?id=329608 it can be seen that I could dismiss the dialog without clicking on Cancel. I probably pressed the Esc key. Please can you test that? But regardless of the details, it seems that - in addition to simply having the wrong name and looking glitchy - this might pose a barrier (of currently unclear severity) to users with accessibility requirements. Please can a gnome-session developer at least acknowledge this? Explain why the option is wrongly (re)named, whether it can be split to 2 properly named options, and in any case, make the dialog non-glitchy and fully accessible using keyboard. Thanks in advance.
(In reply to db0451 from comment #4) > can be seen that I could dismiss the dialog without clicking on Cancel. I > probably pressed the Esc key. Please can you test that? To quote from my comment #3: "Pressing Escape does nothing for me."
Sorry, missed that. OK, weird. We have two different results. I'll test again later and see whether it works for me now. Thanks again for the notification re accessibility, will hopefully help this get more attention, and more importantly, make it usable for those unable to click.
To confirm, it still is keyboard accessible for me, as my original video showed - which is odd given the conflicting report above. And do I have to ask yet again whether any GNOME dev will at least acknowledge this ticket and the (depending on how you ask) misleading-to-broken UX? it entails? Maybe I've just gotten interested in GNOME and started filing helpful tickets at a busy time of the year, but it seems very rare to get any response for any tickets on Session, Shell, or really, most modules except GTK+.
(In reply to db0451 from comment #7) > To confirm, it still is keyboard accessible for me, as my original video > showed - which is odd given the conflicting report above. Are you using GNOME 3.20?
(In reply to Joanmarie Diggs (IRC: joanie) from comment #8) > Are you using GNOME 3.20? Yeah, with Debian unstable.
(In reply to db0451 from comment #9) > (In reply to Joanmarie Diggs (IRC: joanie) from comment #8) > > Are you using GNOME 3.20? > > Yeah, with Debian unstable. Maybe you're lucking out then. I use Fedora, and I'm told it's also reproducible in Arch.
Does anyone care about Session bugs? Does the Session Maintainers group actually contain any maintainers?
I think you may have certain expectations about bug reports that don't actually hold. There's no question that a bug report is a very valuable thing, and filing a report is a useful way for someone to contribute to GNOME. But, note, not all bug reports will get attention right away. There aren't enough people working on GNOME for that to work, and even if there were, I don't think that's the right perspective to be coming from. Bug reports aren't TODO items for maintainers, or support tickets for users. They don't have any sort of SLA associated with them. They provide a way for people working on the project to get insight into the problems currently affecting users, and they provide a medium for users to collaborate with each other and with developers on the problems. Bug reports may help with work prioritization, but the reports don't necessarily define what any given person (maintainer or otherwise) is going to be working on. From a macro view, they provide a landscape, not a path. (As an aside, I do think we should figure this bug out, but I'm busy with other stuff at the moment, though)
Thanks Ray - great points, didn't mean to sound impatient, was mostly hoping for an acknowledgement - and glad to know you agree that the dialog should be sorted. (I'll pester the Settings folks about the misnaming separately :-)
Created attachment 335725 [details] [review] manager: set phase to running before clearing inhibitors e83da6fb3c9307895226ae4812ac27b782a57600 introduced a regression where clicking cancel on the power off dialog causes the dialog to reopen itself in case any JIT inhibitor has been taken, since the inhibitors are removed here and removing the inhibitor causing the dialog to reopen to support functionality that was removed from gnome-shell three years ago. To fix this, set the manager phase to running before removing the inhibitors to ensure the power off dialog does not reopen.
(In reply to Ahmad Samir from comment #0) > When pressing Alt+Ctrl+Delete there's a delay before the logout dialogue is > shown. Pretty sure this was fixed a year or two ago; I can't reproduce it anymore.
(In reply to Michael Catanzaro from comment #15) > (In reply to Ahmad Samir from comment #0) > > > When pressing Alt+Ctrl+Delete there's a delay before the logout dialogue is > > shown. > > Pretty sure this was fixed a year or two ago; I can't reproduce it anymore. I can, though obviously it's hard to produce a recording of this... When clicking on the icon in the Shell, the dialog appears instantaneously. When using a keyboard shortcut, however, there's a delay of approximately 1.25 second. Then we get all the other symptoms already mentioned (some varying by user). Thanks for taking an interest in this and the related PRs!
(In reply to db0451 from comment #16) > When clicking on the icon in the Shell, the dialog appears instantaneously. > When using a keyboard shortcut, however, there's a delay of approximately > 1.25 second. Then we get all the other symptoms already mentioned (some > varying by user). OK, I see there is the 1.25 second delay that doesn't occur when the menu item is used. Something is taking a gnome-session inhibitor when the shutdown dialog is opened via the media-keys g-s-d plugin. I haven't figured out what yet, but something is also not replying when gnome-session asks if the inhibitor should be released. Probably the same thing. So (speculation) gnome-session waits for its timeout, which is probably roughly that long. I'm not really inclined to investigate much more, because, while this is a bug, it's not really a big deal. :) Still, it is the original bug here, just a lot of different slightly-related issues got subsequently added to one report.
Yeah. Like you said, first and foremost is fixing the shortcut to do what it says... then it sounds like if/when it's decided to add an _actual_ Power Off shortcut, you've got the fix in mind. :D I think I briefly replicated the lack of keyboard accessibility once earlier, but have no idea how... and I panicked and clicked out of it before I could assess whether there was any way to analyse it, haha. So that might rear its head again in the future.
(In reply to db0451 from comment #18) > Yeah. Like you said, first and foremost is fixing the shortcut to do what it > says... Bug #675005
Comment on attachment 335725 [details] [review] manager: set phase to running before clearing inhibitors looks right
This bug has grown a bit convoluted, so I'll be closing it with this patch; feel free to create a new bug to track just the short delay. It's a good idea to create separate bugs for each issue.
Attachment 335725 [details] pushed as b3b6d74 - manager: set phase to running before clearing inhibitors
(In reply to Michael Catanzaro from comment #21) > This bug has grown a bit convoluted, so I'll be closing it with this patch; > feel free to create a new bug to track just the short delay. It's a good > idea to create separate bugs for each issue. I think the keyboard a11y issue reported is more important, but I can't reproduce it (except maybe once). Besides, I currently have about 5 other things to write up, which I'm hoping are just due to Debian unstable being in flux... :D Thanks for sorting the double-dialog thing anyway.
I assumed the a11y bug was related to the dialog showing twice. I don't know for sure, though. Nor do I know the right place to file a bug for that (Joanie?) for the right a11y people to investigate it.
(In reply to Michael Catanzaro from comment #24) > I assumed the a11y bug was related to the dialog showing twice. I don't know > for sure, though. Nor do I know the right place to file a bug for that > (Joanie?) for the right a11y people to investigate it. I'm pretty sure there's nothing to investigate because your assumption is correct. That is why I commented here rather than filing a new bug: (In reply to Joanmarie Diggs (IRC: joanie) from comment #3) > In GNOME 3.20, this bug impacts users who are unable to use a mouse. Because > in addition to what was stated in comment 2, the 2nd appearance does not ^^^^^^^^^^^^^^ Emphasis on "2nd appearance" because the 1st appearance IS keyboard accessible. > seem to be keyboard accessible. Pressing Escape does nothing for me. Neither > does Tab. Moreover, all other keyboard interaction ceases working. If you > pressed Ctrl+Alt+Del and then realized you didn't want to power off your > system after all, you are out of luck if you cannot click. ^^^^^^^^^^^^^^^^^^^ Emphasis on "if you cannot click" because if you CAN click, you can cancel out of the 2nd appearance and will land back in the first appearance which is keyboard accessible. That said, I'm surprised you cannot reproduce this to confirm the problem as well as the fix. I can reproduce it on both of my (Fedora) systems. Unfortunately, because I'm traveling on business (and pretty occupied all day, every day at the moment), I don't currently have time to set up an environment to build and confirm I am right. When I return home I'll do so -- unless someone beats me to it.
(In reply to Joanmarie Diggs (IRC: joanie) from comment #25) > That said, I'm surprised you cannot reproduce this to confirm the problem as > well as the fix. I can use keyboard to close the second dialog. We're probably both using F24 so I dunno why it's different for us.
(In reply to Michael Catanzaro from comment #15) > Pretty sure this was fixed a year or two ago; I can't reproduce it anymore. Not fixed for me, still reproducible for me on Fedora 25 with Gnome 3.22. (In reply to Daniel Boles from comment #16) > (In reply to Michael Catanzaro from comment #15) > > Pretty sure this was fixed a year or two ago; I can't reproduce it anymore. > > > I can, though obviously it's hard to produce a recording of this... > Here is a recording of it: https://bugzilla.gnome.org/attachment.cgi?id=341667 Observe that between the two dialogs, there is a small flicker. When you pause the recording at the right time, you see that it's the dialog getting bigger and showing the message is "Some applications are busy or have unsaved work" getting bigger for a fraction of a second. (In reply to Michael Catanzaro from comment #21) > This bug has grown a bit convoluted, so I'll be closing it with this patch; > feel free to create a new bug to track just the short delay. It's a good > idea to create separate bugs for each issue. I created bug #775869 to track this. Important thing to add: it only happens with certain programs running, such as Firefox (see my bug report for the rest).
*** Bug 775869 has been marked as a duplicate of this bug. ***
(In reply to Alexander Korsunsky from comment #27) > (In reply to Michael Catanzaro from comment #21) > > This bug has grown a bit convoluted, so I'll be closing it with this patch; > > feel free to create a new bug to track just the short delay. It's a good > > idea to create separate bugs for each issue. > > I created bug #775869 to track this. No, that bug is not about the short delay mentioned in the original report, it's about the dialog appearing twice which the patch on this bug was supposed to fix.
I can't see any indication that the mentioned patch was cherry-picked to the 3.22 branch. Am I missing it?
(In reply to Daniel Boles from comment #30) > I can't see any indication that the mentioned patch was cherry-picked to the > 3.22 branch. Am I missing it? Never mind, the patch is for gnome-session, but I was looking on the gnome-shell git. It's there on gnome-session's 3.22 branch, for the .1 release.
I see that there is still a bug, or multiple remaining bugs, but it's definitely a different issue so please create a new bug report.