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

RESOLVED FIXED in Firefox 4.0b7

Status

()

Firefox
General
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: dao, Assigned: dao)

Tracking

Trunk
Firefox 4.0b7
All
Linux
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(2 attachments)

(Assignee)

Description

7 years ago
Created attachment 475481 [details]
screenshot
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...
(Assignee)

Comment 2

7 years ago
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.
(Assignee)

Comment 4

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

Updated

7 years ago
blocking2.0: --- → ?
blocking2.0: ? → betaN+

Updated

7 years ago
Duplicate of this bug: 597381
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.

Updated

7 years ago
Duplicate of this bug: 597528
Can you tell me which window manager is running here, please?
Look for compiz or metacity in "xprop -root".
Works as expected with kwin.
Summary: "Check for Updates..." opens the Update dialog behind the About window → "Check for Updates..." opens the Software Update dialog behind the About window
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.
Component: General → Widget: Gtk
Product: Firefox → Core
QA Contact: general → gtk
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:1.9.1.11) Gecko/20100701 Firefox/3.5.11
Summary: "Check for Updates..." opens the Software Update dialog behind the About window → With Compiz, "About Firefox" dialog is always-on-top. (so the new "Check for Updates..." button makes Software Update dialog open behind it)
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.
(Assignee)

Comment 16

7 years ago
(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.
Component: Widget: Gtk → General
Product: Core → Firefox
QA Contact: gtk → general
Summary: With Compiz, "About Firefox" dialog is always-on-top. (so the new "Check for Updates..." button makes Software Update dialog open behind it) → "Check for Updates..." opens the Software Update dialog behind the About window
(Assignee)

Comment 17

7 years ago
Created attachment 476500 [details] [diff] [review]
patch

Epiphany actually does the same.
Assignee: nobody → dao
Status: NEW → ASSIGNED
Attachment #476500 - Flags: review?(gavin.sharp)

Comment 18

7 years ago
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.
(Assignee)

Comment 19

7 years ago
(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.
Attachment #476500 - Flags: review?(gavin.sharp) → review+
(Assignee)

Updated

7 years ago
Keywords: checkin-needed
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.
(Assignee)

Comment 22

7 years ago
http://hg.mozilla.org/mozilla-central/rev/e22b56f3fcf8
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b8
(Assignee)

Updated

7 years ago
Target Milestone: Firefox 4.0b8 → Firefox 4.0b7
You need to log in before you can comment on or make changes to this bug.