Closed Bug 26029 Opened 24 years ago Closed 23 years ago

Download progress dialog [Saving File window] is not minimizable


(SeaMonkey :: UI Design, defect, P2)

Windows 98


(Not tracked)



(Reporter: henrik, Assigned: law)


(Depends on 1 open bug, Blocks 1 open bug, )


(Keywords: helpwanted, Whiteboard: will take for 0.8.1)


(3 files)

When downloading on windows 98 the saving file dialog/window doesn't contain a
minimize widget in the title bar and therefor cannot be minimized.
Moving UE/UI component bugs over to new User Interface: Design Feedback 
component.  UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
I don't think a save file should have a minimize icon at all. 
reassign it to german to take a look in similar cases whthin the entire app than 
make final descision. 
Assignee: shuang → german
I was just reading over this bug and i was confused by which dialog you're 
talking about. There's the dialog that pops up when you click on a link to 
download a file (the one that lets you choose between save file and pick app...) 
and the one that actually shows the file download progress. I would think that 
any dialog that would spend a long time open should have a minimize button so a 
user could clear it off their desktop if they wanted to. The download progress 
window had a minimize button in netscape 4.x the choice window does not and 
should not. 

I'm adding myself to the CC list because it's an item that the average user 
would notice. I'm taking a look at all the small bugs that casual users would 
notice as "internet explorer does it better" and making sure they're all working 
right before beta 1 or 2.
*** Bug 32061 has been marked as a duplicate of this bug. ***
*** Bug 32373 has been marked as a duplicate of this bug. ***
*** Bug 33628 has been marked as a duplicate of this bug. ***
*** Bug 32061 has been marked as a duplicate of this bug. ***
*** Bug 32061 has been marked as a duplicate of this bug. ***
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas (

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to
QA Contact: elig → mpt
This is Windows only, and involves windowing controls ... Another one for 
QA Contact: mpt → claudius
*** Bug 37501 has been marked as a duplicate of this bug. ***
*** Bug 38266 has been marked as a duplicate of this bug. ***
This should be so on all platforms and not only windows
As I understood it, the bug is about the Saving File Dialog (which should be 
consistant with the other Saving dialogs in the app), not the Downloading dialog 
( which probably should have a minimize button. 
Lynggaard, can you confirm or explain the bug in more detail? 
I think this is about the downloading file safe file dialog. The one which 
stays there all the time the file is being downloaded.
*** Bug 38505 has been marked as a duplicate of this bug. ***
*** Bug 41902 has been marked as a duplicate of this bug. ***
this bug, as the reporter originally intended, is about the file download dialog. It should be minimizable and definitely was in 4.x. 
I'm reassigning this bug and changing the component.
Assignee: german → law
Component: User Interface: Design Feedback → XP Apps: GUI Features
Keywords: 4xp
QA Contact: claudius → sairuh
Summary: saving file window cannot be minimized → downloading file window cannot be minimized
*** Bug 47560 has been marked as a duplicate of this bug. ***
*** Bug 48368 has been marked as a duplicate of this bug. ***
*** Bug 48362 has been marked as a duplicate of this bug. ***
Given the number of duplicates for this bug that keep appearing, how about some
progress getting it fixed (if only for the reduced bug reports that will result,
if not the actual bug severity) :-)
12 duplicates => mostfreq
Keywords: mostfreq
Come on, this is one simple windows API flag!

Marking nsbeta3. This should be an easy fix, but we NEED it for user satisfaction.

If we don't provide it, then we're going to have people berating mozilla openly
about this (as already shown by 12 dups => mostfreq).
Well, in downloadProgress.xul the window is defined as class="dialog".  Where is 
this class interpreted, though?
Sorry for the spam.  For some reason I was looking in the layout directory 
instead of the widget directory.
That class on the window element, is used to give it CSS style. I believe that
the actual place that this is launched is

with flags "chrome,titlebar" (although I could be wrong about that).
What is the status of this bug? What happened to the nsbeta3 Mark? This is
mostfreq and doesn't seem that hard to implement...
I don't think this ever had keyword nsbeta3.

So that means its turn hasn't come.  I'm not sure how hard it is to implement.  
I am not sure the toolkit supports a minimizable dialog.
A progress window shouldn't be a dialog at all. It should be a different kind of 
window altogether -- one which can be minimized/shaded, but not closed or
maximized/zoomed, using standard window widgets.
When I asked about the beta 3 mark I was referring to's comment
on 2000-09-10 The line reads ...

"... Marking nsbeta3. This should be an easy fix, but we NEED it for user

Where is this mark? Why would it have been removed without notice?
Matthew:  That's what I meant :-).  It isn't a "regular" window (like navigator,
mail, composer); thus my use of the term "dialog."  I'm not sure "dialog" means
anything specific aside from that (although the term can certainly have specific
connotation in certain contexts).

In other words, I'm not sure the toolkit supports another kind of window
altogether, that is minimizable.  I'll try to look into that.  There is no JS
"feature" flag on by which one can specify "minimizable."  So it
would have to be a XUL extension and I'm not sure what that would entail.  Maybe
it's done and we just need to find out how to do it.  I'm cc:'ing danm because
he would know.

Mike: the comment says that, but the bug activity (click on the "View Bug
Activity" link above) doesn't show it.  If it had been nominated, we would have
added a comment that noted that we were blowing this off for PR3 (rather than do
it covertly).
*** Bug 59412 has been marked as a duplicate of this bug. ***
An aside on terminology...
Matt, there's nothing preventing a dialog, at least in Windows terms, from 
having a minimize button and being non-modal.
This bug has been around for almost a year now, netscape 6 is out. There were 
13 duplicates, and 10 votes for this bug... It's now a step back to the 
netscape 1.x days when there wasn't even a dialogue for download progress... 
Why wasn't this fixed?
To clear up any possible confusion, I've attached a screen shot of the download
progress dialog that does not have a minimize button in Mozilla. This dialog
appears after selecting "Save As..." over a link or when clicking links in an
FTP directory.

Once this is minimizable it would be really nice to do what IE 5 is doing with
the titlebar. It updates the title of the dialog as the percentage changes. This
directly relates to what is shown on the Taskbar so you can track the progress
just from the minimized taskbar item. I'll log a RFE on this.
Blocks: 35046
Looks like Blake beat me to it. See bug 35046 about showing download progress
(%) in title when minimized.

[This bug does not need to be fixed in order for bug 35046 to be fixed. Removing 
No longer blocks: 35046
[Oh, wait, yes it does. Aaargh. Dreadfully sorry. Restoring dependency. I'll go 
flagellate myself now.]
Blocks: 35046
*** Bug 62215 has been marked as a duplicate of this bug. ***
*** Bug 62259 has been marked as a duplicate of this bug. ***
*** Bug 62829 has been marked as a duplicate of this bug. ***
Geez...I sometimes have to ask myself why I run Mozilla.  When it takes this
long for a very basic bug like this to be fixed there must be something horribly
wrong with the toolkit being used.

Corey: It's not a bad toolkit, it's just that we have plenty of other, more 
important bugs to fix first. Patches welcome though! :-)
Keywords: mozilla0.9, nsbeta1
That depends on your definition of important. Did you know that, currently, 
this bug is the 30th most voted for bug. It also isn't an rfe like most of the 
*** Bug 63129 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
Summary: downloading file window cannot be minimized → saving file window cannot be minimized
[Restoring summary. Referring to the download progress window as the `saving file 
window' caused a lot of confusion during the first four months of this bug, which 
is why the summary was changed in the first place.]
Summary: saving file window cannot be minimized → Download progress window cannot be minimized
Nearly half of the dupes are with the secondary summary, so it is obviously not 
much clearer.  The body of the bug and the assignee are clear about which 
dialog is in question, there is even a pretty picture of the problem.
Summary: Download progress window cannot be minimized → Download progress dialog [Saving File window] is not minimizable
cc:ing self
cc:ing self
Please wake me if your done, just kidding!
I just noticed I'd been paged on this bug. law: as you noticed, no, there is no 
separate features flag for opening a window minimizable independent 
of being resizable. I suppose there's nothing for it but to add Yet Another.
Netscape Nav triage team: this is a Netscape beta stopper. Changing priority to 
Priority: P3 → P2
Blocks: 38505
*** Bug 64537 has been marked as a duplicate of this bug. ***
So is this the ability to apply the eBorderStyle_minimize border style to a 
dialog from JS, or is it time I go to bed?
Setting target milestone.
Target Milestone: --- → mozilla0.8
this bug will be one year old tomorrow - happy birthday (is this really so

Suggest to have minimized download window as a small icon in the taskbar (next
to clock) to reduce taskbar clutter on multiple downloads. The icon should show
the percentage complete and when hovered over, the filename as tooltip (like
Depends on: 67161
Target Milestone: mozilla0.8 → ---
this should at least have a target milestone of 1.0 since it is a highly visible
feature (multiple windows all over the desktop). It also affect usability of
mozilla and other applications.
BTW, just look at the number of people on the CC list and you get an impression
of how important this bug is to the users.
Peter, if you think this bug should be fixed soon, then fix it yourself, or find 
a programmer to do it for you. Otherwise, please shut up and stop spamming this 
bug with useless comments. Thankyou.
*** Bug 67400 has been marked as a duplicate of this bug. ***
*** Bug 67401 has been marked as a duplicate of this bug. ***
I just noticed that the little "dialog" that comes up when a profile is being
migrated can be minimized.  Can we just do something like that for now?
Adding CC. My apologies for the spam
The current alternatives are to make the window fully "resizable" (sizing 
borders, min, and max buttons) or not resizable at all.  To change that 
requires modifying nsWindowWatcher, 
nsAppShellService::JustCreateTopLevelWindow, and who knows what under 

My proposal is to support a new "minimizable" feature on window.openDialog that 
can be set independently of "resizable" (although maybe just "min" would be 
better for the spelling- or typing-impaired).

Oh, if we can't get that feature added, then we can always add sizing borders 
and a max button, too.  I'm presuming that's not acceptable (but who knows).
Target Milestone: --- → mozilla0.9
So what if, in the short-term, this window is resizable?  I'd take that if it
also gives me the ability to minimize it.
I would have thought it'd be more complicated, but I guess the support was nearly 
already there. Couple of comments:

The diff for nsAppShellService is in there twice. The diff for 
nsIWebBrowserChrome.idl is missing. But I know what that must look like.

One thing. Could you move the

+    if (aChromeMask & nsIWebBrowserChrome::CHROME_WINDOW_MIN) {
+      widgetInitData.mBorderStyle = NS_STATIC_CAST(enum nsBorderStyle, 
widgetInitData.mBorderStyle | 
eBorderStyle_minimize );
+    } 

clause in nsAppShellService up a couple of lines, into the else clause of (chrome 
== CHROME_ALL) (line 896?). That's where all the rest of the window border 
widgets are handled. It won't make much of a practical difference, but at least 
they're all grouped together that way.

Oh, you did this


a couple of times. Wants to be a comma, not a period.

With the caveats mentioned above, r=me.
Moving up target milestone since this is ready to go (as soon as I get reviews).
Target Milestone: mozilla0.9 → mozilla0.8.1
Thanks Dan.  I had that new code where you suggested but it didn't work.  But 
that might have been because I had some extra cruft in my open properties (I 
was trying various combinations to try to get what I wanted).

I'll move it to where you suggest and clean up the properties and check it out 
again.  I'll post the updated patch when it's done and ask for re-review if 
there's any material differences.
BTW, this particular set of lines is *not* part of the patch (I had that in 
there as part of some other work I was doing)...

+    // If native app in server mode, suppress show of first window.
+    static PRBool firstWindow = PR_TRUE;
+    if ( firstWindow ) {
+        firstWindow = PR_FALSE;
+        nsCOMPtr<nsIAppShellService> appShellService(do_GetService
+        if (appShellService)
+        {
+            nsCOMPtr<nsINativeAppSupport> nativeApp;
+            appShellService->GetNativeAppSupport(getter_AddRefs(nativeApp));
+            if (nativeApp)
+            {
+                PRBool serverMode = PR_FALSE;
+                if (NS_SUCCEEDED(nativeApp->GetIsServerMode(&serverMode))
+                {
+                    // Don't make window visible.
+                    return;
+                }
+            }
+        }
+    }
Erk, please ignore that last comment.  I meant that to go to one of my other 
It did confuse me. r=me, in case you're waiting on me for that.
only a few hours till close for 0.8.1, can someone check this in? I guarantee at
least one positive comment about this on /. :)
Resetting milestone to get these non-critical bugs off the radar till later 
this week.
Target Milestone: mozilla0.8.1 → mozilla0.9
law, a=asa (on behalf of drivers) for checkin to 0.8.1
Whiteboard: will take for 0.8.1
Fix checked in for mozilla0.8.1 (yeah!).  Thank you for your patience.
Closed: 23 years ago
Resolution: --- → FIXED
Looks great, Law!  Verifying on 2001031620.
What iss the related Bug for versions other than Win98?
Under Linux with 0.8.1 I still cannot minimize the saving file window.
(Build ID 2001032614).
I am using this remotely on a Linux RedHat system from
a Solaris CDE X11 server.The release notes for 0.8.1 state
that this has been fixed without referring to an OS.
Ok, this wasn't fixed, except on Windows. (QA, where were you?) Therefore, 
since most of the people on this CC list probably aren't interested in minority 
platforms and don't want to get further spam from this bug, I've filed a 
separate bug 76110 -- `Can't minimize download progress window', for Unix and 
Mac OS.

*sigh* ... When I marked this bug as dependent on bug 67161, I really wasn't 
joking, you know ...
> since most of the people on this CC list probably aren't interested in minority platforms

You weren't trolling right? I mean, some people are going to take offense at that 'minority'... (that word also has a derrogatory meaning besides the normal one you probably meant)
> since most of the people on this CC list probably aren't interested in 
minority platforms
Correct since no one _ever_ changed the os to All or the platform to All.

mpt: next time if you do that, QA just might do what you want. wrote:
> You weren't trolling right?
No, he was lecturing [especially the QA contact]. Although as it turns out, mpt 
was wrong to give the lecture, just as you are wrong to complain about his 

> I mean, some people are going to take offense at that 'minority'...
Go away. he did the right thing in an effort to avoid needlessly spamming the 
cc list continuously. And then you had to complain which spammed us. If you 
have a silly quesiton like this in the future, please contact the person via 
direct email.
> (that word also has a derrogatory meaning besides the normal one you probably 
He used minority as a strict percentage of the general client market share.  
But he used it to complain about the fact that the QA had overlooked that fact.

Again, it turns out that his complaint was misdirected, as this bug was filed 
specifically about windows and has always been focused on windows. A quick read 
of this bug indicates only two mentions of non windows, the first was a request 
that we treat this as all/all [it was ignored], and the second to which mpt was 

mpt's overall response was correct... namely he filed a new bug for the other 
os's. And no I am not using other in a condescending manner.
you asked why the release notes said this bug was fixed but didn't indicate an 
os. the answer should be clear from my above comments, but i'm including this 
for you and everyone else: release notes point to bugs which include 
information about the platforms where the bug is seen and where the assignee 
intends to fix it. In this case, the bug was for PC:Windows98 and was fixed for 
that clas (it was fixed for win32). Anyone reading the release notes would 
browse to this bug and quickly see that it is for windows.

Fixing X11 and MacOS will require platform specific code, just as this did, so 
there should probably be two bugs, not just one.

filed bug 76122 gtk/X11: dialogs [Saving File window] are not minimizable 
I've changed the bug mpt filed to focus on Mac OS (classic).
>Fixing X11 and MacOS will require platform specific code, just as this did, so
>there should probably be two bugs, not just one.

Actually, the fix for this had no Windows-specific code so it perhaps should
have worked on all platforms.  Mac and Linux don't provide the same level of
support for the nsIWidget border styles, apparently.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.