66723 - Download progress window should not appear when saving from cache

Status: NEW

(SeaMonkey :: UI Design, defect)

Description

[Dimitrios]

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.

Comment 1

[John Morrison]

It does happen, but the decision lies in code above widget. Perhaps law
knows more ...

Comment 2

[John Morrison]

*** Bug 66724 has been marked as a duplicate of this bug. ***

Comment 3

[Dimitrios]

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).

Comment 4

[John Morrison]

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.

Comment 5

[John Morrison]

verified -- 

Comment 6

[Dimitrios]

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.

Comment 7

[John Morrison]

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.

Comment 8

[Jesse Ruderman]

*** Bug 120448 has been marked as a duplicate of this bug. ***

Comment 9

[David Illsley]

*** Bug 136451 has been marked as a duplicate of this bug. ***

Comment 10

[Jesse Ruderman]

See also bug 143949, the equivalent bug when download manager is enabled.

Comment 11

[Jesse Ruderman]

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.

Comment 12

[John Morrison]

[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.

Comment 13

[TGOS]

> [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.

Comment 14

[Dimitrios]

"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.

Comment 15

[Craig]

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.

Comment 16

[Ken Burwood]

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.

Comment 17

[Jesse Ruderman]

Fixed in Firebird 2003-11-01 with default options (use Download Manager instead
of individual progress windows).

Comment 18

[Ken Burwood]

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.

Comment 19

[:aceman]

It also happens in Mozilla 1.7.x, Firefox 1.0.x and Firefox 1.5beta1.

Comment 20

[Jonathan Watt [:jwatt]]

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)