Bug 981149

The full zenity command is (from ps -ax | grep zenity):

zenity --question --display :1.0 --class mutter-dialog --title  --text <big><b>“ - Notes” is not responding.</b></big>  You may choose to wait a short while for it to continue or force the application to quit entirely. --ok-label _Wait --cancel-label _Force Quit --icon-name face-sad-symbolic --modal

But I don't have mutter running. Looks like it is generated by libmutter or what not that gnome-shell links to.

Still happens all the time, when the system is sluggish for legitimate reasons. I need an option to disable this annoying behavior.

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

still a problem in f21.

This breaks many automated Eclipse tests on RHEL 7 even if nothing heavy is running in parallel. Eclipse is a heavy program on its own and it just takes some time to start it.

This annoying pop-up steals focus and breaks things and I can't see how to disable it. Now i use removing /usr/bin/zenity but that's not how things should be done.

Yes, I was tempted to remove zenity just to get out of this behavior.

I think this is a gnome-shell craziness - if the whole desktop isn't drawn by
one application (gnome-shell), one or two applications being unresponsive doesn't matter - one can always uses a terminal (which is rarely unresponsive)
to kill the stuck one.

Still a problem, and it is happening while I am just clicking firefox windows in succession - and quite terrible as it steal focus, which means if I click on two or three windows' tab to bring them into front, I could accidently kill the first one.

Since zenity is being called with "--class mutter-dialog":

"zenity --question --display :0.0 --class mutter-dialog ..."

I 'd guess it is mutter issue. Anyway, would really like some redhat people to comment, since this is very annoying and it has been a whole year and three releases now.

After accidentally killing off firefox twice on two consecutive days, I have had enough and looked at the mutter source to disable the zenity pop-up dialog. Here is the single line change to mutter that I have been using for about 30 hours now - and I am *so* happy I am not seeing the annoying zenity pop-up any more !!!!!

Please consider putting this in, or if it is too barbaric, add something equivalent as a user choice - "absolutely do not want to see any pop-ups about applications not responding and do not offer any choice of whether I like to force-kill it".

diff --git a/src/core/delete.c b/src/core/delete.c
index 141cd49..d8a126e 100644
--- a/src/core/delete.c
+++ b/src/core/delete.c
@@ -98,6 +98,8 @@ show_delete_dialog (MetaWindow *window,
               "Got delete ping timeout for %s\n",
               window->desc);
 
+  return;
+
   if (window->dialog_pid >= 0)
     {
       present_existing_delete_dialog (window, timestamp);

The diff is against mutter HEAD I think, but applies well with 3.16.3 .

When using a Manipulate[] construction in Mathematica, if you move a slider back and forth for more than a second or two, it triggers this dialog box even though the window in question is responsive.

I occasionally find this dialog useful, but I'd also like a way to disable it.

(In reply to Garrett Mitchener from comment #11)
> When using a Manipulate[] construction in Mathematica, if you move a slider
> back and forth for more than a second or two, it triggers this dialog box
> even though the window in question is responsive.

The window is apparently responding to your mouse clicks, but it isn't responding to NET_WM_PING messages (the timeout is 5 seconds.) This is a Mathematica bug.
 
> I occasionally find this dialog useful, but I'd also like a way to disable
> it.

Honestly, we're not going to do this - if apps advertise NET_WM_PING in their WM_PROTOCOLS they need to live up to the contract of responding to it in a timely fashion.

(The origin problem in this bug seems to be incredibly bad system performance - apps are perhaps getting swapped out to a very slow disk? It doesn't sound at all usable with or without the dialogs :-()

(In reply to Owen Taylor from comment #12)
...
> The window is apparently responding to your mouse clicks, but it isn't
> responding to NET_WM_PING messages (the timeout is 5 seconds.) This is a
> Mathematica bug.

Is it possible to make the time out user-configurable?

...
> (The origin problem in this bug seems to be incredibly bad system
> performance - apps are perhaps getting swapped out to a very slow disk? It
> doesn't sound at all usable with or without the dialogs :-()

My firefox is always 1/3 not resident, at least. I do not see that as a problem:

3245 hintak    20   0 7582576 5.377g  58076 S  35.8 79.7 400:57.42 firefox

I have many firefox windows open, many of which I don't visit for hours.

(In reply to Hin-Tak Leung from comment #9)
> After accidentally killing off firefox twice on two consecutive days, I have
> had enough and looked at the mutter source to disable the zenity pop-up
> dialog. Here is the single line change to mutter that I have been using for
> about 30 hours now - and I am *so* happy I am not seeing the annoying zenity
> pop-up any more !!!!!
> 
> Please consider putting this in, or if it is too barbaric, add something
> equivalent as a user choice - "absolutely do not want to see any pop-ups
> about applications not responding and do not offer any choice of whether I
> like to force-kill it".
> 
> diff --git a/src/core/delete.c b/src/core/delete.c
> index 141cd49..d8a126e 100644
> --- a/src/core/delete.c
> +++ b/src/core/delete.c
> @@ -98,6 +98,8 @@ show_delete_dialog (MetaWindow *window,
>                "Got delete ping timeout for %s\n",
>                window->desc);
>  
> +  return;
> +
>    if (window->dialog_pid >= 0)
>      {
>        present_existing_delete_dialog (window, timestamp);

been using the diff for almost two months now, and even through upgrade to f23.
basically whenever my own rpm gets overwritten by an upgrade, I go and fetch the source rpm and patch it and rebuild, and have never been without the patch for more than the time to rebuild.

and I do not miss that dialog.

Any news on this? The bug is still existent in Gnome 3.20.3
An option to disable the dialog would be very helpful.

PS: At least change the default keybinding, pressing `ESC` will kill the application instead of closing the dialog.

I have my one-liner patch in for every upgrade since. Luckily mutter upgrades are not frequent. Honestly I do not miss the force-kill dialog. I don't need it, and don't want it.

Any news on this? This is super annoying when debugging GUI applications. Yes, I'm aware that the program I debug will not respond to pings while it's at a breakpoint. No, I don't want to close it.

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This is still in F25

Still a problem.

Hello everyone. I solved this annoying problem for myself and want to share for others. I found this method great because you don't need to touch system and it will work after any update.

1.) open terminal
2.) mkdir -p ~/bin
3.) echo : > ~/bin/zenity 
: command means do nothing
4.) chmod +x ~/bin/zenity

if won't work then use ~/.local/bin instead of ~/bin
Good Luck.

(In reply to bolune from comment #21)
> Hello everyone. I solved this annoying problem for myself and want to share
> for others. I found this method great because you don't need to touch system
> and it will work after any update.
> 
> 1.) open terminal
> 2.) mkdir -p ~/bin
> 3.) echo : > ~/bin/zenity 
> : command means do nothing
> 4.) chmod +x ~/bin/zenity
> 
> if won't work then use ~/.local/bin instead of ~/bin
> Good Luck.

