After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767526 - Bugs: Keyboard shortcut "Log out" is misnamed, does "Power Off", has a delay, needs Cancel/Esc twice
Bugs: Keyboard shortcut "Log out" is misnamed, does "Power Off", has a delay,...
Status: RESOLVED DUPLICATE of bug 728151
Product: gnome-session
Classification: Core
Component: gnome-session
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-11 10:32 UTC by Daniel Boles
Modified: 2016-09-16 13:27 UTC
See Also:
GNOME target: ---
GNOME version: 3.19/3.20


Attachments
screencast showing the mentioned bugs (1.03 MB, video/webm)
2016-06-11 10:32 UTC, Daniel Boles
Details

Description Daniel Boles 2016-06-11 10:32:50 UTC
Created attachment 329608 [details]
screencast showing the mentioned bugs

Debian unstable.

Using the Keyboard preference pane to assign a shortcut (doesn't matter which) to invoke the so-called "Log out" dialog produces several bugs:

* It actually brings up the dialog called Power Off in the normal Shell menu - not the one called Log Out! This should at least be fixed by relabelling it.
* The dialog appears after a noticeable delay when compared to clicking Power Off (again, NOT Log Out) directly in the Shell menu. Is there a reason for this?
* In order to cancel out of this (technically unwanted) Power Off dialog... I have to click Cancel, or press Esc, twice. The first time, it reappears instantly. Only the second time works and gets rid of it. This is clearly a bug.

Attaching screencast. The exact keyboard combo doesn't matter, and nor does the fact that I have Hide Top Bar active (both tested).

Suggested resolutions
* Rename this "Log out" keyboard shortcut to Power Off
* Add an _actual_ Log Out shortcut
* Remove the seemingly pointless delay when compared to using the Shell meni
* Make them close properly on the 1st time the user presses Cancel or Esc.

Thanks in advance.
Comment 1 Florian Müllner 2016-06-11 13:36:40 UTC
I can reproduce those issues, but they are likely not on the gnome-shell side. gnome-shell offers a DBus API for showing the end-session dialog and signals the response to the caller. 


(In reply to db0451 from comment #0)
> * It actually brings up the dialog called Power Off in the normal Shell menu
> - not the one called Log Out!

The keyboard shortcut is provided and implemented by gnome-settings-daemon. It's not quite clear to me why the action was changed to call gnome-session's Shutdown method (bug 671979), but it was apparently deliberate. It's unclear to me though why the shortcut action was not renamed to reflect the change.


> * The dialog appears after a noticeable delay when compared to clicking
> Power Off (again, NOT Log Out) directly in the Shell menu. Is there a reason
> for this?

A quick test suggests that the delay is not on the gnome-shell side - I can see the dialog immediately when the DBus method is called, but there's a noticeable delay between pressing the shortcut and gnome-session calling the method.


> * In order to cancel out of this (technically unwanted) Power Off dialog...
> I have to click Cancel, or press Esc, twice. The first time, it reappears
> instantly. Only the second time works and gets rid of it. This is clearly a
> bug.

Again not a gnome-shell bug. We pop up a second dialog because we receive a second DBus request the moment the first dialog is closed. So this is likely a gnome-session issue as well.


I'll reassign to gnome-session, which is the most likely component for two out of three issues. Please file a separate bug against gnome-settings-daemon for renaming the "Log Out" action.
Comment 2 Daniel Boles 2016-06-11 15:24:25 UTC
Many thanks Florian for replicating and assigning to the right place, and for linking the other bug (where I've grumbled about the incorrect label).
Comment 3 Felix Zhang 2016-06-12 08:00:19 UTC
Second problem seems to be a duplicate of bug728151. No response in original bug yet.
Comment 4 Florian Müllner 2016-06-12 08:10:37 UTC
(In reply to Felix Zhang from comment #3)
> Second problem seems to be a duplicate of bug728151.

Oh right, and that bug does mention the second dialog invocation as well.

*** This bug has been marked as a duplicate of bug 728151 ***