This concerns the process of saving a file to disk. It seems to me that time is wasted while prompting the user for a filename -- it would be nice if Mozilla began downloading the file while the user is navigating to the directory and typing the filename. Extra-cool would be a progress display on the bottom of the save-as box while this was taking place. Doing this also clears up a slight misfeature in interface design (in 4.x, at least) -- for files that are extremely small, the progress dialog pops up and disappears so quickly that it is completely unreadable. For novices this momentary dialog pop may be confusing. Under the suggested scheme, the progress bar on the save dialog would show a completed download, allowing the user to confirm by pressing "save".

I love this RFE :-) I think it would be in Bill's area.

Uhhhh ... where would we start downloading too? A "temp" directory? If so, and the user then selects a different volume, then we either wasted a download or we have to transfer what we've already downloaded to the other volume. Hmmm ... actually this _could_ work. But are there security concenrns with this? Downloading something the user has not confirmed?

I don't know much about the mozilla architecture, but it seems to me that this wouldn't introduce any more security/temp storage issues than are already present during normal page browsing (preemptively-downloaded files could be stored in the same place that content served by plugins is stored, perhaps). I would expect that if the user hit 'cancel' after shift-clicking a link, the file would be removed from temporary storage. As long as files aren't given predictable names and there isn't any way for scripts/rogue servers to simulate a shift-click/"save as", I can't think of any way for this to be misused.

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

Wow, I love the progress bar idea. My bug has been marked duplicate so now I am here :)

Love the progress bar idea. My bug has been marked a duplicate. To answer the question of where to download to - a few hundred K (to a Meg) of memory could be allocated for the download, and if it got too large, then it would be thrown in a temp file. After you clicked ok - it would transfer the data to the other directory and continue the download.

Ideas/Features:- When the user selects a file download the file should start being downloaded to the cache; this should make optimal use of memory, and disk cache. After the download has completed then the file should be copied out of the cache and into the selected directory. This would allow for resume functionality to be enhanced, allowing users to cancel a download (because they are saving to the wrong place), and restart the download to a different directory without losing the data they have already downloaded. It would also allow users to download a second copy of the file (saving to a different location) and just provide the already cached file.

It should be downloaded to mem cache until too large and then downloaded to disk cache.

Check out bug - 40106 - about download accel.

tever, should this go over to Networking...?

Move to "Future" milestone.

As I learned, we are already downloading now, while choosing a file name. If I am right, I propose to close this bug...

yep, background downloading is implemented.

In today's build (Sept 1) on W2k, this does not appear to work. Steps: Go to mozilla.org, right click one of the daily builds, save link as..., wait a few minutes at the save dialog, choose a filename, and watch the download start from 0%. Does something need to be done to enable the feature?

This "feature" [sic:-] only kicks in if you click on the link directly (i.e., try to load the file into the browser). The browser window (in effect) will continue to download to a temp file while you're making up your mind about what to do with it. It displays the "Downloading" dialog, then, after the download to the temp file is complete, will either launch the helper app you selected or open the file picker and then move the temp file to the destination you select. If you right-mouse-click a link and choose "Save link as..." it goes via a different route and the download doesn't start till you pick a destination file. Resolving this fixed might have been a little too optimistic. Not that reopening it will get it fixed any time in the foreseeable future.

I think the Save Link As should also download while saving. Another thing is, on the Windows Build - 2000080712, it downloaded the whole file before giving the Save As Box. That isn't what me meant. It should do it at the same time. Also, it should show the percentage completed in the Save As dialog box.

BTW - I realize it shows the percentage completed in the actual windows status bar.

reopening to back out 'fix'. This should never have gone in. ->0.9.8/P1/critical.

How about some more information, Trudelle? I like this feature, and I'm dubious about security concerns unless the implementation is flawed. (The browser downloads content automatically all of the time.) Now it's critical priority-1 to remove it? What's the deal?

The design and implementation are severely and fundamentally flawed. See bug 55690 for the reasons.

