Red Hat Bugzilla – Bug 77442
dialogs disappear behind windows too easily
Last modified: 2007-04-18 12:48:11 EDT
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: When autoraise is enabled, I frequently find that blocking dialogs disappear behind windows. For example, in galeon, if I click on the "close window" button when I have a bunch of tabs open, a dialog pops up asking if I really want to do this. If I move the cursor from the close button to the dialog too slowly, the dialog window disappears behind the main galeon window, obeying some generic autoraise rule. This is pretty annoying because you then have to go mouse hunting for the hidden window. It's even worse when a blocking popup disappears without you noticing it; galeon or whatever becomes unresponsive and you are fooled into thinking that it has crashed. For some reason, this was never a problem with sawfish. I think metacity would be improved if it adopted the sawfish blocking popup algorithm. Note: I changed one or two of the sawfish default options but I'm not sure that this affected its blocking popup behavior. Version-Release number of selected component (if applicable): RedHat 8.0 How reproducible: Always Steps to Reproduce: Additional info:
this probably happens less or never with newer metacity; try experimental 2.4.3 from ftp://people.redhat.com/hp/gnomehide/ if you want. though in some cases there may be an application bug anyhow (dialogs without a transient parent set, "xprop | grep TRANSIENT")
This is fixed I'm pretty sure, except for apps that don't set TRANSIENT_FOR but that's an app bug.
I updated to redhat 9 and it looks like popups still are disappearing far more often than the do in sawfish. For example, when I run up2date and the root login password popup pops up, it immediately dives behind any open windows as soon as I move the mouse.
The root dialog popup appears as a totally unrelated window to any other windows to metacity. metacity has no way of knowing that it should be kept on top. It could set _NET_WM_STATE_ABOVE perhaps, but this has to be done in usermode, not in metacity. What you need to do is file bugs against specifics apps where this is a problem, metacity is doing what it can with the info the apps provide. CC me on the bugs if the app authors need help knowing what to change.