Closed Bug 204671 Opened 17 years ago Closed 16 years ago

progress dialog on download is always on top


(SeaMonkey :: Download & File Handling, defect, major)

Not set


(Not tracked)



(Reporter: marcus, Assigned: Biesinger)


(Keywords: fixed1.5)


(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030401

If change the download manager to "Open a progress dialog" and download
anything, the download window always on top

Reproducible: Always

Steps to Reproduce:
1.Open Mozilla
2.Change download manager to "Open a progress dialog"
3.Download any file
4.Change focus to another mozilla window

Actual Results:  
Progress dialog always on top.

Expected Results:  
Progress dialog move to back
Attached image screenshot
The progress dialog is just marked dependent on its parent window.  Does your
window manager put all dependent windows on top all the time or something silly
like that?  (For that matter, what WM is this?)
The system is:
Red Hat 9
GNOME is a desktop environment, not a WM....
It's going to be an XP app problem.  They need to make it independent, assuming
that you don't want it to be a dialog.
Sorry, the WM is metacity
If i use the default "download manager" and download any file. When i change
focus to other mozilla window, the download manager go to back.
Summary: progress dialog always on top → progress dialog on download is always on top
Severity: normal → major
I have this problem too, using an up to date RH 9 installation, with the
Metacity window manager. I first noticed this somewhere in 1.2.x, but the RedHat
RPMs seemed to be free of this. I haven't seen any RPMs of 1.4.x from RedHat, so
I built them from the source RPM on
A response from the assigned developer would be nice, given that this report is
4 months old.
said developer does not currently work on the mozilla appsuite, to my knowledge
So shouldn't this be reassigned then? My last comment wasn't mailed to either
the assigned developer or the QA contact. That just seems wrong. I first noticed
this when I built RPMs using the 1.2.x src RPM from for use on RH 8,
which is when RH switched to Metacity. Perhaps this should be reported against
metacity in RH's bugzilla. There's already a bug against mozilla in RH's
bugzilla, which is assigned to Chris Blizzard (the same Chris on the CC list for
this bug?).

Given that the 1.2.x RPM from RH for RH 8 and 9 do not have this problem, I
tried looking at the patches applied in the src RPM. But I'm no mozilla hacker,
so that went nowhere pretty quick. 
Justin, there is in fact no one to assign this bug to -- no one is currently
working on this part of the code (the code is likely to not exist in Firebird,
and SeaMonkey UI development is rather scanty at the moment)...  Reassigning
anyway, for clarity's sake.

I just saw blizzard's comment, by the way.  This is a _dialog_ we are talking
about here.  See bug summary.  So it's marked dependent.  That's not changing.
Assignee: blake → nobody
Ah, ok then. The status of the bug led me to believe it was something that had a
chance of being worked on, which led to my frustration that it wasn't. Thanks
for clearing it up. :) Guess I'll finally look at firebird, although I'll miss
getting email notification in my browser without having the email client
explkicitly open.
Dialogs are on top of their main window, that's totally standard, both GNOME and
KDE do this (as well as Windows and Mac).
If you don't want it, you probably have a non-dialog. Download manager probably
isn't a dialog IMO, though a separate progress dialog may be.
Actually, I just rechecked the code and the progress dialog is NOT marked
dependent.  It's not even opened with openDialog; it's opened with openWindow,
and the window features "chrome,titlebar,minimizable=yes" are used.
So does that mean the WM should not keep it always-on-top by default? I tested
against sawfish, and this doesn't happen there. The same problem does exist with
Firebird 0.6, by the way, which I'm sure is no surprise.
Chris knows a lot more about WMs than I ever will, so he should be the one to
comment on the WM behavior here...
Someone should attach the output of "xprop" and "xwininfo" on the progress
window and the main window it won't go below. Then the WM authors can say more
definitively what the correct WM behavior is given the mozilla settings.