That's a reasonable opinion to have, but I don't understand why this bug was changed to be exactly the opposite of what it once was. Why not file a new bug (that explains the problem and proposed solution)? What you've done has banished my original RFE, and I don't know how to respond to that when I (and others) still want the feature.

I agree with Tom (don't turn this bug into its opposite). Has the subject line been changed? It seems to say the exact opposite of the useful suggestions in all the comments. Peter Trudelle has been trying to abolish this great "'feature'" also in bug 55690#178. Then it was suggested there (bug 55690#177) that this bug be reopened for reasons not really explained (expecially since the goal of this bug is now unclear). A. Could we please clear up what this bug is about (I suggest: to implement pre-downloading). B. The main objections seem to be: (1) user doesn't know where partial downloads are (bad, if download fails and partial file stays). (2) Someone clicks a link, ignores the 'Save as' dialogue, walks way and unknowingly downloads a bazillion gigabytes (that unlikely user will only do that once - DUH). (1) Would be solved by a user-defined default download directory (bug 7840, which is now over THREE years old and has recently been 'futured' by Peter Trudelle. Don't you guys understand the importance on this under windoze? EVERY download manager allows the user to define a default DL directory!). The partially downloaded files should go into the default DL directory (filename.exe.Mozilla). This would have the added bonus of being able to doubleclick an unfinished download (any *.mozilla file) to resume it - hopefully, to be implemented also (like GetRight). Also, a search for *.mozilla would quickly reveal all unfinished/broken downloads (that's an easy FAQ item). (2) This is (a) an unlikely scenario, and (b) easily avoided by showing the pre-download progress on the "save as" dialogue.

I like this feature too. Please don't remove it. Please make a pref. thx.

I like this feature too. Please don't remove it. Please make a pref. thx.

Sorry for spamming this bug, but I put my vote in for this feature as well. Changing the character of a bug to its opposite not acceptable IMHO, I'd have preferred if you open a new bug for the "removal" of the feature. The reasons given in bug 55690 are not about security issues as well...

I want this feature back! It cuts download time down to almost 0 on fat pipe like at my school, and at home it helps cut down on costs as I have to pay by the second for my connection. Implementation may need to change (even though I fail to see the supposed big problems with the current one) but please don't kill the RFE for this feature!

This RFE is very pretty, don't remove it, make it optionable.

The original summary also suggests a "progress meter" which would alse help the user understand that predownloading is in effect. This will help eliminate the confusion some users may have over what is happening. Once users realize this, I think they will be thrilled at the perceived and actual increase in speed their downloads are happening. Suggested UI: +- Enter name of file to save to... --------------------+ | ____________________ | | Recently used directories: |____________________|\/| | <-- bug 115574 :) | ----------------------------------------------------- | | __________________ | | Save in: |_MyDownloads______|\/| [^] [Favorites] | <-- bug 115981 :) | +---------------------------------------------------+ | | | files (or favorites) listed here | | | | | | | | | | | | | | | | | | | +---------------------------------------------------+ | | _______________________________ | | Predownloading File ||||||||____37_%________________| | <-- this bug :) | | | The predownloaded file will be moved to the path and | | filename you select once you click SAVE, or deleted | | if you click CANCEL. | | | | [ SAVE ] [CANCEL ] | +-------------------------------------------------------+ Also, if the download finishes *before* the user clicks SAVE or CANCEL, the bottom section could change to the following. This would be particularly useful for small downloads that finish (100%) virtually before even the Save dialogue comes up: | | | | | +---------------------------------------------------+ | | _______________________________ | | Predownloading File |||||||||||||| 100 % |||||||||||| | | | | The predownload has been completed and will be | <-- updated text | moved/renamed to the path and filename you select | at 100 % complete | once you click SAVE, or deleted if you click CANCEL. | | | | [ SAVE ] [CANCEL ] | +-------------------------------------------------------+

Changing actual summary 'Do not download until user clicks Save' to original-like summary of this RFE: 'Predownload a file after clicking link and before selecting Save' Bill Law: If you think (or Trudelle), that function (not actual implementation) of this RFE have to be removed from browser, mark please this bug WONTFIX and remove code (also change severity to enhancement). Peter Trudelle: Could you provide specification for right implementation? Users want this feature, futhermore this is IMHO very nice 'perf' feature, so why don't implement it in correct way. =)

