65508 - Download progress dialog ["Saving File" window] shouldn't be a transient window

Status: VERIFIED FIXED

(Core Graveyard :: File Handling, defect)

Description

[Deven Corzine]

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

Comment 1

[Boris Zbarsky [:bzbarsky]]

This worksforme with linux build 2001-01-14-21 and AfterStep.

What windowmanager are you using?  Do you see this problem with other
windowmanagers?

Comment 2

[Deven Corzine]

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

Comment 3

[timeless]

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.

Comment 4

[Deven Corzine]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

ccing mpt and pavlov for their input on what the type of this dialog should be.
 Setting status to new and reassigning.

Comment 6

[Matthew T (active 1999-2002)]

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.

Comment 7

[Jesse Ruderman]

This bug is now marked as depending on bug 67161, "Need `progress' type for 
windows."

Comment 8

[Jimmy Sieben]

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.

Comment 9

[sairuh (rarely reading bugmail)]

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

Comment 10

[Havoc Pennington]

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.

Comment 11

[Deven Corzine]

As of Mozilla 1.0, this bug is fixed.  (Probably sometime earlier.)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Deven, you're talking about the dialog, not the download manager.  Right?

Comment 13

[Deven Corzine]

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.

Comment 14

[sairuh (rarely reading bugmail)]

vrfy'ing per reporter.