Should also test with KWin perhaps.
I have attached a tar file with two tar files, each with the xprop and xwininfo
output for the download progress window for Mozilla 1.4.0 and Mozilla Firebird
0.6. I tested Mozilla in KDE and the problem does not exist there.
firebird xprop.out shows TRANSIENT_FOR 0x3f, due to the low number of that
window ID, I bet it's the root window. If you set transient for the root window
it basically means "this is a dialog, keep it on top of the window group"
You can confirm the window ID of the root window by doing "xwininfo -root"

mozilla xprop.out shows no TRANSIENT_FOR hint, however it sets
_NET_WM_WINDOW_TYPE to DIALOG, which is equivalent to setting transient for the
root window (just marks dialog type, so stay on top of window group).

If this isn't a dialog, it shouldn't be marked as such...
I think the confusion is that people want it to look like a dialog, but not act
like one and I'm pretty sure that the two are intrinsically linked in X.
Well, to be honest, I never considered it a 'dialog' in the sense that it isn't
a critical use-this-interactively-now-before-doing-anything-else type of window.
I don't have to wait for the file to finish downloading to continue using the
browser/site. And as such, it seems logical that the process performed can be
'backgrounded' while I continue with what I was doing. A username/password
dialog for a restricted access site does not to be used before proceeding, so it
makes sense to be stuck on top of the browser window. Just my personal view on
the matter.
Chris is right, X (or more accurately, the window manager specs) doesn't really
support making up hybrid kinds of window. The question is really whether it's a
transient click-stuff-and-close window or a persistent window; also is it
associated with some toplevel; if it's persistent and standalone, I'd say don't
use type dialog, it's just a regular window.
This should just be a window.  Does using <window> instead of <dialog> in the
XUL actually help with that?  It better, since the caller does not open this as
a dialog....
taking to investigate whether <dialog>-><window> helps
Assignee: nobody → cbiesinger
so I was looking at the wrong file in comment 22 :( the progress dialog is
already a <window>

however, I poked around a bit and found the problem: It seems that by default,
opened windows are dialog=yes. Specifying dialog=no explicitly fixed the
problem. going to attach the patch.
Ever confirmed: true
Target Milestone: --- → mozilla1.6alpha
Attachment #132008 - Flags: review?(bz-vacation)
Awesome! Thanks. So this will copy over to Firebird as well?
I have no idea. depends if they forked embedding/components/ui/progressDlg; I
don't know if they have.
Comment on attachment 132008 [details] [diff] [review]

r=bzbarsky, but watch out for regressions on Windows and Mac... ;)

If Firebird has not forked this UI, they will soon, so this will need to be
tested separately for a Firebird build (and a separate bug filed if needed).
Attachment #132008 - Flags: review?(bz-vacation) → review+
Attachment #132008 - Flags: superreview?(jag)
<biesi> Hi, does someone here know if firebird forked mozilla's download
progress dialog?
<mconnor> biesi: actually, no, we didn't fork the dialog

so this patch will fix firebird as well.
sweet. Thanks for picking this back up guys. :D
Comment on attachment 132008 [details] [diff] [review]

Attachment #132008 - Flags: superreview?(jag) → superreview+
patch checked in.

Checking in nsProgressDialog.js;
/cvsroot/mozilla/embedding/components/ui/progressDlg/nsProgressDialog.js,v  <--
new revision: 1.32; previous revision: 1.31
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 132008 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to the 1.5 branch. Please add the
fixed1.5 keyword when this has landed. Time is short for 1.5 so this will need
to land pretty darned quickly if it's gonna make it. Thanks.
Attachment #132008 - Flags: approval1.5+
um, sure, checked in to 1.5 branch
Checking in nsProgressDialog.js;
/cvsroot/mozilla/embedding/components/ui/progressDlg/nsProgressDialog.js,v  <--
new revision:; previous revision: 1.30
Keywords: fixed1.5
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.