Yup, as it stands this is wontfix alright, it violates fundamental principals of user interface behavior, and leads to several critical defects. The feedback we have received is that most customers and users think this is a defect in itself, without even considering the defects in its implementation. We apparently did it for parity with IE5, but even MS dropped it in IE6, presumably for the same reasons we need to. It should be possible to get a large part of the benefit in typical scenarios by fetching a few KB to a temporary file, as IE6 still does. This is reasonable, since we sometimes need to fetch enough to determine the type, and it lets the download proceed during the second or two in which users just accept the name and location, which seems to me to be the typical case. On dialup lines, this may be indistinguishable from current behavior in most cases, without any of the drawbacks. The only proposal I've heard for doing this in a usable manner would be to add the concept of a default download directory which would obviate the save dialog. This concept has existed on MacOS for a while, and allows the fastest possible downloads, although some users may still feel the need to move/rename some files after download. Naturally, the save dialog would still be the default, but for users willing to specify the destination in advance, downloads could proceed from the initial click, which is the main benefit of the current behavior. I see no way to let users retain control over the name and directory within the current Save File dialog, without also letting them have control over whether the download happens at all. You can't eat your cake and have it too. However, it is possible to offer a way, in the the download progress UI, to re-direct a file to a new name/destination. I don't think this would be worth adding, but if mozilla developers wanted to add it unobtrusively, it might make the default download directory option palatable to those who also want the ability to change the name and destination.

Well, if it's a lack of support that's the problem, then let me reiterate that I think this would substantially improve the usability of Mozilla. (Problems in implementation aside.) Perhaps I am biased, but my impression of the discussion in bug 55690 is that it is far from "most" users considering this feature a defect. (In fact, I remember wow-ing a friend even with the unspectacular current implementation.) I am having a hard time understanding why this violates fundamental UI principles. The browser automatically downloads and stores files on the disk all the time, and the user knows that clicking on a link starts this kind of behavior. For instance, if I click on a link to a flash movie, that movie is downloaded to my disk and then played. Clicking on links fetches content. Can someone explain the specific problem with the design? Personally I think Peter Lairo's dialog is great. I get the feeling that there must be a simple change to the design that could satisfy the users who want this kind of functionality and those who think it is a bad idea... Thanks!

The people expressing personal opinions in these bugs and on newsgroups are in no way representative of typical target users. We are the <<1% of most sophisticated users, and frequently what we tolerate or even like is considered unusable or defective by the masses. In many cases it is possible to resolve these difference via careful design, but in this case the fundamental problem is that until the user clicks Save, they have not given permission to use their bandwidth or disk space. Clicking on a link whose content we can present is a distinctly different case, wherein the click itself is the permission to do whatever is needed to present the content. When we don't know how to present the content, we have failed our part of the single-click contract, and must ask the user what to do. For all we know, they were counting on the browser to present the content, and have no other way to do it,so the file may be garbage to them. We have no right to presume a decision to download just because our networking layer is already reading bytes from the file. You could make a slightly stronger case for when the user picks Save Link As (a far more rare operation), but even then, the expectation is that they can still cancel the operation before it is carried out, which is not true if we are 'pre-downloading'.

> the fundamental problem is that until the user clicks Save, > they have not given permission to use their bandwidth or disk space. 1) When clicking a link to another page, we use up bandwidth/diskspace without asking - "that's OK". 2) When clicking a download link, it is suddenly not OK to use up bandwidth/diskspace without asking? That seems to contradict #1. Anyhow, with the above suggested UI, the user would have visual feedback that bandwidth is being used and could quickly hit CANCEL (and maybe looses $0.0001). BTW, by far the *most* common users pay by the minute and not by bandwidth, IMHO.

