Closed Bug 204671 Opened 17 years ago Closed 16 years ago
progress dialog on download is always on top
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
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 WM is GNOME.
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
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 ftp.mozilla.org.
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 mozilla.org 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?). https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=88064 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.
maybe this bug is due to the fact that http://lxr.mozilla.org/seamonkey/source/embedding/components/ui/helperAppDlg/nsHelperAppDlg.xul is a <dialog> instead of a <window>
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.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → mozilla1.6alpha
16 years ago
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] patch 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+
16 years ago
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] patch sr=jag
Attachment #132008 - Flags: superreview?(jag) → superreview+
patch checked in. Checking in nsProgressDialog.js; /cvsroot/mozilla/embedding/components/ui/progressDlg/nsProgressDialog.js,v <-- nsProgressDialog.js new revision: 1.32; previous revision: 1.31 done
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment on attachment 132008 [details] [diff] [review] patch 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 <-- nsProgressDialog.js new revision: 18.104.22.168; previous revision: 1.30 done
You need to log in before you can comment on or make changes to this bug.