All users were logged out of Bugzilla on October 13th, 2018
When saving a page from cache, the downloading window appears. I think this doesn't make any sense and, possibly, makes the user to think he must keep internet connection open to save pages. Nav 4.x and IE don't show such a message.
It does happen, but the decision lies in code above widget. Perhaps law knows more ...
Assignee: trudelle → law
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → XP Apps
Ever confirmed: true
*** Bug 66724 has been marked as a duplicate of this bug. ***
Adding 4xp keyword. Chances are that I am wrong (e.g. if my pc is so fast that I am not able to catch up this window on NS4).
There _are_ download dialogs in both IE and Nav4.x on windows, and frankly, I think there should be these dialogs, if only a brief flash.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
John, finally the concept of my bug was incorrect. Yes, there is a dialog in NS4, now I see it. It is centered in the screen and flashes for less than a tenth of a sec. Of course I can't read its contents but it's surely a download dialog. I wasn't able to see any dialog in IE, obviously it's too fast for the eye to catch. Should I file a new bug about the duration of the download dialog? Now it is in the range of 2 sec (K6-III/400, 192MB ram). If there is a duration timer, it could be set to 0.1-0.5 sec. Two seconds is annoyingly long.
Yeah, I don't like that 2 second delay for any and all downloads. I think there is a bug on file to remove that delay, but if not, then file it for consideration.
*** Bug 120448 has been marked as a duplicate of this bug. ***
*** Bug 136451 has been marked as a duplicate of this bug. ***
See also bug 143949, the equivalent bug when download manager is enabled.
Summary: Download window should not appear when saving from cache → Download progress window should not appear when saving from cache
Whiteboard: parity-ie, parity-opera
This bug is not present in IE or Opera, but it is present in Netscape 4. (Some comments in that bug mentioned a two-second delay before the window would disappear; this delay was present in 0.9, but in 0.9.4 and 2002 091208, the progress window disappears almost immediately.) Saving a displayed page or image is not downloading. Presenting it as downloading - causes ui inefficiency. I might wait second for the progress window to appear because I want to avoid clicking the progress window during the fraction of a second that it is visible. - makes it less unclear whether the save was successful. If saving an image hits a porn server, or if saving a dynamically-generated page hits a server, the save probably wasn't successful. - may confuse users into thinking that saving requires an internet connection (comment 0). Using "save link target as..." on an item that happens to already be in the cache is borderline and probably does deserve a download dialog.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
[Um, well, IE5.5 on win2k does indeed show a progress dialog when saving the currently displayed page. Perhaps IE6.0 changes this behaviour.] And this is so not a performance bug.
Whiteboard: parity-ie, parity-opera → parity-opera
Target Milestone: --- → Future
> [Um, well, IE5.5 on win2k does indeed show a progress dialog when saving the > currently displayed page. Perhaps IE6.0 changes this behaviour.] But IE never ever displayed any progress meter when saving a currently displayed image and that annoys me most at Mozilla. Mozilla sees storing a currently displayed image to disk as download, but that is no download of any kind in IE or Opera. Not only that Mozilla will open a progress meter if you store a currently displayed image, no, it even places this "download" onto the download manager window. IMHO Mozilla should be none of both. Just adding a delay to open the progress meter does not really fix the problem as I see it, because there will still be a download displayed on the new download manager, that will sooner or later make the progress window optionally anyway (there is no reason to waste resources for an own window for every download if a single window can cover all currently running downloads at once and if one can still make a single progress window appear for every currently running download from there if one needs that). But when I right now go to a computer art page and browse the pictures there and decide to store some of them, because I may like to use them as desktop background anytime in the future or because I just like them, I have hundreds of so called "downloads" in my download manager, which is highly annoying. A download takes only place if the browser is transferring data from a server and only then a dialog window should appear and only then a download should be added to the download manager window. If that does not happen, we are not talking about a download of any kind, but just of transferring data from memory or cache directory to another location on HD and that is no download. So the problem is how the download window(s) are currently triggered. They should actually be triggered by the network layer. E.g. the network layer should know if the just requested resource is part of a currently displayed page or not. If it is part, only the progress bar at the bottom of the browser window is used to show progress. If it is not, then either a progress window is opened or a new entry is created in the download manager, and that's where the progress is updated (I think an own thread is started for this, too, isn't it?). The layer that actually requests the picture to then store it to HD, just does that, it requests the picture and whether this initiates a download or not is none of its business. If there is another layer that looks first if it's in cache or not, it will do just that and only initiate a download if it's not in cache (but it also doens't create a new download task). That way also "Save link target as..." will only cause a progress window or download manager window if the requested resource is not currently in memory or disk cache, otherwise it will not. I guess that's how Opera is doing it. Can't say for IE, because IE has a progress window, but no download manager, where one could look up what actually has internally be handled as download and what not.
"And this is so not a performance bug" I think that's wrong. In win2K, when you have multiple browser windows opened and downloading images (heavy cpu usage), saving an image from cache is terribly slow (K6-III/400, 384MB ram). There are also be other factors affecting this, but surely a useless progress dialog contributes to it. Everything that uses cpu power makes an already difficult situation even worse. I 'd suggest adding perf keyword again.
Another reason why this is bad is that Mozilla has a "keep this window open after download in complete" click box. Personally, I want to keep that checked for real downloads, because I want to be able to see that they have finished even though I might have wandered off while they are doing it. I don't want to see this useless box come up when I am just saving a file.
I couldn't agree with comments 11, 13 & 15 more. Concerning comment 13, not only do IE and Opera not trigger download meters when saving displayed images from a page, but NS4x never triggered download dialogs when saving displayed images either. NS4x only triggered dialogs when saving other data from the cache (e.g. a zip file). I've just started using Firebird 0.6.1 and this behavior is extremely irritating. I've even turned off the option to have the download dialog stay opened when finished, specifically because of this behavior. Most people I know would be extremely frustrated with the dialog openning every time they save an image, which, I believe, is something people do far more often than actually downloading files.
Fixed in Firebird 2003-11-01 with default options (use Download Manager instead of individual progress windows).
This bug has reappeared in Firefox 0.9. It was finally fixed in version 0.8, where saved html & image files no longer were recorded in the download manager. However, the download manager in version 0.9 once again records saved html & image files as if they were downloads. Together with bug 246165 this can really get in the way when saving images; or if you simply wish to set the download manager to stay open when finished.
It also happens in Mozilla 1.7.x, Firefox 1.0.x and Firefox 1.5beta1.
Assignee: law → jag
Status: REOPENED → NEW
QA Contact: jrgmorrison
Target Milestone: Future → ---
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Keywords: parity-ie, parity-opera
Whiteboard: parity-ie for images, parity-opera → for images,
You need to log in before you can comment on or make changes to this bug.