GNOME Bugzilla – Bug 749711
cannot move unresponsive windows
Last modified: 2015-05-22 15:48:30 UTC
An application that is not tending to its X11 events properly will no longer be able to be moved around because of CSD. Easily reproduced: 1. Start gnome-calculator 2. Send SIGSTOP to it. 3. Try to move it. CSD is perty and all that, but it wreaks havoc on robustness.
Created attachment 303822 [details] [review] window: Fix meta_window_set_alive() not working if first ping fails window->is_alive isn't initialized explicitly so it defaults to FALSE meaning that if the first ping fails we'd short circuit and not show the delete dialog as we should. We could initialize the variable to TRUE but in fact we don't even need the variable at all since our dialog management is enough to manage all the state we need, i.e. we're only interested in knowing whether we're already displaying a delete dialog.
(In reply to Rui Matos from comment #1) > We could initialize the variable to TRUE but in fact we don't even > need the variable at all since our dialog management is enough to > manage all the state we need, i.e. we're only interested in knowing > whether we're already displaying a delete dialog. Are we? If the delete dialog is closed by the user clicking "Wait", after applying the patch we pop up the dialog again after the next failed ping - as far as I can see, that's a change from the current behavior (which isn't necessarily wrong, but we shouldn't just do so accidentally)
Created attachment 303825 [details] [review] window: Fix meta_window_set_alive() not working if first ping fails window->is_alive isn't initialized explicitly so it defaults to FALSE meaning that if the first ping fails we'd short circuit and not show the delete dialog as we should. We could initialize the variable to TRUE but in fact we don't even need the variable at all since our dialog management is enough to manage all the state we need, i.e. we're only interested in knowing whether we're already displaying a delete dialog. This does change our behavior here since previously we wouldn't display the dialog again if the next ping failed after the dialog is dismissed but this was arguably a bug too since in that case there wouldn't be a way to kill the window after waiting for a while and the window kept being unresponsive. -- (In reply to Florian Muellner from comment #2) > Are we? If the delete dialog is closed by the user clicking "Wait", > after applying the patch we pop up the dialog again after the next > failed ping - as far as I can see, that's a change from the current > behavior (which isn't necessarily wrong, but we shouldn't just do so > accidentally) Indeed that's a behavior change that I didn't intend. But I'd say it was a bug too, see the expanded commit message above.
Review of attachment 303825 [details] [review]: OK
Attachment 303825 [details] pushed as b39c00f - window: Fix meta_window_set_alive() not working if first ping fails