I cannot reproduce this on either X11 or wayland. In both cases all input to the non-responding window is blocked, but other applications are not affected as expected ...

Ah, I forgot a word – it's *mouse* input that is blocked, although keyboarding still works fine.

That is, although I can move and focus windows, the programs themselves don't receive any clicks for as long as the dialog is shown. Happens reliably on X11.

(Oddly, Chromium's tab-bar is unaffected, but page content still is. All other programs do not respond to any clicks nor scrolls.)

(In reply to Mantas Mikulėnas (grawity) from comment #2)
> Ah, I forgot a word – it's *mouse* input that is blocked, although
> keyboarding still works fine.

No, "all input" in comment #1 was referring to both pointer and keyboard input, so I still cannot reproduce this issue - there must be something else involved.

An update: I realized it doesn't block *all* input, but actually only the area where the "frozen" window is. (It's just that my original report involved fully maximized windows...)

So if there's another, normal window on top of the frozen one, the area where they intersect completely blocks all mouse clicks: they reach neither the normal window, nor the frozen one.

This affects me too. It freezes my debugger when I am debugging an X11 app. And just like the reporter, it freezes only mouse input, not keyboard input.

*** Bug 791411 has been marked as a duplicate of this bug. ***

*** Bug 791977 has been marked as a duplicate of this bug. ***

To reproduce this bug, you can use a debugger and pose an X application.

Was anyone able to make any progress on this one?
This is a major issue if you're debugging X applications.

This bug affects mutter-3.26.2+31+gbf91e2b4c-1 on Archlinux (from official repos).

What do you guys think about having a third option to this dialog: "ignore" which would stop trying to ping the window?

Because when debugging this message is going to pop again, again and again, and this is pretty useless.

(In reply to Mantas Mikulėnas (grawity) from comment #4)
> An update: I realized it doesn't block *all* input, but actually only the
> area where the "frozen" window is.

That is the key observation - what is happening is that the dialog is included in the input region, no matter the stacking.

This is still happening to me (Gnome Shell in Ubuntu 18.04) and it seems like quite a critical issue, since it basically prevents you from keep working in other applications while you wait for the application to become responsive. 

It basically sequesters the computer and forces you to either wait idle, or kill the offending app, which is way worse than just having the application freeze with no dialog.

Perhaps it should be marked more urgent than «Normal»?

I totally agree, this bug is really critical.

It makes it impossible to do development, as soon as you debug an X11 application, it obviously stop responding and you can not even use your debugger anymore...

On the other it is a very feature to let your colleagues make jokes about Gnome and Linux: "HAHAH Linux is the desktop of the year ;-)"

Superseded by https://gitlab.gnome.org/GNOME/mutter/issues/287, https://gitlab.gnome.org/GNOME/gnome-shell/issues/273, etc.

This bug is still a major problem in 	Ubuntu 18.04.4 LTS.    This renders the system completely unusable for a considerable period of time unless you know the workarounds.   And in many cases, you won't know that the problem has to do with the Force Quit dialog; typically, a web browser was blamed for eating up RAM.


As an aid to reproduction, keepassxc seems to bring up the Force Quit or Close dialog a lot.   2.3.1+dfsg.1-1, installed through apt-get.   Currently have uninstalled and am using the version from snap to see if it is more stable.

 
Workarounds:
  - Install the Disable Force Quite or Close gnome shell extension.  Unfortuatenly, this cannot be installed from the command line, which is unacceptable, and you lose the force quit functionallity entirely.
  - Control-Alt-Delete -> Cancel seems to unlock the mouse
  - Alt-Tab reportedly gives you the abiltiy to switch windows, but not unlock the mouse.



   - 

inux cervantes 5.3.0-40-generic #32~18.04.1-Ubuntu SMP Mon Feb 3 14:05:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

                                    all          GNOME Shell extensions integration for web browsers
ii  gnome-shell                                                      3.28.4-0ubuntu18.04.3                           amd64        graphical shell for the GNOME desktop
ii  gnome-shell-common                                               3.28.4-0ubuntu18.04.3                           all          common files for the GNOME graphical shell
ii  gnome-shell-extension-appindicator                               18.04.1                                         all          App indicators for GNOME Shell
ii  gnome-shell-extension-ubuntu-dock                                0.9.1ubuntu18.04.3                              all          Ubuntu Dock for GNOME Shell
ii  gnome-shell-extensions                                           3.28.0-2                                        all          Extensions to extend functionality of GNOME Shell