GNOME Bugzilla – Bug 729786
A hung GTK application cannot be closed
Last modified: 2018-05-02 09:33:09 UTC
KWin implements the ping protocol like described in http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140146176692592 after sending a WM_DELETE_WINDOW. Thus KWin can only detect hung clients which it tried to close. This does no longer work with the client-side-decorated GTK applications as there is no close button provided by the window manager. Steps to reproduce 1. Run KWin 2. Run gtk3-demo from a Konsole 3. Press ctrl+z in Konsole 4. try to close the window by clicking the close button Actual result: nothing Expected result: KWin shows the dialog for hung applications. Note: this affects our stable release 4.11 which got released in July 2013. We cannot adjust this version as sending more pings would be a new feature and the dialog shown for hung applications is explicitly stating that the user tried to close the window. With CSD one doesn't know that the user tried to close the window, thus the dialog would need a rewording which is not possible as the language is frozen.
I think compositors should always detect unresponsive applications, not just in response to close.
(In reply to comment #1) > I think compositors should always detect unresponsive applications, not just in > response to close. well we don't and thus it affects our stable release. The NETWM spec is quite clear that it's only intended after a DELETE request. Thus we don't know how a client would respond to that. It's possible that it only expects it after getting a DELETE request. This would need an update to the NETWM spec to cover the usecase. Also I don't understand why you think that compositors should always detect that. It has never been a problem and we support compositing now since 2008.
>> I think compositors should always detect unresponsive applications, not just in >> response to close. > well we don't and thus it affects our stable release. The NETWM spec is quite > clear that it's only intended after a DELETE request. Thus we don't know how a > client would respond to that. First of all, the compositor should not mess with the _NET_WM_PING protocol at all, it's for the windowmanager and has little to no relation to the compositor. Second, actually: "A Window Manager can use this protocol at any time" "A participating Client receiving this message MUST send it back to the root window immediately" Just that 3rd there's also little reason to play ping pong on the X11 server for no actual cause and then annoy the user with an offer to kill a client out of the void. Anybodies personal opinion on this does really not matter, the specification doesn't mandate any particular behavior, so fact remains that if a user tries to close a window with a CSD on a stopped or hung process, he simply won't be able to do and we won't be able to detect this wish and offer him a kill instead. At "best", we could ping all clients every 10 seconds and popup kill dialogs into the users face - which he hopefully doesn't confirm accidentally then... (i'd then immediately file a bug for an option to disable such silly behavior)
> I think compositors should always detect unresponsive applications, not just in > response to close. I partially take this back. I thought mutter does this, but it turns out it doesn't, actually. Its behavior for non-responsive clients is pretty bad, actually. Regardless whether they are csd or not.
mutter sends out a ping whenever activating a window, either with Alt+Tab, mouse focus or click-to-focus.
(In reply to comment #3) > First of all, the compositor should not mess with the _NET_WM_PING protocol at > all, it's for the windowmanager and has little to no relation to the > compositor. Compositor, here, was used in the "compositing window manager" sense. Since mutter is both the compositor and window manager, and the terminology is "compositor" in Wayland, the two are often used interchangeably in GNOME. Sorry for the confusion.
> mutter sends out a ping whenever activating a window Interesting. How do you catch a client that freezes while it's active (eg. because the user interacted with it)? Or do you ping on close attempts as well?
(In reply to comment #7) > > mutter sends out a ping whenever activating a window > Interesting. > How do you catch a client that freezes while it's active (eg. because the user > interacted with it)? We apparently don't right now. We could do it on clicks, since we take a passive grab on the window that we replay, or we could do it any time we update _NET_WM_USER_TIME. > Or do you ping on close attempts as well? We do that also.
Does it at least work when trying to close the window with Alt+F4 or a WM shortcut?
(In reply to comment #9) > Does it at least work when trying to close the window with Alt+F4 or a WM > shortcut? Alt + F4 works, but one cannot call that a solution as users don't know that shortcut.
OK. I was checking to see if we were actually treating _NET_WM_PING events properly. Well, it's obvious that if our application is hung, we can't really respond to click events. What would you like to see us do?
(In reply to comment #11) > OK. I was checking to see if we were actually treating _NET_WM_PING events > properly. fair enough :-) > > Well, it's obvious that if our application is hung, we can't really respond to > click events. What would you like to see us do? This one is difficult and to me a deal breaker (unfortunately). A possible solution might be to expose the geometry of the close button and the window manager to install a passive grab on the window to check whether the close button got clicked and send it a ping. That would though require quite some changes in existing window managers. To me it looks like there will be a bunch of properties a window manager needs to support and if one of them is missing GTK shouldn't use client side decorations. To be quite honest: the broken close brings me very close to enforce server side decorations for GTK+ windows. We have a strong "form follows functionality" approach and as I said: not being able to close hung applications is a deal breaker to me.
(In reply to comment #12) > This one is difficult and to me a deal breaker (unfortunately). A possible > solution might be to expose the geometry of the close button and the window > manager to install a passive grab on the window to check whether the close > button got clicked and send it a ping. That would though require quite some > changes in existing window managers. Why can't you always send the ping in your passive grab that you use to raise the window, like we do?
(In reply to comment #13) > > Why can't you always send the ping in your passive grab that you use to raise > the window, like we do? That would require us to completely rework the message we show or introduce a different dedicated one. Right now it's just for closing: "You tried to close window..."
And it increases likelihood of false positives (I/O pending or simply stopped clients) And we bother the client with useless chat (as it's completely irrelevant whether it is responsive in this condition) And, most important: what about the active client (where we do not hold an unmodified passive grab to not accidentally "confuse" the client of main interaction)?
*** Bug 734919 has been marked as a duplicate of this bug. ***
We're migrating the GTK bug tracking to GitLab! Sadly, importing this bug breaks the python-bugzilla module in weird ways, so we'll have to migrate it manually; I've opened issue: https://gitlab.gnome.org/GNOME/gtk/issues/215 and copied the description and comments there, and left a link back to this bug. Thanks for your patience.