Closed Bug 22796 Opened 25 years ago Closed 23 years ago

Predownload a file after clicking link and before selecting Save

Categories

(Core Graveyard :: File Handling, defect, P1)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: twm, Assigned: law)

References

(Blocks 1 open bug)

Details

(Whiteboard: (py8ieh: reopen)) 

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".
Assignee: nobody → law
QA Contact: nobody → sairuh
I love this RFE :-)   I think it would be in Bill's area.
Target Milestone: M20
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.
Status: NEW → ASSIGNED
*** Bug 33666 has been marked as a duplicate of this bug. ***
Component: Browser-General → XPApps
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...?
Component: XPApps → Networking
QA Contact: sairuh → tever
Move to "Future" milestone.
Target Milestone: M20 → Future
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
Whiteboard: (py8ieh: reopen)
reopening to back out 'fix'. This should never have gone in. ->0.9.8/P1/critical.
Severity: enhancement → critical
Status: RESOLVED → REOPENED
Keywords: helpwanted
Priority: P3 → P1
Resolution: FIXED → ---
Summary: [RFE] Start download while prompting for filename → Do not download until user clicks Save.
Target Milestone: Future → mozilla0.9.8
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!
Depends on: 55690
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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. =)
Summary: Do not download until user clicks Save. → Predownload a file after clicking link and before selecting Save
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.
Blocks: 75364
#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.
No longer blocks: 75364
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.
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.9 → ---
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → 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.
Blocks: 129923
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.
Component: Networking → File Handling
QA Contact: tever → sairuh
mass-verifying Wontfix bugs.

mail filter string for bugspam: Tursiopstruncatus
Status: RESOLVED → VERIFIED
*** 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?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.