Closed Bug 26029 Opened 25 years ago Closed 24 years ago

Download progress dialog [Saving File window] is not minimizable

Categories

(SeaMonkey :: UI Design, defect, P2)

Product:
SeaMonkey
Component:
UI Design
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: henrik, Assigned: law)

References

(Depends on 1 open bug,
URL
)

Details

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

Attachments

(3 files)

Screen shot comparing Moz, NS4, and IE5 download file progress dialogs
10.02 KB, image/png
Details
Patch to add "minimizable" window.open feature and make progress dielogs use it
4.71 KB, patch
Details | Diff | Splinter Review
new and improved patch (all the files this time; modified per Dan's comments)
4.51 KB, patch
Details | Diff | Splinter Review
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 (mpt@mailandnews.com). 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 elig@netscape.com.)
QA Contact: elig → mpt
This is Windows only, and involves windowing controls ... Another one for Claudius.
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 http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamXferOp .cpp#97 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 jce2@po.cwru.edu's comment on 2000-09-10 The line reads ... "... Marking nsbeta3. This should be an easy fix, but we NEED it for user satisfaction..." 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 window.open 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 dependency.]
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 others.
*** 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.
URL: http://bugzilla.mozilla.org/showattac...
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 window.open 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 P2.
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 complicated?) 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 getright).
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 mozilla/widget. 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 "chrome,titlebar.minimizable", 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.
sr=alecf
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 (kAppShellServiceCID)); + if (appShellService) + { + nsCOMPtr<nsINativeAppSupport> nativeApp; + appShellService->GetNativeAppSupport(getter_AddRefs(nativeApp)); + if (nativeApp) + { + PRBool serverMode = PR_FALSE; + if (NS_SUCCEEDED(nativeApp->GetIsServerMode(&serverMode)) &&serverMode) + { + // Don't make window visible. + return; + } + } + } + }
Erk, please ignore that last comment. I meant that to go to one of my other bugs...
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.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Looks great, Law! Verifying on 2001031620.
Status: RESOLVED → VERIFIED
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. cesarb@dcc.ufrj.br 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 language. > 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 meant) 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 responding. 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. johann@ai.univie.ac.at: 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.

Attachment

General

Creator:
Created:
Updated:
Size: