The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in Future

Status

Core Graveyard
File Handling
VERIFIED FIXED
16 years ago
9 months ago

People

(Reporter: Deven Corzine, Assigned: Ben Goodger (use ben at mozilla dot org for email))

Tracking

(Depends on: 1 bug)

Trunk
Future
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sawfish])

(Reporter)

Description

16 years ago
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?
(Reporter)

Comment 2

16 years ago
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

16 years ago
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.
Whiteboard: [sawfish]
(Reporter)

Comment 4

16 years ago
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.
Summary: Download progress dialog ["Saving File" window] shouldn't always be on top → Download progress dialog ["Saving File" window] shouldn't be a transient window
Assignee: asa → ben
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps: GUI Features
Ever confirmed: true
QA Contact: doronr → sairuh
ccing mpt and pavlov for their input on what the type of this dialog should be.
 Setting status to new and reassigning.

Comment 6

16 years ago
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.
Depends on: 67161

Comment 7

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

Updated

16 years ago
Keywords: nsbeta1-
Target Milestone: --- → Future

Comment 8

16 years ago
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. :)
Component: XP Apps: GUI Features → File Handling

Comment 10

15 years ago
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.
(Reporter)

Comment 11

15 years ago
As of Mozilla 1.0, this bug is fixed.  (Probably sometime earlier.)
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Deven, you're talking about the dialog, not the download manager.  Right?
(Reporter)

Comment 13

15 years ago
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.