#1- browser carries out user request to present content. #2- browser unable to present content as requested, *offers* to save it instead. These are clearly very different different cases, and in case #2 the content may be worthless if the browser is unable to present it. Scenario A: You see a link to a lengthy presentation on a topic of interest, say usability engineering. You click it and go for coffee, expecting it to load. However, the author has created it in PowerPoint, and you have no viewer. Should your browser decide to download the lengthy file to your temporary directory, or should it ask you if you want it first? Scenario B: You click Save Link As on a large MP3 file, but when the Save As file dialog comes up, you recognize the file name, and think you might already have it. You switch to the another program to search for it, but get distracted. When you come back later, should the browser have made your decision for you? I could go on, but the issue is: Who is in control, the browser or the user? In the default Save File behavior, the user has immediate visual indication that nothing is happening, and can quickly hit the Save key to start the download a few milliseconds sooner. She should not have to hit something quickly to stop an action she didn't request. Perhaps you don't recall the DOS applications from 20 years or so ago, but many of them tried to lead users around by the nose like this, and they failed. In a GUI, the user is in control, period.

Peter: What about solution, that this feature will be disabled at default and user could enable it in Preferences?

> You click Save Link As on a large MP3 file, but when the Save As > file dialog comes up, you recognize the file name, and think you might already > have it. You switch to the another program to search for it, but get > distracted. When you come back later, should the browser have made your > decision for you? Well, since you clicked "Save As..." I don't think the browser is wrong in attempting to guess ahead (I would say that the majority of Save As actions DO result in finishing the download). But the decision to keep the download is the user's, not the browser's. Of course, it IS wrong if it leaves the file on your disk after you hit cancel, or even if it leaves the file with its default name/extension in a predictable place. In both cases, the worst thing that happens is a "waste" of bandwidth (that just as easily could have been incurred by an inappropriately configured helper app for A) while the user is not even using the browser, after having (partially) directed the action to take place. Why shouldn't a partial commit to download result in a partial download (where clicking 'save' is what actually signs the contract and puts the file on disk?) > In the default Save File behavior, the user has immediate visual indication that > nothing is happening, and can quickly hit the Save key to start the download a > few milliseconds sooner. This is true, except that the user might spend some time navigating to the directory that the file should be downloaded to. In that case I think this can be a significant performance win, and that's what the original RFE was about. That said, if this was a default-off pref or worked only on "Save Link As..." (shift-click), then I think that would make advanced users happy and it certainly wouldn't confuse users in the situations you describe.

I hit both of Trudelle's scenarios often. Here's a common extension of them which illustrates why it can be bad even for someone who doesn't have to pay by the byte: I click on a link and it turns out to be something I don't have on the current machine, so it gives me a download dialog. Let's pick one that I hit a lot: quicktime. I go to another window and check and verify that I don't have quicktime on my system. Now the question is, can I get it for my system? I don't want to download the file unless I can get a player. Okay, back to the browser (perhaps open a new window) and start doing rpmfind and google queries looking for a player. Except, guess what? All my queries are slow as molassas and I'm not having much luck getting the answer, because all my bandwidth is being taken up by this downloading file that I'm not even sure I want to download. In the case of quicktime, the ultimate answer will be, no, I don't want to download it because there is no player for my platform, but it's going to take me a loooong time to find that out because of the useless downloading file. In the case of mp3, the answer may well be that I can't answer until I've downloaded, installed and tested the latest ALSA drivers to see if they recognize my sound card. Making the feature optional (preferably disabled by default) would be fine, though. Obviously there are people who like it.

Tom: How nice that you would leave *some* decisions to the user, such as how to dispose of the garbage that his browser spews onto his system. ;-) Even in the "Save As..." scenarios, the expectation is that no action will be taken until the user clicks Save. I'm sure Akkana is just trying to be nice, but for almost anything you can think of, there are a few people who claim to like it. However, that doesn't mean that it is actually good for them, or would be a good thing to add to the browser. If we can't draw the line in cases like this, but are forced to continually compromise via mini-fork prefs in a design-by-committee attempt to please *everyone*, then this browser will continue to grow without bound, until it is too bloated and slow for even the most buff development machines to run. Let's just get this to work properly for 1.0, and leave the optimizations to a future release, when we can do it in such a way as to benefit most users.

