204671 - progress dialog on download is always on top

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, defect)

Description

[Marcus Grando]

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

Comment 1

[Marcus Grando]

Attachment: screenshot

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Marcus Grando]

The system is:
Red Hat 9
WM is GNOME.

Comment 4

[Boris Zbarsky [:bzbarsky]]

GNOME is a desktop environment, not a WM....

Comment 5

[Christopher Blizzard (:blizzard)]

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.

Comment 6

[Marcus Grando]

Sorry, the WM is metacity

Comment 7

[Marcus Grando]

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.

Comment 8

[justin]

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.

Comment 9

[justin]

A response from the assigned developer would be nice, given that this report is
4 months old.

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

said developer does not currently work on the mozilla appsuite, to my knowledge

Comment 11

[justin]

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. 

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[justin]

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.

Comment 14

[Havoc Pennington]

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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

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.

Comment 16

[justin]

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Chris knows a lot more about WMs than I ever will, so he should be the one to
comment on the WM behavior here...

Comment 18

[Havoc Pennington]

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.

Comment 19

[justin]

Attachment: xprop and xwininfo for progress dialog

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.

Comment 20

[Havoc Pennington]

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

Comment 21

[Christopher Blizzard (:blizzard)]

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.

Comment 22

[Christian :Biesinger (don't email me, ping me on IRC)]

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>

Comment 23

[justin]

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.

Comment 24

[Havoc Pennington]

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.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Christian :Biesinger (don't email me, ping me on IRC)]

taking to investigate whether <dialog>-><window> helps

Comment 27

[Christian :Biesinger (don't email me, ping me on IRC)]

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.

Comment 28

[Christian :Biesinger (don't email me, ping me on IRC)]

Attachment: patch

Comment 29

[justin]

Awesome! Thanks. So this will copy over to Firebird as well?

Comment 30

[Christian :Biesinger (don't email me, ping me on IRC)]

I have no idea. depends if they forked embedding/components/ui/progressDlg; I
don't know if they have.

Comment 31

[Boris Zbarsky [:bzbarsky]]

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

Comment 32

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 33

[justin]

sweet. Thanks for picking this back up guys. :D

Comment 34

[jag (Peter Annema)]

Comment on attachment 132008 [details] [diff] [review]
patch

sr=jag

Comment 35

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 36

[Asa Dotzler [:asa]]

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.

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

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: 1.30.8.1; previous revision: 1.30
done