User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008061105 Minefield/3.0pre I noticed Firefox starts the download of a file in background even if the Save dialogue is not confirmed. I think it's better to add an option to disable this, for security. This could be a big problem with viruses. Reproducible: Always Steps to Reproduce: 1. Go to a page with a big file to be downloaded, for example the page reported in URL section 2. Click the download link. When the Save dialogue appears, do not confirm it for some minutes. 3. Confirm the download Actual Results: File was downloaded in background and the download is already finished, or a part of the file is already downloaded.
Confirming because this is a reasonable enhancement request. Even if Firefox prefers the current method other Gecko-based products may want to change the behavior (but then what component would this be in?). Users who pay for their connection based on amount consumed also have a need for this kind of option. Clearing the "security-sensitive" flag though: this is known behavior (and collects a fair number of complaints). It's primarily done to improve perceived performance: most of the time the download is wanted by the user, and this gives them a head start while they figure out where they want to save it; if the user doesn't want the file we throw away the downloaded part. Although it isn't the reason we do this, you could even argue that the current behavior enhances security: if the user has an active anti-virus program the file could be scanned and any evilness detected before the user chooses to officially save it (if the file is small enough).
(In reply to comment #1) > Users who pay for their connection based on amount consumed also have a need > for this kind of option. This is true. I think if an option will be created, it could be asked at the first start of Fx if you want to turn it out (in an advanced first config). It could be added also some options for high/low performance machine and fast/slow connection. I know is out of the scope of this bug, it's just an idea. > Although it isn't the reason we do this, you could even argue that the current > behavior enhances security: if the user has an active anti-virus program the > file could be scanned and any evilness detected before the user chooses to > officially save it (if the file is small enough). Mh. I don't know very much about, but even if the file has not an executable extension, it can't be executed by Java code, for example?
Summary: Option to disable the downloading in background → Option to disable background-downloading while waiting for user confirmation
The reason why we do this is different: Gecko must ask the server for the file before it can display the save as dialog because it needs the content type of the requested URL. Requesting the URL and you get already the file, gecko can abort it (cancel the TCP/IP connection) and wait for the user to accept and select a destination but that could mean that the server sends you a different response which could result in a failed download. The best solution would be to throttle the download to a minimum download speed (0.01k/s) and I think we added throttling support already in Gecko but I'm not sure. biesi should know more about that. It can not be executed unless you start your finished download which should be in your temp directory.
We do not have throttling in Necko at the moment. What we could do is stop reading from the socket. I don't think that that's a good idea - if you take too long to select a directory the download would fail. I don't see the problem with the current behaviour. Viruses are not harmful when they're not executed.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 69938
Well, this bug is not a dup of bug 69938. See in particular bug 69938 comment #304
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Another issue with this background downloading: if one want to use a different downloader (e.g. Down them all! in my case), in the case of a download from websites like rapidgator, uploaded, eazyshare and others (which is quite frequent), as they allow only one free download at a time, with a restricted bandwidth and so on, if Firefox starts the download, it is not possible anymore for the other downloader to manage it. For instance, click the download button on the webpage, the confimation dialog appear to confirm what to do with the link (while Firefox is already downloading it in background), then select the other downloader and confirm, which then starts the download in the other downloader while firefox cancel its own. Finally, the other downloader starts and make an error, because it was not allowed to download. My suggestion is that, if Firefox have to start the download, for whatever reason, then what should be done is not to cancel and let restart, but to provide the necessary information to resume the download from the other downloader. Of course, this means that the other downloader should manage that. For that I see several ways: - it could be possible to exploit the transfer protocol in a given way to switch completely to the other downloader without having the target (from which we download) noticing it - firefox should play as a proxy, so that the download still pass through Firefox, but the one which rules the download is the other downloader Anyway, for that to happen the other downloader should be able to manage requests for already started downloads (not only requests to start from scratch). For that, an API (standard or Firefox-specific) should be used, thus available to Firefox extensions and other external downloaders.
(In reply to Daniel Veditz [:dveditz] from comment #1) > Confirming because this is a reasonable enhancement request. Even if Firefox > prefers the current method other Gecko-based products may want to change the > behavior [...] Such as Firefox on Android. By default, we'd very much like being able to turn this while on metered connections for example.
(In reply to Jan Henning [:JanH] from comment #11) > [...] we'd very much like being able to turn this while on metered connections [...] Turn this *on*, that is.
As far as I can tell, we actually have some throttling capabilities now. If so, it would be nice if this could be leveraged to optionally (for Android we might want to turn this on by default) start downloads throttled and only unthrottle them when it's clear that we actually want to download the file, i.e. for those cases where we're showing the helper app dialogue not until the user has confirmed that they want to continue the download with Firefox (on Desktop, "Open with" seems to mean "Download a temp file and then open that in the chosen external app", so "download" or "open" wouldn't make a difference, but on Android we abort the download completely and only pass the URL to the chosen app to handle).
You need to log in before you can comment on or make changes to this bug.