Last Comment Bug 65508 - Download progress dialog ["Saving File" window] shouldn't be a transient window
: Download progress dialog ["Saving File" window] shouldn't be a transient window
Status: VERIFIED FIXED
[sawfish]
:
Product: Core Graveyard
Classification: Graveyard
Component: File Handling (show other bugs)
: Trunk
: x86 Linux
: -- normal (vote)
: Future
Assigned To: Ben Goodger (use ben at mozilla dot org for email)
: sairuh (rarely reading bugmail)
:
Mentors:
Depends on: 67161
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-15 09:46 PST by Deven Corzine
Modified: 2016-06-22 12:16 PDT (History)
4 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Deven Corzine 2001-01-15 09:46:33 PST
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 [:bz] (still a bit busy) 2001-01-15 10:17:35 PST
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 2001-01-15 10:55:31 PST
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 2001-01-15 11:01:10 PST
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 2001-01-15 11:06:13 PST
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 [:bz] (still a bit busy) 2001-01-15 11:19:01 PST
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 Paul Thomas 2001-01-15 19:34:38 PST
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 2001-02-27 16:50:02 PST
This bug is now marked as depending on bug 67161, "Need `progress' type for 
windows."
Comment 8 Jimmy Sieben 2001-07-03 08:49:14 PDT
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) 2001-10-09 15:04:11 PDT
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 2002-08-18 15:10:48 PDT
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 2002-08-23 06:59:56 PDT
As of Mozilla 1.0, this bug is fixed.  (Probably sometime earlier.)
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2002-08-26 15:54:50 PDT
Deven, you're talking about the dialog, not the download manager.  Right?
Comment 13 Deven Corzine 2002-08-27 06:41:47 PDT
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) 2002-09-19 12:43:22 PDT
vrfy'ing per reporter.

Note You need to log in before you can comment on or make changes to this bug.