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 737109 - dismissing wait? dialogue with ESC performs destructive action
dismissing wait? dialogue with ESC performs destructive action
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal major
: ---
Assigned To: mutter-maint
mutter-maint
: 771690 777603 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-09-22 10:47 UTC by Christian Persch
Modified: 2017-01-22 13:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Invert the logic of the dialog (844 bytes, patch)
2016-09-20 09:06 UTC, Landry MINOZA
none Details | Review
Invert the logic of the dialog (1.31 KB, patch)
2016-09-20 10:08 UTC, Landry MINOZA
none Details | Review
delete: Swap wait/force-quit actions (1.50 KB, patch)
2016-09-20 10:30 UTC, Florian Müllner
committed Details | Review

Description Christian Persch 2014-09-22 10:47:34 UTC
When an app doesn't react and mutter shows the "wait or force quit?" dialogue, dismissing the dialogue with pressing ESC performs the destructive "force quit" action instead of the nondestructive "wait" action, as I'd expected.

This is because zenity equates ESC with the cancel action. However, mutter is calling zenity with 'ok' == 'wait' and 'cancel' == 'force quit', ie the 'cancel' action is the destructive one. This looks backwards, and is likely a regression from bug 581046.
Comment 1 Christian Persch′ 2016-08-21 16:42:38 UTC
Still happening in 3.20.
Comment 2 Christian Persch 2016-09-20 07:56:09 UTC
*** Bug 771690 has been marked as a duplicate of this bug. ***
Comment 3 Landry MINOZA 2016-09-20 09:06:21 UTC
Created attachment 335911 [details] [review]
Invert the logic of the dialog

Make Force Quit action on the OK button and test if EXISTSTATUS is 0 (OK button pressed) instead of 1 to kill the freezed window
Comment 4 Landry MINOZA 2016-09-20 09:07:14 UTC
It is simple to test with a simple python script launched in a terminal
#!/usr/bin/env python
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk

class MyWindow(Gtk.Window):

    def __init__(self):
        Gtk.Window.__init__(self, title="Hello World")

        self.button = Gtk.Button(label="Click Here")
        self.button.connect("clicked", self.on_button_clicked)
        self.add(self.button)

    def on_button_clicked(self, widget):
        while True:
		pass

win = MyWindow()
win.connect("delete-event", Gtk.main_quit)
win.show_all()
Gtk.main()

After a clic on "Click Here" button, this application hangs (eating CPU
in infinite loop), clic on the "close" window decoration and gnome
suggest to kill it after a few seconds.
Comment 5 Florian Müllner 2016-09-20 09:50:49 UTC
Review of attachment 335911 [details] [review]:

Please use git-format-patch to include a commit message

::: src/core/delete.c
@@ +45,3 @@
   window->dialog_pid = -1;
 
   /* exit status of 1 means the user pressed "Force Quit" */

The comment needs to be updated as well
Comment 6 Landry MINOZA 2016-09-20 10:08:39 UTC
Created attachment 335915 [details] [review]
Invert the logic of the dialog

Reworked patch to modify comment also and use git-format-patch to include commit message.
Comment 7 Florian Müllner 2016-09-20 10:30:19 UTC
Created attachment 335916 [details] [review]
delete: Swap wait/force-quit actions

Reattaching with a proper commit message
Comment 8 Rui Matos 2016-09-20 13:32:10 UTC
Review of attachment 335916 [details] [review]:

looks good, but I guess this is a UI break?
Comment 9 Florian Müllner 2016-10-10 22:55:00 UTC
Attachment 335916 [details] pushed as ed52e17 - delete: Swap wait/force-quit actions
Comment 10 Florian Müllner 2017-01-22 13:59:01 UTC
*** Bug 777603 has been marked as a duplicate of this bug. ***