Comment #38 (PTrudelle): > ... how to dispose of the garbage that his browser spews onto his system. Downloading THE file that the user has CHOSEN by clicking on a DOWNLOAD link can hardly be considered "garbage". > ... the expectation is that no action will be taken until the user clicks Save.´ No, when the user clicks a DOWNLOAD link he expects the file to be downloaded (and as quickly as possible). I suggest to "future" this useful feature, and then make it a preference with the default being ON/OFF? <- I say ON).

There is no such thing as a 'download link'. If there were, you'd have a point.

> There is no such thing as a 'download link'. If there were, you'd have a point. What I meant is any link to a binary file that users USUALLY (read: virtually always) want to download, like *.exe, *.mp3, *.ZIP, etc. etc., etc. files. I thought that was pretty obvious, but I gues it wasn't. So, now do I have a point? ;)

The same would go for a shift-click or "Save Link As...", of course. > Tom: How nice that you would leave *some* decisions to the user, such as how to > dispose of the garbage that his browser spews onto his system. ;-) I think this is an entirely inaccurate (and somewhat rude) characterization of my proposal. I'm not asking to take any decisions away from the user. In fact, making this a pref gives the user more choice. My comment still stands that the browser saves data to disk automatically all of the time during normal operation, and it is the way that it *leaves* the disk, not how it uses the disk for temporary storage, that matters in the end.

Tom, I'm sorry about the 'somewhat rude' comment, I have no intention to be rude to you or anyone else who is contributing here. I was just trying to be humorous, and even used a smiley, but I guess it wasn't funny either, and I apologize for that too. If you don't make any distinction between when the browser is (1) able to present the link content or know how the user wants it to be handled (e.g, they have specified "always open in WinAmp, never ask me"), and when (2) it can't present the content doesn't know how to handle it, then I guess there is no way to convince you that clicking on a link only gives the browser permission to use bandwidth and disk space in (1), not in (2). Peter, in the current default configuration, the browser does not have any reason to assume that users usually want to download .mp3, .zip, or many other file types, nor does it know how they want them to be handled, and it would be a security problem if it just assumed you wanted to download executables. Having some other type of auto-download controlled by an opt-in pref is a separate consideration, and I do support some informal proposals I've heard along those lines, but not making the current behavior a pref.