That breaks zenity completely, though.

Still a problem in Fedora 26.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Still a problem, and also my patch seems not to work any more after upgraded to fc27, so the problem has gotten worse.

I am getting the extremely annoying "unresponsive app" dialog in fc27 when opening files from the network (sftp) in Nautilus, which launches Kate. Kate would always be reported as unresponsive, but after clicking Wait will continue normally. I would greatly appreciate a fix.

(In reply to J. Haas from comment #17)
> Any news on this? This is super annoying when debugging GUI applications.
> Yes, I'm aware that the program I debug will not respond to pings while it's
> at a breakpoint. No, I don't want to close it.

I agree; this behaviour is extremely annoying while debugging apps. I wonder how GNOME devs debug apps while using gnome-shell? is there some trick to stop that dialog from becoming a recurring pain in the neck?

The problem seems to be considerably worse in FC27, not sure if the timeout is shorter, but I am finding that by the time the debug breakpoint hits, I get only a few seconds to do anything before the entire desktop becomes unresponsive to mouse input, although keyboard input appears to continue functioning.  

For now its completely unusable for debugging.

Same here. This comes up whenever I hit a breakpoint in Clion, but freezes Clion.
Now I need to find the dialog (in the background), hit continue, but it reappears while I try to go back to my debugger and hit the next step1.

I appreciate the good intention of the dialog, but would appreciate it more if there was a way to disable it.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

As with the rollover to each new Fedora release since 2013 this ticket needs to be reopened as it still exists.

Is there any way to mark this ticket as unlikely to be resolved by a simple change from one Fedora version to the next? It seems it actually requires a bit more than this to address it.

When doing debugging, the debugged app often appears unresponsive but is simply stopped in the debugger. The repeated appearance of the "unresponsive app" dialog makes the debugging process very difficult.

To see this simply launch a GUI application in debug mode in something like IntelliJ/CLion, place a breakpoint in e.g. the handler code for a particular button in the GUI and then press that button.

At this point the application appears unresponsive - just wait for the timeout documented above and see how problematic it is to carry on working in the debugger while the "unresponsive app" dialog is visible (and keeps returning if dismissed).

This is a classic example of developers not paying attention to their customers. As others have said, this "feature" makes debugging on RedHat OSes (I use Centos 7) virtually impossible. I am not a window manager expert, but I notice that there is a fork of mutter - muffin. Does anyone know if it has the same problem? If not, how can I switch to it on Centos 7?

(In reply to dnessett from comment #32)
> This is a classic example of developers not paying attention to their
> customers. As others have said, this "feature" makes debugging on RedHat
> OSes (I use Centos 7) virtually impossible. I am not a window manager
> expert, but I notice that there is a fork of mutter - muffin. Does anyone
> know if it has the same problem? If not, how can I switch to it on Centos 7?

Here is the answer. Install KDE Plasma desktop and switch to it. No absurd "... not responding" messages. I can now debug applications. The instructions for installing KDE Plasma are here:

https://www.rootusers.com/how-to-install-kde-plasma-gui-in-centos-7-linux/

Still a problem in Fedora 31.