From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17 i686; en-US; 0.7) Gecko/20010105 BuildID: 2001010517 When downloading any file, the progress dialog ("Saving File" window) is forced to the top in the window Z-order (at least under X Windows), obscuring the view of any normal browser windows underneath, although non-Mozilla windows can be brought in front of the dialog. Reproducible: Always Steps to Reproduce: 1. Download a file. 2. Try to bring another browser window to the front. 3. Observe that the progress dialog remains in front. Actual Results: The progress dialog is always in front of normal browser windows. Expected Results: Window z-order should work normally for the progress dialog as with normal browser windows. (This is how Netscape Navigator 4.x works.)
This worksforme with linux build 2001-01-14-21 and AfterStep. What windowmanager are you using? Do you see this problem with other windowmanagers?
I'm using the Helix Gnome desktop with the Sawfish (v0.34) window manager. While the window manager might be part of the problem here, that doesn't mean that Mozilla might not be making a mistake. Is the dialog being marked as a transient window? That's the most likely reason for Sawfish to keep it raised, assuming the window manager is doing it. If it is being marked as transient, that should probably be reconsidered, since file downloads could take hours, which is hardly transient after all...
we have a bunch of sawfish bugs. and we already have normal bugs for this dialog (we know it's type is wrong). pick your complaint and stick w/ it. If a newer sawfish fixes your problem please resolve wfm, otherwise we can morph this bug _once_ to talk about transience.
I experimented with the Sawfish configuration. The problem is indeed because the progress dialog is a transient window, and Sawfish was configured to keep transient windows stacked above the parents. If I set it to "none", it doesn't happen. Netscape 4's download window is a small window, but it is NOT marked transient, and doesn't cause a problem regardless of the settings. If there's already a bug out there that says that the progress dialog shouldn't be transient, feel free to mark this bug as a duplicate of it.
17 years ago
ccing mpt and pavlov for their input on what the type of this dialog should be. Setting status to new and reassigning.
The download progress window should not be a dialog (unclosable, unminimizable, modal), it should be a progress window (unclosable, minimizable, non-modal). See bug 26029 for another problem from implementing the progress window as a dialog. AFAIK, XP Toolkit doesn't have a progressWindow type of window yet. A bug should be filed for that, which both bug 26029 and this bug should depend on.
17 years ago
This bug is now marked as depending on bug 67161, "Need `progress' type for windows."
I observe the same behavior on Mac OSX with Mozilla 0.9.2 (20010702 build). The file download window means I can't use all other Mozilla windows. So this is not just a problem with one window manager.
spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)
See http://bugzilla.gnome.org/show_bug.cgi?id=90590 and http://bugzilla.gnome.org/show_bug.cgi?id=83483 for independent discussion of why this change is probably right.
As of Mozilla 1.0, this bug is fixed. (Probably sometime earlier.)
Deven, you're talking about the dialog, not the download manager. Right?
Well, we probably shouldn't call it a dialog. After all, wasn't this bug the result of thinking of it as a dialog? (Dialogs are normally transient...) But yes, I'm talking about the single-file download progress window, not the multiple-file download manager. I just double-checked it, under Mozilla 1.0. This bug has been fixed in 1.0, if not earlier. Since I originally reported this bug, I've marked it as fixed; feel free to verify... In the process of double-checking, I stumbled across another bug, that the "Enter name of file to save to..." dialog is parented to the original browser window instead of the "Downloading <filename>" window. However, that appears to be the subject of bug 135736, so I'll discuss it there.
vrfy'ing per reporter.