Peter Trudelle (comment #43): > (2) it can't present the content [or] doesn't know how to handle it What *currently* happens in this case? If mozilla knows *that* (2) has occurred, then we could ask the user what he wants (e.g., "Do you want to save this file to disk), then bring up the "save as" screen (and only then start predownloading - after user says YES to the download option). > in the current default configuration, the browser does not have any reason to assume that users usually want to download .mp3, .zip,... Correct, the predownload could/should start after the user has made that choice: +-----------------------------------------------+ | You have clicked a link to a ZIP file | | | | Do you want to: | | < > open the file with /Windows Commander/ ? | | <x> download the file to your hard drive? | | | | <x> Remember this decision | | | | [ OK ] [ CANCEL ] | +-----------------------------------------------+ (A) If the user selects "download" and clicks OK, THEN the predownload could/should start. (B) If "remember this..." is selected AND "download", THEN predownload could always start after clicking a file-link for that filetype (e.g., ZIP). This way it would not be a "security priblem" because the user has made the conscious decision to download this file, or files of this type ("remember").

You continue to ignore the fundamental principal that users are in control, and they expect the download to start only after they click on Save. In the current UI, the very concept of 'predownloading' is a defect. To make it acceptable to any significant number of users, you need to add the concept of a default download directory where such files automatically go. This has been proposed, and should be considered elsewhere, it is outside the scope of this bug report. I've wasted far too much time trying to explain this, and I must conclude and accept that some people just prefer what most others consider defective behavior. We are building a browser for the general public, you are most welcome to take the code and build whatever you like. resolving as wontfix.

FYI, I filed bug 121027 as an RFE to implement a default download directory and I will file a bug dependent to this one to reimplement a "proper" pre-download mechanism.

Peter Trudelle (comment #45): > To make it acceptable to any significant number of users, you need to add the concept of a default download directory where such files automatically go. Isn't that what I pointed out WAY back in comment #22 regarding bug 7840 (which is over THRE years old!)? This bug should be reopened, made dependant on bug 7840, and marked "future".

As my home web access is quite fast, but has a low monthly traffic limit, I am happy to know that this rfe is wontfixed. I think Peter Trudelle's "user contract" point of view (comment #32) makes sense.

I would bet a case of beer that Robert Pollak's case is the *extreme* exception (pays by bandwidth as opposed to online *time* = <<1% of users), and that wontfixing this bug to keep him from downloading a file whose link he explicitly clicked, seems to be the completely wrong resolution. Anyhow, my suggestion in comment #28 would give these edge cases enough visual feedback that a file is being downloaded that they could reasonably quickly hit the cancel button before incurring anything even close to a relevant cost-hit. Ideally, there would be a pref to turn off (or on) predownloading for these extreme edge-case users - but we are currently far far away from a pref.

Peter, that's a nice US-centric attitude. While paying by time is the rule in the US (or even flat rates), paying by bandwidth is very common in Europe.

Boris: *I* live in Germany! I have *never* heard of anyone paying by bandwidth. Here, T-DSL is very popular (3+ mil users) and only costs € 21 flatrate with *unlimited* bandwidth. Most other providers/fee-schemes have a (very generous) base-bandwidth *before* they start charging by the byte. Actually, the most popular methods to get online (after T-Online) are call-by-call services (pay by the *minute* - not MiBi!).

Peter, Boris is telling truth. Foe example in Czech rep. is common bandwith based pay for wireless connections. Germany isn't whole Europe (since 1945). BTW I think, that predownload is VERY useful, but couldn't be 'on' at default in builds. What about preference for it?

@Peter: I live in Switzerland and have a flatline. I pay about 30$ for each GB which exeeds 3GB (which can easily be reached with 2-3 users on my home LAN) That having said, I am all for predownloading. SCNR, shutting up now

more SPAM: Peter: *I* live also in Germany and I know that many people pay for Traffic. (1&1 DSL.....) You see all problems only from your point and that's the general problem and that is not what mozilla needs. Adam: "Germany isn't whole Europe (since 1945)" I hope you mean that not as it sounds... BTW: I want this predownloading in Mozilla but disabled by default and with a hidden or debug pref.

So, despite some obstacles (which can easily be overcome with a pref) , we all agree that predownloading is desirable. Why then is this bug still "wontfixed" and not "futured" (pending a pref)? BTW. Nobody is going to incurr any relevant costs during the few seconds they decide where to put a file, especially as compared to the hours browsing and downloading needed to fill up their quotas (e.g., 3 GiBi's). The relationship is simply disproportional by an enormous factor.

Peter: I have already explained why this bug is wontfix, and will remain wontfix Your topical input in bugs is valued, but nobody is bound to make decisions based on votes or number of comments in a bug. All you are doing now is spamming everyone unecessarily. *PLEASE* take your concerns to the appropriate newsgroup (n.p.m.browser or n.p.m.ui), where people can choose to participate if they wish.

-> file handling As I send this bug out of networking, I'm going to repeat a point I made in another download bug: If you don't know much about networking (or computing in general), you should exercise restraint, and stop banging your head on the wall. In bugzilla, head banging becomes spam for a lot of people that don't need it. --- Also, even in the US, where consumers do not pay for bandwith, most backbones pay for bandwith by data. In the long term, a trend towards more metering of bandwith is likely because, simply put bandwith is ultimiately limited.

mass-verifying Wontfix bugs. mail filter string for bugspam: Tursiopstruncatus

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

(In reply to comment #45) > In the current > UI, the very concept of 'predownloading' is a defect. To make it acceptable to > any significant number of users, you need to add the concept of a default > download directory where such files automatically go. This has been proposed, > and should be considered elsewhere, it is outside the scope of this bug >report. Isn't this the case now, with firefox? If so, why not reopen this bug? Is there currently no pre-downloading at all, in any case, or have any of the suggestions here been implemented?