When you click the close button on a window, the window can have a hint on it which tells the window manager not to close it immediately. Instead, it should ask the window to close itself, and if the window doesn’t respond within a certain amount of time, it should put up a dialogue box which asks whether to kill the process which owns the window.
At present, this amount of time is fixed in Metacity to 2.25 seconds.
GNOME bug 121934 suggests that this timeout could be different in some cases:
- If the window usually takes “a long time to exit”. This would require window matching.
- Generally, because 2.25 seconds is too short a time to wait. On the other hand, if it was much longer, the user might have forgotten closing the window and would be surprised by the “force quit” dialogue.
- When the system is under heavy load, so the program is less likely to be able to respond.
Photo © rwangsa, cc-by-nc-nd.
3 thoughts on “Squib of the day: quit timeout”
The only program I recall seeing this message from is Firefox, where it happens quite frequently. No idea why, but closing FF always seems to take a few seconds, so it’s often over that 2.25 second threshold.
well even nautilus triggers this often on my computer, a very slow old one. And Epiphany as well, but it deserves to be force quit anyway since it can’t quit itself properly.
I see it a bit with big programs if the computer is busy: firefox, eclipse and open office mostly. But, it does let you wait. I don’t think it’s too bad as it is. 2.25 is something of an odd number though :)
What is more annoying, although probably not reasonably able to be controlled by the WM, is when you click ‘close’ and the program doesn’t because it’s stuck in a way that leaves the GUI loop active, so you don’t get the option of closing it without a command line kill or xkill. I guess what is happening there is that it’s acknowledging the close but not actually closing because it’s waiting on the stuck thread to finish. Fortunately this is fairly rare.