596562 - "Check for Updates..." opens the Software Update dialog behind the About window

Status: RESOLVED FIXED

(Firefox :: General, defect)

Description

[Dão Gottwald [:dao]]

Attachment: screenshot

Comment 1

[:Gavin Sharp [email: [e-mail]]]

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...

Comment 2

[Dão Gottwald [:dao]]

The dialog is 'dependent' on Windows, so this can't happen there. It's 'alwaysRaised' but not 'dependent' on Linux.

Comment 3

[Marco Bonardo [:mak]]

fwiw dependent should work fine on Linux too IIRC, from my early testing with bookmarks dialogs. it's on Mac that it's broken.

Comment 4

[Dão Gottwald [:dao]]

I think we deliberately didn't use dependent on Linux even though it would work...

Comment 6

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 8

[Karl Tomlinson (:karlt)]

Can you tell me which window manager is running here, please?
Look for compiz or metacity in "xprop -root".
Works as expected with kwin.

Comment 9

[Daniel Holbert [:dholbert]]

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.

Comment 10

[Karl Tomlinson (:karlt)]

I guess that makes this a Widget:Gtk issue, even though focusing but not raising sounds like a compiz bug.

Comment 11

[Daniel Holbert [:dholbert]]

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 12

[Daniel Holbert [:dholbert]]

(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.)

Comment 13

[Daniel Holbert [:dholbert]]

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:1.9.1.11) Gecko/20100701 Firefox/3.5.11

Comment 14

[Daniel Holbert [:dholbert]]

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?"

Comment 15

[Daniel Holbert [:dholbert]]

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.

Comment 16

[Dão Gottwald [:dao]]

(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.

Comment 17

[Dão Gottwald [:dao]]

Attachment: patch

Epiphany actually does the same.

Comment 18

[Brian Marshall]

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.

Comment 19

[Dão Gottwald [:dao]]

(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.

Comment 20

[Daniel Holbert [:dholbert]]

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?)

Comment 21

[Robert Strong (they/them - no direct email)]

There are a couple of cases where we still need to open the update window so it is still a problem for those cases.

Comment 22

[Dão Gottwald [:dao]]

http://hg.mozilla.org/mozilla-central/rev/e22b56f3fcf8