I noticed this, but it's only a problem on Linux. I've seen this same behavior on Linux before in other cases, so I assumed it was just a normal platform problem...
The dialog is 'dependent' on Windows, so this can't happen there. It's 'alwaysRaised' but not 'dependent' on Linux.
fwiw dependent should work fine on Linux too IIRC, from my early testing with bookmarks dialogs. it's on Mac that it's broken.
I think we deliberately didn't use dependent on Linux even though it would work...
This seems like a widget-level bug to me. We open the about dialog like this: window.openDialog("chrome://browser/content/aboutDialog.xul", "", "chrome,centerscreen"); and it calls nsIUpdatePrompt::checkForUpdate which just does: var openFeatures = "chrome,centerscreen,dialog=no,resizable=no,titlebar,toolbar=no"; Services.ww.openWindow(null, "chrome://mozapps/content/update/updates.xul", "", openFeatures, null); The second openWindow seems like it should result in the window opening above the about dialog, without any special action from the front-end code. Instead, the newly opened window is focused but not raised above.
Can you tell me which window manager is running here, please? Look for compiz or metacity in "xprop -root". Works as expected with kwin.
Compiz is the window-manager that's running when this is a problem. If I disable Compiz (switching to metacity) in the gnome-appearance-properties "effects" tab, then this switches to the correct behavior.
I guess that makes this a Widget:Gtk issue, even though focusing but not raising sounds like a compiz bug.
Ah -- so the problem seems to be just that the "About" window is always-on-top when I'm running Compiz. So the Software Update window probably tries to come to the foreground, but the "About" window won't let it. If I have a browser window open and the "About Minefield" "Software Update" dialogs open, then... - with metacity: whichever window I click will come to the foreground. - with compiz: The "About" dialog insists on **always** being on top of the other two. I can interact with the other two (i.e. type into this bug page), so it's not modal exactly -- it's just "on top".
(Comment 11 is true for just the browser window + "About Minefield", too -- the Software Update dialog doesn't need to be involved. It's just a new way for this About-dialog-always-being-on-top issue to cause pain.)
This issue ("About" window wanting to be on top) goes back at least as far as Firefox 3.5, on my system. Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:220.127.116.11) Gecko/20100701 Firefox/3.5.11
At Karl's suggestion, I ran xprop and clicked on the "About" window, and compared the output vs. the Software Update window & the Preferences windows. It looks like the only significant difference is: about dialog: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG other windows: _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL So, as gavin surmised in IRC: "it appears that our "dialog" flag triggers _NET_WM_WINDOW_TYPE_DIALOG, which triggers always-on-top?"
FWIW, I've confirmed that the Preferences & Software Update windows use Compiz's "Open Window"/"Close Window" animations to open up, whereas the "About" dialog does not. (It just pops into & out of existence -- with no animations -- on my system.) Beyond that, I don't know if there are any behavioral differences between TYPE_DIALOG vs TYPE_NORMAL from comment 14.
(In reply to comment #14) > So, as gavin surmised in IRC: "it appears that our "dialog" flag triggers > _NET_WM_WINDOW_TYPE_DIALOG, which triggers always-on-top?" This is legitimate: 'If the features parameter is a zero-length string, or contains only one or more of the behaviour features (chrome, dependent, dialog and modal) the chrome features are assumed "OS' choice." That is, window creation code is not given specific instructions, but is instead allowed to select the chrome that best fits a dialog on that operating system.' -- https://developer.mozilla.org/en/DOM/window.openDialog#Default_behaviour We'd have to specify alwaysRaised=no, but we actually only support this chrome feature on Windows, I think. So the other option is to make the window dependent like it is on Windows.
Created attachment 476500 [details] [diff] [review] patch Epiphany actually does the same.
Epiphany does the same, but any windows it spawns (by clicking the credits or license buttons) appear as always on top of the about window itself, so it's not a problem.
(In reply to comment #18) > Epiphany does the same, but any windows it spawns (by clicking the credits or > license buttons) appear as always on top of the about window itself, so it's > not a problem. I'm saying it does the same as Firefox would with my patch.
Hm -- it looks like "Check For Updates" button & dialog doesn't exist anymore. (Help|About automatically checks for & downloads the update now, and gives you an "Apply Update" button) Does that affect the necessity / applicability of this bug's patch? (Is there any remaining way to make the old "Check for Updates" dialog show up and reproduce this bug now?)
There are a couple of cases where we still need to open the update window so it is still a problem for those cases.