Closed Bug 676619 Opened 13 years ago Closed 12 years ago

Implement proposed download attribute

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla20

People

(Reporter: evilpie, Assigned: evilpie)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(4 files, 7 obsolete files)

tests v1
6.46 KB, patch
smaug
: review+
Details | Diff | Splinter Review
v2.1
35.52 KB, patch
smaug
: review+
Details | Diff | Splinter Review
change params to nsAString
13.98 KB, patch
smaug
: review+
Details | Diff | Splinter Review
modified test for https
3.25 KB, patch
smaug
: review+
Details | Diff | Splinter Review 
This is probably a dup, but chrome just implemented download="filename.txt". Which is neat, because you can specify the download name of implemented with data-uris etc.

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032489.html
http://functionsource.com/post/downloadmynameisslimshady-png
I don't recall a bug about download attribute.
Jonas, you've been activate in the download attribute discussion.
Do you know if the spec is sane?
The big problem is that it allows cross-origin downloads. Even of sensitive contents such as bank statements and such which contains sensitive account and credit card numbers.

We definitely need to do a security review before we allow that.
(In reply to Jonas Sicking (:sicking) from comment #3)
Hi, could you be more specific about security issues? specifically how could one download bank statements?
insert something like the following in the page:

<a href="http://bank.com/statement.cgi" download="statement.html">

The actual URL depends on the bank of course.

When the user clicks such a link, the user will be prompted if they want to download. It seems very easy for the user to make the mistake of thinking that something on the original website is being downloaded, and not something from bank.com.
(In reply to Jonas Sicking (:sicking) from comment #5)
> insert something like the following in the page:
> 
> <a href="http://bank.com/statement.cgi" download="statement.html">
> 
> The actual URL depends on the bank of course.
> 
> When the user clicks such a link, the user will be prompted if they want to
> download. It seems very easy for the user to make the mistake of thinking
> that something on the original website is being downloaded, and not
> something from bank.com.

I assumed something like that... but secured pages are either not vulnerable to such attack (e.g. each request must have some valid unique ID) or I can actually  do that without download attribute (but with much more programming overhead and probably with server programming as well). There is actually no security issue that does not exists today, download attribute may add easier way to fool users by attackers, but no new one... instead of programming for 1 minute to add attribute one would have to programm 30 minutes... 

since "We definitely need to do a security review before we allow that" is there any research beeing done?

Would it be possible to implement it with same-origin and CORS (Access-Control-Allow-Origin) in mind if you are questioning cross origin security? This is very useful feature for web applications (create Blob using JS and let user download it with some meaningful name)
(In reply to Bronislav Klučka from comment #6)
> (In reply to Jonas Sicking (:sicking) from comment #5)
> > insert something like the following in the page:
> > 
> > <a href="http://bank.com/statement.cgi" download="statement.html">
> > 
> > The actual URL depends on the bank of course.
> > 
> > When the user clicks such a link, the user will be prompted if they want to
> > download. It seems very easy for the user to make the mistake of thinking
> > that something on the original website is being downloaded, and not
> > something from bank.com.
> 
> I assumed something like that... but secured pages are either not vulnerable
> to such attack (e.g. each request must have some valid unique ID) or I can
> actually  do that without download attribute (but with much more programming
> overhead and probably with server programming as well). There is actually no
> security issue that does not exists today, download attribute may add easier
> way to fool users by attackers, but no new one... instead of programming for
> 1 minute to add attribute one would have to programm 30 minutes... 

How would you do this without the download attribute? Do keep in mind that when the browser makes the request to the bank site it includes the users cookies for bank.com. Generally these cookies are what identifies the user to the bank.

> Would it be possible to implement it with same-origin and CORS
> (Access-Control-Allow-Origin) in mind if you are questioning cross origin
> security? This is very useful feature for web applications (create Blob
> using JS and let user download it with some meaningful name)

Google was opposed to using CORS for this.
(In reply to Jonas Sicking (:sicking) from comment #7)
> 
> How would you do this without the download attribute? Do keep in mind that
> when the browser makes the request to the bank site it includes the users
> cookies for bank.com. Generally these cookies are what identifies the user
> to the bank.
Oh i see what you meant, looking at that URL it does not seem to be behind login (cookies)... sorry. This is of course true, I cannot bypass that...

BTW. I can still write "to save this file please right click on the link and select 'save link as'" next to the link.... I wonder how many would blindly follow :)

> 
> > Would it be possible to implement it with same-origin and CORS
> > (Access-Control-Allow-Origin) in mind if you are questioning cross origin
> > security? This is very useful feature for web applications (create Blob
> > using JS and let user download it with some meaningful name)
> 
> Google was opposed to using CORS for this.

Well there can be notification or deny/allow mechanism when downloading from another origin (e.g. like in case of geolocation API). Or not to send cookies in case of cross origin request with download attribute. Or Mozilla can implement only same origin (and local [blob URL and FileSystemAPI URL]) at first (I really actually do not care that much about cross origin).

Is this attribute something Mozilla is seriously considering as useful and want to have or "yeh... well... rather not..."? I'm developing application using BlobBuilder and allowing users to download data with some intelligent name so I'm wondering whether I can proceed and wait until FF will catch up in few weeks/months or nobody really knows at this point?
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#downloading-resources
the 12th point in process starting with "Let filename be the void value." should address cross origin problem.
For same-origin this is definitely something that we want to implement. However if you're using BlobBuilder, and thus are using Blobs, I suspect what you want is FileSaver, no?

(In reply to Bronislav Klučka from comment #9)
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.
> html#downloading-resources
> the 12th point in process starting with "Let filename be the void value."
> should address cross origin problem.

I don't see why it would?
(In reply to Jonas Sicking (:sicking) from comment #10)
> For same-origin this is definitely something that we want to implement.
> However if you're using BlobBuilder, and thus are using Blobs, I suspect
> what you want is FileSaver, no?

Yes, FileSaver would be great as well, but no browser seems to be implementing it (in some near future) and download attribute is very easy way to do the same = save file to local file system (actual file system, not FileSystem API file system)
I've done some test on weekend how to get file from webapp to disk
http://www.webnt.cz/demos/034_a_download/  (Chrome only at this point)
using download attribute or drag & drop on actual file or generated file (blob). The last example (span) shows how to download Blob without actually having A element (by creating it on the fly)...


> 
> (In reply to Bronislav Klučka from comment #9)
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/links.
> > html#downloading-resources
> > the 12th point in process starting with "Let filename be the void value."
> > should address cross origin problem.
> 
> I don't see why it would?

"Act in a user-agent-defined manner to safeguard the user from a potentially hostile cross-origin download. If the download is not to be aborted, then let filename be set to the user's preferred file name or to a file name selected by the user agent, and jump to the step labeled "sanitize" below.

If the algorithm reaches this step, then a download was begun from a different origin than the resource being downloaded, and the origin did not mark the file as suitable for downloading, and the download was not initiated by the user. This could be because a download attribute was used to trigger the download, or because the resource in question is not of a type that the user agent supports.

This could be dangerous, because, for instance, a hostile server could be trying to get a user to unknowingly download private information and then re-upload it to the hostile server, by tricking the user into thinking the data is from the hostile server.

Thus, it is in the user's interests that the user be somehow notified that the resource in question comes from quite a different source, and to prevent confusion, any suggested filename from the potentially hostile interface origin should be ignored."

So you can abort such cross origin download, you can notify user about cross domain download, you can ignore download attribute....
Well, if we abort such downloads then we're back to not supporting cross-site uses of the download attribute :-)

Except in the rare case when the resource already sets Content-Disposition:attachment, in which case the download attribute added no value.

So yes, I'm all for supporting the download attribute for same-origin contents.
As I have said before, supporting same-origin, Blob URL, FileSystem URL for start would be a great step forward and apparently according to spec :)
(In reply to Jonas Sicking (:sicking) from comment #5)
> insert something like the following in the page:
> 
> <a href="http://bank.com/statement.cgi" download="statement.html">
> 
> The actual URL depends on the bank of course.
> 
> When the user clicks such a link, the user will be prompted if they want to
> download. It seems very easy for the user to make the mistake of thinking
> that something on the original website is being downloaded, and not
> something from bank.com.

I'm confused about this example.  Why does explicitly setting the download file name make this attack more effective than without it?  Even without the download attribute, a user may still download the file.  Which can then be uploaded to a different site as you said.  One could argue that it's a little harder if you don't know the filename of the download, but much of the time this filename will be fixed (e.g. "bank-statement.pdf") and thus knowable.
The problem isn't in being able to select the name, but rather in being able to force a download at all.

Note that http has a specific mechanism for telling the browser that a response is so sensitive that it can't be cached on disk, only in memory. For example so that it doesn't linger around in case of a computer crash.

Many banks use this mechanism.

It would seem silly if we honored the bank telling us that a resource is so sensitive that we can't cache it to disk, and then turn around and gladly honor another websites request to not just store that resource in the cache, but permanently on the users desktop (or whatever the default save location is)
(In reply to Jonas Sicking (:sicking) from comment #15)

I'm confused here... isn't storing on users desktop exactly what browsers do at this point after clicking on a element with resource, that cannot be displayed by browser? Isn't it what browsers do when user right click on a element and select "save target as" even for resources that can be displayed by browser? This is for your "and then turn around and gladly honor another websites request", we do that already...

How about respecting always this HTTP mechanism (even if download attribute is specified) an in other cases respect the download attribute? Author will probably not use this HTTP mechanism and download attribute together (since it does not make any sense) and altering webpage (Firebug, WebKit Inspector) will not compromise secret information.
(In reply to Jonas Sicking (:sicking) from comment #15)

So this is saying it would be a bad idea to allow the page to force a download.  But that's different from allowing the page to suggest a filename if the _user_ decides to download.

> The problem isn't in being able to select the name, but rather in being able
> to force a download at all.
> 
> Note that http has a specific mechanism for telling the browser that a
> response is so sensitive that it can't be cached on disk, only in memory.
> For example so that it doesn't linger around in case of a computer crash.
> 
> Many banks use this mechanism.
> 
> It would seem silly if we honored the bank telling us that a resource is so
> sensitive that we can't cache it to disk, and then turn around and gladly
> honor another websites request to not just store that resource in the cache,
> but permanently on the users desktop (or whatever the default save location
> is)
Please note that the download attribute has two features:

1. When the user simply clicks a link like <a href="..." download="foo.html"> the
   browser will pop up a save-as dialog, rather than navigating to the clicked link.
2. When the file is saved, either by simply clicking the link, or when right-clicking
   and choosing "save link as" the name of the saved file is determined by the
   value of the download attribute.

The '2' part I completely agree is not a security problem. The '1' part is what makes me nervous.
(In reply to Jonas Sicking (:sicking) from comment #18)
> Please note that the download attribute has two features:
> 
> 1. When the user simply clicks a link like <a href="..."
> download="foo.html"> the
>    browser will pop up a save-as dialog, rather than navigating to the
> clicked link.
>
>  The '1' part is  what makes me nervous.

but browsers already do that... they navigate to content browsers can display (html, text, image, pdf) and download content they cannot display. No issue what so ever.

And that is problem from application point of view... one has to do right click -> "save link as" to force download of any content. That's fine for web pages, but just annoying for applications.

But again, we already allow people to download dangerous executables from web without any concern... allowing them to simply download image or text or HTML?
We've always let *users* choose to download anything from any website.

Point 1 allows *webpages* to make the user download something from another site. That is totally different.

To make an example:

You can today go to your bank and download a bank statement.

You can also go to evil.com which could link to your bank statement and hope that you right-click and select "save link as". But evil.com can't do much other than hope that you right-click and choose that option.

Point 1 means that if you navigate to evil.com, evil.com can make you download your bank statement anytime you click anywhere on the page. With very little indication that that is what you are downloading.


I hope that makes the difference clear.
(In reply to Jonas Sicking (:sicking) from comment #20)
> I hope that makes the difference clear.

Yes, but I do not see any security risks here, evil.com will not get any secure data from that. You said it yourselves: there is always an option to right click. So if I want to be evil today, I can instruct user to right click and save data and the upload them back to my evil site. Tomorrow? I can let user download it with left click and upload those data to me... There's no new level of risk involved.

Frankly I'm beginning to be a little worried. This security paranoia is effectively colliding with creating real application development environment and sadly winning... I do understand the need for security, but at the end it's user responsibility. Nobody'd talking here about silently saving malicious data on user's computer and running them.
With such approach we would never have hypertext at all... because some sites can look like other (phishing), so wouldn't it be more secure to simply disallow user to click on link to another site, force every link to be within domain?

There can always be warning bar (as for GeoLocation) involved in case of cross-domain use of download attribute ("you are downloading data from remote site: disallow | allow this time | allow always access from evil.com to bank.com")
(In reply to Jonas Sicking (:sicking) from comment #20)
> We've always let *users* choose to download anything from any website.
> 
> Point 1 allows *webpages* to make the user download something from another
> site. That is totally different.
> 
> I hope that makes the difference clear.

By the way, again, browsers allow "*webpages* to make the user download something from another site." just not certain content at this point (a can download .exe, i cannot download .html without right click)
Arg, we're going in circles. Please read the rest of the comments in the bug.
So I've gotten a little lost reading all these comments.  I'm still trying to address a concrete problem with a web app I'm developing.  My app creates some content on the *client*, then, in order to deliver it to the user, embeds that content in a data url and calls window.open on the url.  The result is a dialog saying "you have chosen to open <large amount of gibberish>" with "open with" and "save as" options.  If I click "save as", the default filename is "8Z_onkyL" .  This really seems not particularly user friendly.  I'd like to improve that with a download= attribute that sets a more natural default filename.  I don't see this as creating a security threat, since a download from a _server_ sets the filename based on the tail of the download url, which can be anything a server wants it to be.
(In reply to David Karger from comment #24)
my point all the time :) but Jonas apparently has no issue regarding same-origin implementation, so this case you are describing will be addressed by FF developers, hopefully.

Brona
Please implement this!

As you can see from this demo: http://eligrey.com/demos/FileSaver.js/ saving a user-generated file in the browser is tremendously useful. The user can still decide whether they accept to download the file or not, once the download dialog/window appears.

Not implementing <a download=""> leaves us to throw users into an awfully confusing situation where the apparently downloaded file is simply opened in a new tab/window.

See also: http://developers.whatwg.org/links.html#downloading-resources
(In reply to Paul Neave from comment #27)
> See also: http://developers.whatwg.org/links.html#downloading-resources

Note that this is only in the "WHATWG" version of HTML for now.
I got a same use case and issue as David Karger's, same origin policy is fine. so maybe someone can implement this first as this one seems agreed by all.
This is extremely useful for downloading content generated in javascript. Currently the workflow is to send the content to the server, which then just spits it back out. The content does a round trip to the server which is completely unnecessary. My use case is for creating links like so:

<a download="mine.whatever" href="data:application/whatever;base64;...">Download</a>
(In reply to Bronislav Klučka from comment #6)

I must say I find it hard to understand the security issues.
since this is just an info attribute allowing to indicate a link as being downloadable. untill now you could only do this by setting a specific headers in the response form the server which is not an option if you want to set it from the client side (like in data URIs).

now I'm sure that we can all agree that in data URIs there is no security issue.
since this content will always come form the page origin and the download tag will only indicate the name of the downloaded file.
the only thing an "attacker" can do here, is force you to get a download dialog for file type that are usually run in the browser as image/text/html.
and since automatically running a file is way more dangerous then prompting for downloading it, I think we can rule this option out as being a security issue
* with that in mind the download tag should of course only allow setting of a file name and not the path for it to be saved so values like "/etc/hosts" "../.bashrc" should not be allowed, but this should be obvious and also if you get the file name from the headers.

The more serious security issue might be from using as you mentioned a cross origin request to a different domain, the user might think he is downloading a file form a illegitimate site but will actually be directed to an evil site download.

the first assumption is wrong. since the site triggering the request (using the download tag ) is the malicious site ( or a hacked site). so we might say that if the user consider this site as safe he is wrong, any malicious content can be added to the site and you do not need any cross origin request to get it.
more over lets say you still want to cause the user to download a malicious file form a 3rd party evil site. all this site has to do is set the response header to indicate the file is downloadable (as with any other download) and the user will get a download notification exactly as would happen with a download tag.

the more serious issue with CORS downloads is if a malicious site forces a download of a file form a legitimate  site and some how gets access to its content. so lets say I download the user gmail inbox page and explore its messages.
in this case an evil site will have to fool the user into downloading the file and uploading it back to the server, so lets say we have a gmail.com/inbox.html actually contains all the user mail messages and the attacker sites offers a download link for a coupon file, that should be uploaded to another evil site. the coupon will supposedly offer a 30% discount on a new Ipad. the download link will actually point to gmail.com/inbox.html and will download it as "30off.coupon", the if the user will download this file and upload it without checking it's content the evil site will get the user "coupon" and so its inbox content.
I think this security issue is much more serious then just the use of a download tag (user downloading and uploading files to an unknown site)
but it can be avoided by ignoring the download tag for setting the file name specifically for external files and only use it for data URIs (which are not affected form this issue).
developers will be able to set file names to data URIs, and if a specific link has to get a different name then what its URL indicates it can still be set in the server response headers.

Now I'm not coming to tell any one security is not an issue (you should always try to consider all the implications of implementing a new feature), I'm more trying to push the discussion and activity on this issue since I think this is a really needed feature and I'm trying to make the discussion about it more active.
(In reply to Yoni Jah from comment #34)

I'm totally agree with you.

There is *VERY* small security difference between: a) A without "download" attribute and b) with it. 

Let's compare it:

a) 1. User sees the link and read the text. The text can be everything (e.g. "my secure report").
   2. User hover the link and see the URL. It can be everything (e.g. http://mysite.com/report.xls) and can lead to *ANY* external site in the internet.
   3a. User click on the link. Depending on the server response -- it would either open it (e.g. HTML or text) or open dialog for saving the file (see step 4).
   3b. User do right-click on link and select to save the file.
   4. "Save file" dialog appear if user did not select "Do it automatically". The file name that is shown here depends on the server response (it could send header "Content-Disposition: attachment; filename='<name>'") and can be completely *DIFFERENT* from the file name mentioned in URL (e.g. virus.exe).
   5. User select what to do with file -- save or open it (in given program).

b) 1. the same
   2. the same
   3a. It would always lead to saving file in spite of server response.
   3b. the same
   4. the same but filename is got from "download" attribute, not server response.
   5. the same.

Let's summarize difference:
 1. User will be prompted to download file even if file is supported by browser -- e.g. HTML or image (if it was a ZIP, EXE or binary -- user would have been prompted to download anyway).
 2. Filename for saving will be generated by the page, not the server that holds the resource.

What would be the impact?
 1. User may download HTML / text / image instead of just opening it.
 2. User may have file name different than one provided by external resource.

That's it! Issue 1 is not a security at all, issue 2 as well -- user will be warned about the file type before downloading and opening it.

Also any file name generation can be easily done on server (and it is being used already) and we see no complains yet.

One more thing -- Google Chrome already implemented it since Chrome 14. They are really concerned about security (recall their sandbox model and long adoption of security-impacted features -- e.g. WebGL or files storage) but have it. They must had really good reasons to have it in mainline -- even not experimental branch.
As far as I can tell, the only real reason Mozilla refuse to implement the download attribute is because it is not a W3C standard. It is only in the WHATWG version of HTML: http://developers.whatwg.org/links.html#downloading-resources

The security risks are nonexistent and it would obviously make a good addition. So I'd suggest that those who are interested join the W3C lists at https://www.w3.org/Bugs/Public/ and propose that <a download> be added to the official W3C spec. Then perhaps Mozilla would be more willing to add support.
(In reply to Paul Neave from comment #36)
> As far as I can tell, the only real reason Mozilla refuse to implement the
> download attribute is because it is not a W3C standard. It is only in the
> WHATWG version of HTML:
> http://developers.whatwg.org/links.html#downloading-resources
> 
> The security risks are nonexistent and it would obviously make a good
> addition. So I'd suggest that those who are interested join the W3C lists at
> https://www.w3.org/Bugs/Public/ and propose that <a download> be added to
> the official W3C spec. Then perhaps Mozilla would be more willing to add
> support.

This is not true. Mozilla isn't against implementing something that is only specified in WHATWG version of HTML.
(In reply to Mounir Lamouri (:mounir) from comment #37)

> This is not true. Mozilla isn't against implementing something that is only
> specified in WHATWG version of HTML.

Then let's change status from "NEW" to "CONFIRMED" an make someone work on it :)
(In reply to Paul Neave from comment #36)
> As far as I can tell, the only real reason Mozilla refuse to implement the
> download attribute is because it is not a W3C standard. It is only in the
> WHATWG version of HTML:
> http://developers.whatwg.org/links.html#downloading-resources
> 
> The security risks are nonexistent and it would obviously make a good
> addition. So I'd suggest that those who are interested join the W3C lists at
> https://www.w3.org/Bugs/Public/ and propose that <a download> be added to
> the official W3C spec. Then perhaps Mozilla would be more willing to add
> support.

this is weird because in MDN this attribute is mention it as part of html5 -
https://developer.mozilla.org/en-US/docs/HTML/Element/a#attr-download
and it is very confusing since it doesn't mention that firefox doesn't actually support this feature
The main reason this isn't happening right now is because nobody is working on it.  I think we agree that the security concerns are manageable.  We're certainly ok with implementing same-origin download attribute, and probably a cross-origin download attribute with CORS.

And we're absolutely not opposed to implementing things that are only in the WHATWG version of HTML.
> Then let's change status from "NEW" to "CONFIRMED" an make someone work on it :)

NEW does mean CONFIRMED.

And thank you for volunteering!
Assignee: nobody → tonn81
(In reply to Boris Zbarsky (:bz) from comment #41)
> And thank you for volunteering!

Just wondering, is this a joke? Or is he starting to work on this for real?
_I_ certainly wasn't joking.  Just acting on comment 38's suggestion.
Let's set the real status of this bug.
Artem, if this bug is a priority for you, you can either vote it (near the "Importance" field) or work on it or pay someone else to work on it.
Assignee: tonn81 → nobody
(In reply to Yoni Jah from comment #39)
> this is weird because in MDN this attribute is mention it as part of html5 -
> https://developer.mozilla.org/en-US/docs/HTML/Element/a#attr-download
> and it is very confusing since it doesn't mention that firefox doesn't
> actually support this feature
True. I've added the NeedsCompatTable tag on the page. It would be nice to have a compatibility table that takes attributes into account, very much like what can be seen in the <input> page https://developer.mozilla.org/en-US/docs/HTML/Element/Input

I take this opportunity to inform you that Mozilla organizes a doc sprint in London next week-end https://wiki.mozilla.org/MDN/Doc_Sprints
It can be attended in-person if you're in London (in the London MozSpace) or virtually (everyone just connects to the same IRC channel).
Contact me or Janet Switcher (jswisher@mozilla.com) if you're interested in participating, even if just for one hour.
I would be interested in working on this, but I am not really sure how to fix this.
I already added a download attribute to nsIDOMHTMLAnchorElement. Than I looked nsDocShell::OnLinkClickSync and I figured I somehow need to change something so we end up calling nsIExternalHelperAppService. The hard part I think is changing the path through all of this code.
My inclination would be to add a filenameHint attribute to nsIChannel that GetFilenameAndExtensionFromChannel would attempt to use first. Dunno how keen the necko people would be on that, so let's get Jason's thoughts.
You may find the patch in Bug 665216 to be of use.
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #48)
> You may find the patch in Bug 665216 to be of use.
Great Kyle, this patch showed me an easy way to fix this! Combining your patch and my patch, we should be able to force a download and even specify a file-name.

I just tested this with a Blob and it seem to work. One thing that needs to be looked at, how we could allow drag and drop downloading like Chrome.
Status: NEW → ASSIGNED
QA Contact: evilpies
Assignee: nobody → evilpies
QA Contact: evilpies
Attached patch wip patch (obsolete) — — Splinter Review 
With this patch, clicking on the download link, should show a download box. I still need to look into the same-origin restriction.

<script>
var blob = new Blob(['test']);

var a = document.createElement('a');
a.download = true;
a.href = window.URL.createObjectURL(blob)
a.textContent = 'Download';

window.document.body.appendChild(a);
</script>
Depends on: 665216
For the same origin check, you can probably use GetASCIIOrigin or GetUTFOrigin from nsContentUtils. I guess the check has to happen between the current document and the targeted download?
Depends on: 795442
> My inclination would be to add a filenameHint attribute to nsIChannel that 
> GetFilenameAndExtensionFromChannel would attempt to use first

Talked with biesi on IRC--we came to conclusion that the right thing here would be to make nsIChannel.contentDispositionFilename no longer readonly, so code could write to that.  Filed bug 795442
Attached patch WIP v2 (obsolete) — — Splinter Review 
This now depends on my patch in Bug 795442. I also implemented some same-origin check, no idea if this is the right way.
Attachment #663804 - Attachment is obsolete: true
The security check is certainly wrong afaict.  I thought I'd told someone how to do it right, already....

In any case, the right place to do it is probably a CheckMayLoad check at the place where we do the existing CheckLoadURI for link loads.
Keywords: dev-doc-needed
Attached patch WIP v3 (obsolete) — — Splinter Review 
Now with the ability to name the downloaded file. I removed the security check and some stuff still behaves _right_, weird.
Attachment #666200 - Attachment is obsolete: true
Test page, going to add a few examples:
http://jsfiddle.net/G5hyy/
(In reply to Boris Zbarsky (:bz) from comment #54)
> The security check is certainly wrong afaict.  I thought I'd told someone
> how to do it right, already....
> 
> In any case, the right place to do it is probably a CheckMayLoad check at
> the place where we do the existing CheckLoadURI for link loads.

I don't see either of these being used in OnLinkClickSync, InternalLoad or DoURILoad. I think we might want to allow navigating to the linked element even when it is on a different domain, so in practice ignore the download attribute. Would this allow for this flexibility? Chromium allows downloading cross-domain stuff btw.
> I don't see either of these being used in OnLinkClickSync, InternalLoad or DoURILoad.

Yes, they happen way before that.  See nsContentUtils::TriggerLink.

> so in practice ignore the download attribute. Would this allow for this flexibility?

Yes.  You'd just need to make the download attribute bits an argument to OnLinkClick, and get it off the node in TriggerLink.
Attached patch WIP v4 (obsolete) — — Splinter Review 
Thanks to bz's help, this is now working correctly. He also already told me about the fun that is ahead of me to write tests for this. I am going to look at Drag 'n Download in another bug.
Attachment #668574 - Attachment is obsolete: true
I need some help with the tests. I tried to search for 'Content-Disposition' assuming that test for that would be useful and they don't look like that. Searching for 'download' comes up with test for the download manager.

I actually just want to test this in a very simple way.

If we click on a link with the download attribute, make sure the download box opens up with the right filename in it. In some cases we don't want to allow the download (cross-origin), so we should test whether we navigated to that page.
> make sure the download box opens up with the right filename in it.

You mean the filepicker?  That would be kinda bad, since it's a modal OS dialog, so if it comes up you're sort of stuck.

I think you basically want to see whether you can repurpose the download manager tests here.  :(
This should follow browser settings, either download directly to download folder with suggested name or open filepicker (Save As dialog)
We're talking about the _test_ here, not what happens when a user uses the browser.  In the latter case, it'll follow browser settings, obviously.
Tom, can't you use nsIFilePicker mock? We have that in SpecialPowers if I remember correctly, The default file name should be available from nsIFilePicker.defaultString, right?
I am talking about this: http://imgur.com/UTM94.
Can we implement a mock for that?
(In reply to Josh Matthews [:jdm] from comment #67)
> There is already a MockFilePicker object:
> http://mxr.mozilla.org/mozilla-central/search?string=mockfilepicker

Josh, that's what comment 64 was saying but that mock doesn't implement the "Do you want to save or open this file" dialog. We need another mock for that I would say.
I think http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/tests/chrome/test_unknownContentType_dialog_layout.xul could be edited to test something like this. But it feels kinda wrong.
Attached patch Test WIP (obsolete) — — Splinter Review 
The way I implemented the wait for window, test, continue is ultra ugly. I hope we have some better way to do this. This is lacking tests for cross-origin links that should just navigate away.
Attached patch v1 (obsolete) — — Splinter Review 
This is more or less the same as WIP v4. bz suggested truncating the aTargetSpec, because <a download target="_blank"> should start a download instead of navigating away.
Attachment #678054 - Attachment is obsolete: true
Attachment #683577 - Flags: review?(bugs)
Attached patch tests v1 — — Splinter Review 
This tests:
- data uris
- video url with empty download
- video url with explicit file name
- data uri with target
- cross origin url

I just tests that the "Opening test.file" "Open With" dialog is opened with the correct filename.
Attachment #682758 - Attachment is obsolete: true
Attachment #683580 - Flags: review?(bugs)
Comment on attachment 683577 [details] [diff] [review]
v1

># HG changeset patch
># Parent cd8533b0fae7641fca51d4adf5f61bbfb1d719ec
># User Tom Schuster <evilpies@gmail.com>
>
>diff --git a/content/base/src/nsContentUtils.cpp b/content/base/src/nsContentUtils.cpp
>--- a/content/base/src/nsContentUtils.cpp
>+++ b/content/base/src/nsContentUtils.cpp
>@@ -4668,37 +4668,56 @@ nsContentUtils::TriggerLink(nsIContent *
> 
>   nsILinkHandler *handler = aPresContext->GetLinkHandler();
>   if (!handler) {
>     return;
>   }
> 
>   if (!aClick) {
>     handler->OnOverLink(aContent, aLinkURI, aTargetSpec.get());
>-
>     return;
>   }
> 
>   // Check that this page is allowed to load this URI.
>   nsresult proceed = NS_OK;
> 
>   if (sSecurityManager) {
>     uint32_t flag =
>       aIsUserTriggered ?
>       (uint32_t)nsIScriptSecurityManager::STANDARD :
>       (uint32_t)nsIScriptSecurityManager::LOAD_IS_AUTOMATIC_DOCUMENT_REPLACEMENT;
>     proceed =
>       sSecurityManager->CheckLoadURIWithPrincipal(aContent->NodePrincipal(),
>                                                   aLinkURI, flag);
>   }
> 
>+  // A link/area element with a download attribute is allowed to set
>+  // a pseudo Content-Disposition header.
>+  bool forceDownload = false;
>+  nsString fileName;
>+  if ((aContent->Tag() == nsGkAtoms::a || aContent->Tag() == nsGkAtoms::area) &&

aContent->IsHTML(nsGkAtoms::a) || aContent->IsHTML(nsGkAtoms::area)



>+      aContent->GetAttr(kNameSpaceID_None, nsGkAtoms::download, fileName)) {
>+    forceDownload = true;
>+  }
>+  // For security reasons we only allow websites to declare same-origin resources
>+  // as downloadable. If this check fails we will just do the normal thing
>+  // (i.e. navigate to the resource).
>+  if (forceDownload) {
>+    if (NS_FAILED(aContent->NodePrincipal()->CheckMayLoad(aLinkURI, false, true))) {
>+      forceDownload = false;
>+    }
>+  }

This all could be
bool forceDownload = NS_SUCCEEDED(proceed) &&
                     (aContent->IsHTML(nsGkAtoms::a) || aContent->IsHTML(nsGkAtoms::area)) &&
                     aContent->GetAttr(kNameSpaceID_None, nsGkAtoms::download, fileName) &&
                     NS_SUCCEEDED(aContent->NodePrincipal()->CheckMayLoad(aLinkURI, false, true));



>     NS_IMETHOD OnLinkClick(nsIContent* aContent,
>         nsIURI* aURI,
>         const PRUnichar* aTargetSpec,
>+        bool aForceDownload,
>+        const nsString& aFileName,
Since the method takes PRUnichar* params anyway, perhaps use that for aFileName too.
That way null aFileName could mean no forced download.
Forced to pass EmptyString around feels a bit ugly in this case.



Would like to see a new patch.
Attachment #683577 - Flags: review?(bugs) → review-
Comment on attachment 683580 [details] [diff] [review]
tests v1

Would be nice if someone more familiar with firefox UI code could look at this too - to ensure that we test all the cases we should be testing.
Attachment #683580 - Flags: review?(bugs) → review+
> aContent->IsHTML(nsGkAtoms::a) || aContent->IsHTML(nsGkAtoms::area)

I think we should allow svg:a too.  And non-html:area would never call this method anyway..

> Since the method takes PRUnichar* params anyway, perhaps use that for aFileName too.
> That way null aFileName could mean no forced download.

Or we could use a void string to indicate that?
(In reply to Boris Zbarsky (:bz) from comment #75)
> 
> Or we could use a void string to indicate that?
That would be ok too if the other parameter was changed to be const nsAString&.
I want some consistency in the parameter types :)
(In reply to Boris Zbarsky (:bz) from comment #75)
> I think we should allow svg:a too.
Well, there is no spec for that, I believe, but yeah, makes sense.
Attached patch v2 (obsolete) — — Splinter Review 
Addressed review comments, but still need to change the oder parameters to nsAString.
Attachment #683577 - Attachment is obsolete: true
Attached patch v2.1 — — Splinter Review 
I am now using NullString(), which makes this a lot nicer.
Attachment #685231 - Attachment is obsolete: true
Attachment #685244 - Flags: review?(bugs)

        Attachment #685259 -
        Flags: review?(bugs)

        Attachment #685259 -
        Flags: review?(bugs) → review+

    
    

    
  
Comment on attachment 685244 [details] [diff] [review]
v2.1

>+    if ((aContent->Tag() != nsGkAtoms::a && aContent->Tag() != nsGkAtoms::area) ||

I'd prefer using aContent->IsHTML(...), and  aContent->IsSVG(...)
That way it is clear which cases we're handling here.

> nsDocShell::InternalLoad(nsIURI * aURI,
>                          nsIURI * aReferrer,
>                          nsISupports * aOwner,
>                          uint32_t aFlags,
>                          const PRUnichar *aWindowTarget,
>                          const char* aTypeHint,
>+                         const nsAString &aFileName,
const nsAString& aFileName



>+   * @param aFileName       - Mon-void when link should be downloaded as.
>+                              the given filename.
Non-null
And there is extra . after as
Should there be 'the' before 'link'?


>    * @param aPostDataStream the POST data to send
>+   * @param aFileName non-void when link should be downloaded as the given file
non-null


>+   * @param aFileName non-void when link should be downloaded as the given file
non-null



Could you please test various protocols. You seem to test http: and data:.
Could you make sure also https: work. And ftp should work too, but I'm not sure how to
write mochitest for ftp: case.
I wonder how javascript: should be handled. Does the spec say anything about it?

        Attachment #685244 -
        Flags: review?(bugs) → review+

    
    

    
  
I guess javascript: with download shouldn't do anything, and your patch probably even handles that, 
but please add a test.

    
    

    
  
Or no. javascript: channel doesn't seem to throw when setting contentdisposition.

Downloading the script data would be ok too. I don't see anything related to this in the spec.
Please test what other browsers do. A followup patch might be needed to sort this out.

    
    

    
  
I will look at adding test for the other protocols. In Chrome a link with download and javascript: just does nothing.

    
    

    
  
WebKit doesn't implement the whole "javascript: can return value" thing except in the special case of iframes; they actually handle it as a complete special-case, not via normal loading codepaths.  So testing Chrome for javascript: is pretty pointless... :(

    
    

    
  
Well, we need to figure out what javascript: + download should do in Gecko.
And whatever we decide, have a test for that.

    
    

    
  
hmm, i currently develop a webapp that, on click of a link, does the following:

1. prepare Blob https://developer.mozilla.org/en-US/docs/DOM/Blob
2. create object url https://developer.mozilla.org/en-US/docs/DOM/window.URL.createObjectURL
3. create link tag with download attribute
4. fake a click on that created link

it would be quite useful to let a link with href="javascipt:…" just download the URL that is returned by the supplied javascript expression.

then my code wouldn’t look like above, but let the link tag’s href just call a function consisting of steps 1&2 and returning the object url.

    
    

    
  
I think we should do whatever is simplest implementat-wise. If simply ignoring the download attribute in that case is the simplest thing to do, I think that's fine. If running the javascript and offering to download any content that is returned, then I think that's totally fine too.

    
    

    
  
(In reply to flying sheep from comment #87)
> hmm, i currently develop a webapp that, on click of a link, does the
> following:
> 
> 1. prepare Blob https://developer.mozilla.org/en-US/docs/DOM/Blob
> 2. create object url
> https://developer.mozilla.org/en-US/docs/DOM/window.URL.createObjectURL
> 3. create link tag with download attribute
> 4. fake a click on that created link
> 
> it would be quite useful to let a link with href="javascipt:…" just download
> the URL that is returned by the supplied javascript expression.

That is not how javascript URLs work. We wouldn't download the URL returned by the expressed, but we'd download what the expression returned.

If you have a Blob object that you want the user to download, either set the href attribute to the blob: url, or use the FileSaver API (once that's implemented)

    
    

    
  
(In reply to Jonas Sicking (:sicking) from comment #89)
> If you have a Blob object that you want the user to download, either
> set the href attribute to the blob: url, or use the FileSaver API
> (once that's implemented)

was just an idea. but since a onclick eventlistener is executed before the user clicks, one also can just set the href there: http://jsfiddle.net/8NKmJ/

(i left out the additional onfocus for non-mouse users in the onmouseover case: i guess it’s needed if the link is never actually hovered?)

    
    

    
  
(In reply to Olli Pettay [:smaug] from comment #81)
> Comment on attachment 685244 [details] [diff] [review]
> v2.1
> 
> >+    if ((aContent->Tag() != nsGkAtoms::a && aContent->Tag() != nsGkAtoms::area) ||
> 
> I'd prefer using aContent->IsHTML(...), and  aContent->IsSVG(...)
> That way it is clear which cases we're handling here.
>
> > nsDocShell::InternalLoad(nsIURI * aURI,
> >                          nsIURI * aReferrer,
> >                          nsISupports * aOwner,
> >                          uint32_t aFlags,
> >                          const PRUnichar *aWindowTarget,
> >                          const char* aTypeHint,
> >+                         const nsAString &aFileName,
> const nsAString& aFileName
> 
> 
> 
> >+   * @param aFileName       - Mon-void when link should be downloaded as.
> >+                              the given filename.
> Non-null
> And there is extra . after as
> Should there be 'the' before 'link'?
> 
> 
> >    * @param aPostDataStream the POST data to send
> >+   * @param aFileName non-void when link should be downloaded as the given file
> non-null
> 
> 
> >+   * @param aFileName non-void when link should be downloaded as the given file
> non-null
> 
> 
I fixed these, but it would be great if you could use the review feature.
> 
> Could you please test various protocols. You seem to test http: and data:.
> Could you make sure also https: work. And ftp should work too, but I'm not
> sure how to
> write mochitest for ftp: case.
> I wonder how javascript: should be handled. Does the spec say anything about
> it?
I added a test for javascript:. I manually tested https:. But I am still missing tests for https: and ftp:. I am not sure how to these those.

    
    

    
  
I just committed the current stuff. I am going to look into the other tests next week.

https://hg.mozilla.org/integration/mozilla-inbound/rev/a12cd43e6e02
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2a92abab0d1
Whiteboard: [leave open]

    
    

    
  
Thanks Tom for the implementation :)

For consistency, can we merge this topic too: https://bugzilla.mozilla.org/show_bug.cgi?id=367231

Possibly, offering this solution as the final one?
I'm interested to know what people think of it.

    
    

    
  
Tom: You rock!! This is awesome! Thank you so much for your help. Let us know if you are interested in helping on other things once this is fully fixed!

    
    

    
  
So I think for ftp:// I need to load a page from ftp:// otherwise the download should be disallowed anyways.

    
    

    
  
Yes, a different protocol or a different port means that it's a different origin.

    
    

    
  
Are there any security issues related with this feature? Like creating a script that will auto download an executable file on the system? Should there be any filename filters?

Thanks

    
    

    
  
Firefox nightly 20.0a1 (2012-12-04) fires onbeforeunload event. I have no target set (target="_self" or anything else => same behavior).
Is this correct? Can i prevent this event?

Thanks

    
    

    
  
This is a legitimate problem. Basically we just need to replicate what we do in the javascript: case and suppress it.

    
    

    
  
Excellent, this even behaves well with middle‐click (opens content in new tab instead of download)! Have a bug open for Chromium http://code.google.com/p/chromium/issues/detail?id=116376 with their download behaviour overriding user intent.

    
    

    
  
The problem in Comment 99 is actually pre-existing. This also happens for files served with Content-Disposition: attachment. I filled follow-up bug 818559 for this.

    
  
Blocks: 818559

    
    

    
  
We don't have a test infrastructure for FTP at all, so there's no point worrying about adding an ftp:// test.

    
    

    
  


  

        Attachment #689272 -
        Flags: review?(bugs)

    
    

    
  
I just had one thought about security.
the file name form the download attribute should not change the original way firefox handles file names, so if the file already exists in the download folder the file should be saved with a number suffix (as happens with current downloads).

another thing that should be checked is that the filename only contains file names and no directories and if it does they should be ignored so we are sure the site is not able to set to local directory where the file will be saved.

I'm sorry if I'm just stating the obvious but I tried to see if this issue was discussed.
(I also tried to look in the code but I don't understand it we'll enough to understand how it'll behave)

p.s the work your guys are doing here is awesome and I'm sorry I couldn't be more helpful

    
    

    
  
Yoni, the filename from this attribute is treated exactly like a filename from an HTTP Content-Disposition header.  In fact, the implementation basically synthesizes such a header, and then lets the rest of the system work as it normally would.  So all those things should be handled fine with this patch, I think.

        Attachment #689272 -
        Flags: review?(bugs) → review+

    
  
Blocks: 819373

    
    

    
  
Thank you Olli. This bug is now done, I filed a Bug 819373 for handling Drag and drop.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d6d585622ca7
No longer blocks: 819373
Whiteboard: [leave open]

    
  
Blocks: 819373

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/d6d585622ca7
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20

    
    

    
  
' Download "just some video" ' Just opens a link to the video rather than downloading it.
Similarly with images, the images open without downloading them with the appropriate name.

Additionally, shouldn't this download function affect "Save As..."?

    
    

    
  
Is this really working as expected?
In Chrome, the download attribute behaves like the "Save As..." function on any type of content, not just data and javascript urls.

    
    

    
  
>' Download "just some video" ' Just opens a link to the video rather than downloading it.
>Similarly with images, the images open without downloading them with the appropriate name.
Do you mean the test committed by this patch? Where are you getting this from?

>Additionally, shouldn't this download function affect "Save As..."?
In which way?

>In Chrome, the download attribute behaves like the "Save As..." function on any type of >content, not just data and javascript urls.
Could you please show us an example where the download is not working as expected? Please not we have stronger restrictions for the origin of the data you are allowed to download than Chrome, because we only allow same-origin downloads.

You can download from all kinds of URI types as along as they are same-origin.
Here an example for an image download. http://jsfiddle.net/vhbmQ/1/

    
    

    
  
>we have stronger restrictions for the origin of the data you are allowed to download than Chrome, because we only allow same-origin downloads.
Okay, I see. This is a pretty heavy restriction, especially since downloadable content is usually served from a CDN or an alternate domain.

    
    

    
  
Antoine, it's a necessary restriction to prevent this functionality being used to attack users.  Please read the whole bug: this was discussed at some length....

    
    

    
  
(In reply to Boris Zbarsky (:bz) from comment #113)
> Antoine, it's a necessary restriction to prevent this functionality being
> used to attack users.

I get the feeling that everyone is overthinking this a little.
Wouldn't limiting the download location to certain areas, ensuring the name attribute does not contain any executable extensions or directory modifiers (such as / or \) and forcing the attribute to ignore certain unicode characters (such as RTL override) would stop the majority of exploits?

Alternatively, have the function turned off be default, or warn the user when it's being used.

    
    

    
  
(In reply to Tom Schuster [:evilpie] from comment #111)
> >' Download "just some video" ' Just opens a link to the video rather than downloading it.
> >Similarly with images, the images open without downloading them with the appropriate name.
> Do you mean the test committed by this patch? Where are you getting this
> from?

The test in here: https://hg.mozilla.org/mozilla-central/rev/d6d585622ca7

> http://jsfiddle.net/vhbmQ/1/

Image download worked on that, but it doesn't seem to work when using a userscript (Ihavenoface's 4chan-x) with GreaseMonkey.
HTML produced:
<a download="8269171301_b6fed812cc_b.jpg" href="http://images.4chan.org/a/src/1355530839672.jpg" class="download_link entry focused">Download file</a>
All it does is open the image file in tab instead of in a download window. (Link will most likely be dead by the time you see this.)

> >Additionally, shouldn't this download function affect "Save As..."?
> In which way?

By changing the default name into the one recommended by the download attribute.
Currently if you do "Save Link/Image As..." it keeps the file's original name rather than using the recommended title given by the download attribute. I use Save As a lot as I like to categorize where I download specific things.
Depends on: 835198

    
    

    
  
If html5 fullscreen mode is activated the save dialog exit the fullscreen mode.

    
    

    
  
I checked on Firefox 21 (Aurora) and this not work.
If I click on Video.ogg in test page the movie opened in the browser and not dowloaded.
https://hg.mozilla.org/mozilla-central/raw-file/d6d585622ca7/browser/base/content/test/download_page.html

    
    

    
  
That server is sending an explicit Content-Disposition header for that URL, which overrides the hint from the "download" attribute.

    
    

    
  
I checked this on Chromium and the file download and not open in the browser.

    
    

    
  
(In reply to Amiad from comment #119)
> I checked this on Chromium and the file download and not open in the browser.
It is its own issue. Could you file a new bug, please? That will allow the spec/implementation investigation to happen in this new bug instead of this one.
Thanks Amiad :-)

    
    

    
  
> I checked this on Chromium and the file download and not open in the browser.

Yes, Chromium implements @download quite differently from us once you start testing the edge cases.  Not least because the spec is ... lacking.

    
    

    
  
Yep, file a new bug for this one. It's not a spec issue, it's a browser way to handle content. As mentioned, FF tries to "play" this media file, so there should be a rule that will override this process when the link is inside the download attribute.

    
    

    
  
> FF tries to "play" this media file

Because the server _explicitly_ tells it to, by sending "Content-Disposition: inline".  The open spec question is whether that should or shouldn't override the download attribute.  In our implementation, a server-provided Content-Disposition header always wins.

Note that the spec does not define a specific processing model for @download in terms of whether the download actually happens, so both our behavior and Chrome's are spec-compliant.

    
    

    
  
Though the spec _does_ define what should happen when the @download filename and the Content-Disposition filename don't agree and you're downloading: the Content-Disposition filename wins.

    
    

    
  
Nice, thx for letting us know, then it's a fixed topic. :)

    
    

    
  
I've edited the MDN documentation with this two bits of information (priority to C-D filename according the spec + spec silent with C-D:inline and this attribute, with different implementations across browsers. See: https://developer.mozilla.org/en-US/docs/HTML/Element/a

    
    

    
  
IMO the @download attribute should win both when it comes to what filename to use, and when it comes to using "inline" or "attachment" behavior.

People generally have an easier time getting markup right than getting headers right. That's one of the main reasons we have the @download attribute at all.

    
    

    
  
I’d also encourage @download to override C-D header, as a servers behaviour changing would negatively affect static pages.

    
    

    
  
If you want the spec to change, please raise spec issues.

    
    

    
  
the header is better.its a cross browser solution, it works on ie.if people need use  download attribute, I think its  fine to spend a  little time to learn it.

    
    

    
  
the header is better.its a cross browser solution, it works on ie.if people need use  download attribute, I think its  fine to spend a  little time to learn it.

    
    

    
  
The problem mentioned in comment #116 (exit fullscreen mode) is getting better.
The fullscreen still remains but if you close the save dialog the message "xyz.com is now fullscreen ..." appears.
I think the problem is that the firefox main window gets the focus back after closing the save dialog. This message also appears if you switch to another app and go back to fullscreen firefox window.

Tested with firefox nightly 22.0a1 (2013-03-27) on Window 7.

    
    

    
  
Well, now I can detect download attribute support ("download" in document.createElement("a")), but it will still not work for my use case, so I present the user a broken UI.

What I do:
I wrote a media player like interface for magnatune.com. On the album info page I present the user with download links to the songs (if they are signed-in). I use <a download="" ...> but the Ogg versions of the tracks still start to play in Firefox (20.0b7, 21.0a2, 22.0a1 on Linux x86_64 and 20 beta on Android ARM). Firefox 20 beta for Android even does nothing for the m4a and mp3 versions (shows a new about:blank tab) but it indeed downloads the wav version.

E.g. see (if you have a Magnatune account):
http://greattuneplayer.jit.su/#/album/Bootstrap%20Physics

Is there any other way to force a download? Maybe via some app-only API?

    
    

    
  
Ah and Magnatune doesn't send a Content-Disposition header:

HTTP/1.1 206 Partial Content
Date: Mon, 01 Apr 2013 16:46:34 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Sun, 24 Feb 2013 00:41:47 GMT
Etag: "a5004f5-4d7f43-4d66db07da64d"
Accept-Ranges: bytes
Content-Length: 4836603
Content-Range: bytes 242248-5078850/5078851
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: audio/ogg

    
    

    
  
_If_ those are the headers that get sent, it should work.

Please file a bug with usable steps to reproduce (e.g. directions on getting a test magnatune account or a way to reproduce without) or at least an HTTP log of the interaction.

    
    

    
  
I copied these headers with Firebug. Using curl (which doesn't do a range request) I get:

curl -I 'http://panzi:******@download.magnatune.com/music/Paul%20Avgerinos/Lovers/01-In%20My%20Arms-Paul%20Avgerinos.ogg'

HTTP/1.1 200 OK
Date: Mon, 01 Apr 2013 17:34:18 GMT
Server: Apache/2.2.14 (Ubuntu)
Last-Modified: Sun, 27 Jan 2013 00:43:05 GMT
ETag: "a50061f-48d1cc-4d43a718b7840"
Accept-Ranges: bytes
Content-Length: 4772300
Content-Type: audio/ogg

Which still has no Content-Disposition. It's a static HTTP server using HTTP Basic Auth. (no SSL/TLS) Maybe the HTTP Auth stuff throws Firefox off? I had to implement something like 4 different workarounds (different browsers and versions thereof) to create a "login" feature for an other domain that uses HTTP Auth so one can play the member "streams".

But I'll file a bug later (maybe not until tomorrow evening).

    
    

    
  
If you're seeing a range request, that's already way past the point where @download matters.  Hence my request for an actual HTTP log, which would show everything going back and forth, not just a quote from some later irrelevant part of the log...

But in any case, comment 136 has the info needed: that's a cross-site load, and we don't allow forcing downloads cross-site.  No need for a separate bug.

    
    

    
  
There is a problem with downloading a file when it extension is „js”, and URI scheme is „data:”, and operating system is Windows.

For example, when I clicked on any of the hyperlinks:

<a href="data:application/javascript,alert('Hello')" download="hello.js">Download</a>, 
<a href="data:application/javascript;base64,YWxlcnQoJ0hlbGxvJyk=" download="hello.js">Download</a>,
<a href="data:text/plain,alert('Hello')" download="hello.js">Download</a>

file is not saved in destination directory, but is displayed in Firefox's download manager.

This problem occurs in Firefox Nightly 22.0a1 (2013-03-30) for Windows 7 (64-bit), and for Windows XP (32-bit), but not for Ubuntu (64-bit).

    
    

    
  
(In reply to Boris Zbarsky (:bz) from comment #137)
> But in any case, comment 136 has the info needed: that's a cross-site load,
> and we don't allow forcing downloads cross-site.  No need for a separate bug.

I see. Then I'll blacklist Gecko based browsers in my app. Why would I need this download attribute if I host the file myself? (except for data and object URLs) If the file is hosted on my domain I could change Content-Disposition.

    
    

    
  
> Why would I need this download attribute if I host the file myself?

Because lots of people apparently can't change content-disposition.

But yes, the point of this attribute is mostly for data and blob urls!

    
    

    
  
Any updates on comment 132? This bug still exists in firefox nightly 24.0a1 (2013-05-16).

    
    

    
  
Please file a separate bug. Totally unrelated with the download attribute.
Depends on: 874009

    
    

    
  
I've added a link to window.URL.createObjectURL in the doc of HTMLAnchorElement.download. With this I think we are done! :-)
Keywords: dev-doc-needed → dev-doc-complete

    
    

    
  
FWIW, according to the spec editor, the spec specifies that

<a download href="someurl.html">

should bring up a dialog even when someurl.html returns with

Content-Disposition: inline; filename="B.txt"
or
Content-Disposition: inline


However in both cases the filename "someurl.html" should be the suggested name.


It's unclear if the spec always defined things that way, but it doesn't really matter, it's the behavior specified now.

If this is not the current behavior in Firefox, it would be great if someone could file a separate bug on that.

    
    

    
  
I'm sorry to bring this up again regarding cross-origin a@download links:

The case against allowing cross-origin downloads is centered around the premise that visitors of an [evil] site (eg, discountipads.com) could unknowingly download a file from a site containing their own personal information (eg, gmail.com) and save it to their disk using a misleading name (eg, "discount.coupon") AND THEN proceed to another malicious page where they manually upload that same file they just downloaded. This is quite far-fetched in my opinion, and anyone who would succumb to such trivial trickery perhaps does not belong online in the first place. I mean c'mon...Click here to download our special discount offer and then re-upload it through our special form! Seriously? Download our special offer and then email it to this Yahoo address for a big discount! Do the people who fall for these things even know how to do email attachments?

I'm all for browser security, but if the good people of Chromium have no problem with this I don't see why Firefox has to completely banish it. At the very least I'd like to see a preference in about:config to enable cross-origin @download for "advanced" users (default it to false). Even better would be a confirmation box similar to: "Although this page is encrypted, the information you submit through this form won't be" or: "This page is requesting to install addons" or: "Files downloaded from the web may harm your computer" or even: "The security certificate of this page is invalid" ...y'know what I mean? There are myriad ways to heighten the user's awareness and inform them this might not be safe. One extra click and a short (or long?) delay is enough to let them assess the risk.

As the web grows, and the use of CDNs grows, and the presence of advanced web-apps grows, and the need to manage files hosted across servers grows, features like @download will become more important. And when a browser like Chrome supports it fully whereas Firefox does not, this is not a win for Firefox.

In short, I think that mitigating the potential evil uses of @download by simply ignoring the attribute in cross-origin scenarios is a woefully ill-thought move. I'm not saying the risk is entirely non-existent, quite the contrary: I am saying there are plenty of risky things one does online in the course of his day...downloading ANY file is high among them. Why not work around that issue with a well-thought user experience?

    
    

    
  
One issue I notice that doesn't happen in Chrome (which also supports the "download" attribute) is that on Firefox it currently doesn't work with "jpg" files.

So if you have:

<a href="test.jpg" download="test.jpg">Text here</a>

Instead of bringing up the download dialog it just opens the image in the browser. That's really not the desired behavior at all.

Javier

    
    

    
  
Javier, http://web.mit.edu/bzbarsky/www/testcases/download-attribute/test-jpeg-download.html works just fine for me.  Presumably there is more going on with your testcase (e.g. is your server sending explicit "Content-Disposition: inline" headers?).

    
    

    
  
How can I check that? Not sure what that is really, but the test case you sent works correctly...

    
    

    
  
> How can I check that?

Look at the HTTP headers in your server's response?

    
    

    
  
That doesn't seem to be the issue, according to this site http://http-headers.online-domain-tools.com/

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.3.0.GA_CP01 (build: SVNTag=JBPAPP_4_3_0_GA_CP01 date=200804211657)/Tomcat-5.5
responseHasData: true
Content-Type: text/html;charset=utf-8
Vary: Accept-Encoding
Content-Encoding: gzip
Cache-Control: max-age=14400
Date: Thu, 12 Sep 2013 16:10:08 GMT
Content-Length: 13
Connection: keep-alive

    
    

    
  
OK.  Then, assuming that's a same-origin link, it should work.  Do you have a link to a non-working testcase?

    
    

    
  
Well, I don't. The environment is on local so I can't share a link. Could that be the issue maybe?

    
    

    
  
Unless you mean it's a file:// URI, no.

You could try creating a log using https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging#Logging_HTTP_activity and attaching it here, just in case the headers we see are different from what the tool from comment 150 was showing you...

Also, worth making sure you don't have any extensions interfering.

    
    

    
  
In a while I'll go to another stating, I'll test it there and let you know if it's solved. Thanks for the help so far :)

    
  
Blocks: 923415

    
  
Depends on: 940568

    
    

    
  
>When the user clicks such a link, the user will be prompted if they want to download. It seems very easy for the user to make the mistake of thinking that something on the original website is being downloaded, and not something from bank.com.

1 why are you thinking that is a security issue? The FF download dialog displays the domain and protocol to help user understand from where file is downloaded and make right decision
2 We can additionally display warning that download was forced by referrer page, not the http header.
3 Also we can check CORS http headers.

    
  
Flags: needinfo?(jonas)

    
    

    
  
You may want to read the discussion in bug 676619.

    
    

    
  
Please open a new bug if you think we should loosen the same-origin restriction.

I'll leave the decision up to the security team, so probably cc dveditz and :sworkman
Flags: needinfo?(jonas)

    
    

    
  
(In reply to Jonas Sicking (:sicking) No longer reading bugmail consistently from comment #18)




Please note that the download attribute has two features:


    

  1. When the user simply clicks a link like <a href="..."
    
download="foo.html"> the
    
browser will pop up a save-as dialog, rather than navigating to the
    
clicked link.
    2. 

  2. When the file is saved, either by simply clicking the link, or when
    
right-clicking
    
and choosing "save link as" the name of the saved file is determined by
    
the
    
value of the download attribute.
    3. 



The '2' part I completely agree is not a security problem. The '1' part is

what makes me nervous.




Since #1 above was the security concern for linked resources on another server, could at least #2 be implemented in the case of right-click save-as? I would really like the file name in the save as dialog to be taken from the value of the download attribute if present, even if the presence of that attribute does not automatically cause a normal click to initiate a download.



          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: