New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 373182 link

Starred by 163 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Regression

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Wrong file name when clicking on data-uri anchor with "download" tag

Project Member Reported by yori@google.com, May 14 2014

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.132 Safari/537.36

Example URL:
http://www.yoriz.co.uk/chrome-test.html

Steps to reproduce the problem:
1. Go to http://www.yoriz.co.uk/chrome-test.html
2. Click on the "Download CSV" link
3. The latest Chrome downloads a file named "download"

What is the expected behavior?
It should download the same file but with the name "data.csv". 

What went wrong?
A wrong file name was inserted: "download" instead of "data.csv". Particularly the missing extension is bad: the user cannot open the file in, say, Excel directly from the browser.

Did this work before? Yes Chrome 34.0.1847.132

Chrome version: 35.0.1916.99  Channel: stable
OS Version: Ubuntu 12.04
Flash Version: not sure
 
Labels: Hotlist-Google
Cc: rponnada@chromium.org
Labels: -Type-Bug -OS-Linux Type-Bug-Regression OS-All M-35
Owner: asanka@chromium.org
Status: Assigned
Able to repro this issue on Windows7 using:35.0.1916.99  & 35.0.1916.114

Cl: http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/branches/1916/src&range=268605:268640&mode=html

Suspect:r268606?
@asanka@chromium.org: Could you pleas confirm, is this intended as per r268606

Comment 3 by asanka@chromium.org, May 19 2014

Labels: Cr-UI-Browser-Downloads

Comment 4 by asanka@chromium.org, May 21 2014

 Issue 375881  has been merged into this issue.
 Issue 376473  has been merged into this issue.

Comment 6 by asanka@chromium.org, May 27 2014

 Issue 376197  has been merged into this issue.

Comment 7 by asanka@chromium.org, May 27 2014

Cc: asanka@chromium.org
 Issue 376856  has been merged into this issue.

Comment 8 by tkent@chromium.org, May 28 2014

 Issue 377860  has been merged into this issue.

Comment 9 by tkent@chromium.org, May 28 2014

 Issue 377700  has been merged into this issue.

Comment 10 by yori@google.com, May 28 2014

I have read that there are security concerns regarding the "download" attribute. In particular, I think that for cross-site references, the "download" attribute is to be ignored from Chrome 35 on. As far as I understand, it should still work for same-site references though. So what is the resolution for data-uri references? Are they supposed to be considered same-site references? 

In other words: is this a bug, or is it intentional and will this issue not be "fixed"?

Comment 11 by Deleted ...@, May 28 2014

Why would downloading a file with a name that the user can edit, less safe than downloading it with a default name of "download" that the user can also edit?
Two questions:

1. I'm encountering this problem when using a web page served from file://.  Is it intentional that the download attribute be ignored in that case?

2. The following code works anyway in 35.0.1916.114.  Is the fact that this works going to be considered a "bug" and "fixed" in future releases? 

///////// downloads as foo.txt when served from file://
{
var pom = document.createElement('a');
  
var blob = new Blob(["Hello, World!"], { type: 'text/plain' });
var url = URL.createObjectURL(blob);
pom.href = url;

pom.setAttribute('download', 'foo.txt');
pom.click();
}
Labels: -Cr-Internals-Network Cr-Blink
To clarify:

- There's an explicit exception for the same-origin rule in the spec for data URIs. A patch to allow data URIs to specify filenames is in review.

- Blob URLs are working as intended.


Labels: -Pri-2 Pri-1
Browser: Chrome 35.0.1916.114 32-bit on Windows Server 2008 R2 / 7 64-bit
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36

Getting the same bug when downloading canvas image via canvas.toDataURL("image/jpeg"),
setting link.download has no effect when the source is a dataurl.

The temporary fix below works for me, but is less than ideal. It converts the dataurl to a blob

////////////Code >>>>>>>>>>>
var myimgURL = annotationCanvas.toDataURL("image/jpeg");

/// Patch to fix chrome dataurl download name bug
var data = atob( myimg.substring( "data:image/jpeg;base64,".length ) );
var asArray = new Uint8Array(data.length);

for( var i = 0, len = data.length; i < len; ++i ) {
	asArray[i] = data.charCodeAt(i);    
}
var blob = new Blob( [ asArray.buffer ], {type: "image/png"} );
myimgURL =  URL.createObjectURL(blob);
/// End Patch

var link = document.createElement('a');
link.href = myimgURL;
link.download = heightImage.originalName + '_photoheight.jpg';
link.click();

<<<<<<<<</Code/////////////////////

Hope the real fix comes soon!

Thanks, Jason (photoheight.com)

Comment 16 by tmst...@gmail.com, May 29 2014

Having the same issue with data:application/csv downloads. Only in Chrome, it downloads as filename: "download" with no extension. Having to tell dozens of clients to stop using Chrome in order to be able to access their reports. Hope this gets fixed soon.
@tmst

This is what I'm using to download a stringified JSON object placed inside of a textarea.  I'd imagine that you can do something similar for a CSV.

---------- code ---------------

var blob = new Blob([$('.cardCreateText').val()], { type: 'text/plain' });
var url = URL.createObjectURL(blob);

$('.downloadCardLinkContainer').html('<a class="downloadCardLink" title="Click to download card" href="'+url+'" download="'+createCardObj.Brief+'.js">Download Card</a>');

---------------/code---------------------

I use a method similar to the one in comment #15 for downloading images.

Both of these methods are working just fine for the time being. I was able to restore functionality within minutes of finding these solutions.

I'd still rather it work the way that it did originally though.

Comment 18 Deleted

I have a chrome extension that finds all the mp3s on a page and downloads them... This bug has caused serious issues with my extension... all my mp3s are not named properly anymore... 

Here is a work around that might help others:

 -----------code-----------------
function downloadFile (sUrl, fileName) {
        window.URL = window.URL || window.webkitURL;

        var xhr = new XMLHttpRequest();
        xhr.open('GET', sUrl, true);
        xhr.responseType = 'blob';

        xhr.onload = function(e) {
                var res = xhr.response;               
                 var blob = new Blob([res], {type:"audio/mp3"});

                url = window.URL.createObjectURL(blob);
                var a = document.createElement("a");
                document.body.appendChild(a);
                a.style = "display: none";
                a.href = url;
                a.download = fileName.replace(/\./g,'')+'.mp3';
                a.click();
                window.URL.revokeObjectURL(url);
        };
}
 -----------/code-----------------
I am having major issue with google chart download as image. Googlechart provide getImageURI() method to get data:uri for image. And when I use download attribute with a filename, it ignores the name. Instead filename always comes as "download.png"

Comment 21 by Deleted ...@, May 30 2014

Same issue here for download as xls file.

example code : 
<a href="data:application/vnd.ms-excel;…9kaXY+Cgk8L2JvZHk+PC9odG1sPg==" download="Report.xls">click to download</a>

3 days ago it downloaded as 'Report.xls', its now 'download.xls'
I think my chrome was auto-updated about 2 days ago.

Comment 22 by saya...@gmail.com, May 30 2014

Yep! Same problem for me.

A few weeks ago, it was downloading as "name.csv" and now it is "download.csv"

Example code:

<a class="hidden-link" href="data:text/csv;charset=utf-8,No,Serial%20no,Model%20Name,Model%20No,Product" download="checks.csv"></a>

2 weeks ago it was downloading as "checks.csv". Now, it downloads always as "download.csv"

Comment 23 by marc...@gmail.com, May 30 2014

Same problem here. We're using it to download all our reports in our webapp. We have a lot of them, so customers need this files with a useful name to can organize it.
Thanks!
Cc: kareng@google.com cbentzel@chromium.org
Folks, we are working on getting a fix out for the regression with regard to data: URIs.

Use of the 'download' attribute will always trigger a download, but from M-35 onwards will only honor the suggested filename if the final resource URL is same-origin as the document. Even when it doesn't, as long as a MIME type is specified correctly, it will receive a filename like 'download.<ext>' where <ext> is the extension known to the host OS as mapping to the specified MIME type. If the resource is served with a Content-Disposition, then the Content-Disposition will take precedence.

For the purpose of handling the 'download' attribute, data URIs should be considered same-origin with the containing document and that's the issue we are trying to fix.

Blob URIs continue to work and will continue to work as long as the blob URI is considered same-origin as the document containing the link.

So the examples people have given that involve data: URIs will work as expected in the future.

+cbentzel and +kareng FYI. https://codereview.chromium.org/300543002/
Same problem for me. Before update the file name was "4711.csv" and now "Download"
Same here, all my csv are now named "Download".
Regards
As an aside, it's always a good idea to specify the correct MIME type for a data: URI even when the intention is to allow it to be downloaded.
In my case I use
data:application/csv

Before the update that worked fine.

Regards
application/csv is incorrect. Use text/csv.
Thanks for the tip.
Anyway, I've tried it and the result is the same as before (the content is ok but the file name is 'download').

Regards
Bummer.  Looks like I have almost identical case as everyone else that is using inline "data:text/csv;base64..."  Just stopped working with the download= directive to get it to recognize it as .csv and it is strange that the text/csv isn't even getting download.csv, it is just download?
Same issue here, but Jason's workaround (comment #15, use blob url instead) is working great.  A real fix would be nice, but in the meantime, thanks Jason!
Same problem for me, using xlsx.js, the data head is data:application/vnd.openxmlformats-officedocument.spreadsheetml.sheet;base64
This change is borking my extension that helps users download music.
Its a bit of a hassle to delegate all the click calls and download it myself as a blob and offer it as a blob url.
I'd like to see this fixed also (unless someone can offer a simple solution to me which I'd appreciate)
You guys may want to take a look at this, written before Chrome supported the download attribute (I'm having to use this now to support Safari as well):

https://code.google.com/p/download-data-uri/

It's a total hack, but I am able to keep ajax calls with dynamically created files downloading with the correct filename and my users don't need to click a blob url.  

One note- the javascript is defaulting to use the writer's servlet (you can see that  options.url is set to that). if this isn't okay for your usage, the source code is there for you to move to your server- it's written in Python and you may need to rewrite it to whatever language you are using on your back-end.
don't forget the xhr.send() for "#19 AGarip...@gmail.com" solution.
 

Comment 37 Deleted

IF anyone is facing problems to download images from cross-domain and choose the filename by the download attribute, this is an workaround that I just developed to use before this issue be fixed.

var xhr = new XMLHttpRequest();
	xhr.open( "GET", source_of_your_image, true );
	xhr.responseType = "arraybuffer";
	xhr.onload = function( e ) {
	    var arrayBufferView = new Uint8Array( this.response );
	    var blob = new Blob( [ arrayBufferView ], { type: "image/jpeg" } );
	    var urlCreator = window.URL || window.webkitURL;
	    imageUrl = urlCreator.createObjectURL( blob );

	    var link = document.createElement("a");
	    link.href = imageUrl;
	    link.download = name_of_your_file;
	    link.style.display = "none";
	    var evt = new MouseEvent("click", {
	        "view": window,
	        "bubbles": true,
	        "cancelable": true
	    });
	    document.body.appendChild(link);
	    link.dispatchEvent(evt);
	    document.body.removeChild(link);
	    console.log("Downloading...");
	};
	xhr.send();

Hope it to be useful for someone facing the same issue.
Project Member

Comment 39 by bugdroid1@chromium.org, Jun 13 2014

The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=176085

------------------------------------------------------------------
r176085 | asanka@chromium.org | 2014-06-13T04:02:41.194243Z

Changed paths:
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/anchor-download-allow-data.html?r1=176085&r2=176084&pathrev=176085
   M http://src.chromium.org/viewvc/blink/trunk/Source/core/html/HTMLAnchorElement.cpp?r1=176085&r2=176084&pathrev=176085
   A http://src.chromium.org/viewvc/blink/trunk/LayoutTests/http/tests/security/anchor-download-allow-data-expected.txt?r1=176085&r2=176084&pathrev=176085

Allow filename suggestions via a[download] for data URIs

Currently filename suggestions specified via a[download] are only honored if
the interface origin is allowed to read content retrieved from the target
resource origin. An embedder may enforce additional restrictions such as only
honoring the suggested name if there are no cross-origin redirects encountered
while fetching the resource.

The suggested filename determination algorithm at
http://www.w3.org/TR/html5/links.html#downloading-resources allows an exception
for data URIs. They should be considered same-origin as the interface. This
isn't currently the case since the origin of a data URI is considerd to be
unique and is not same-origin with anything since they lack a server-based
naming authority.

This CL implements the exception for data URIs so that they are considered
same-origin as their containing document for the purpose of handling the
suggested filename for a[download].

BUG= 373182 

Review URL: https://codereview.chromium.org/300543002
-----------------------------------------------------------------
Thanks asanka@chromium.org - the recently committed fix is encouraging.  Any idea when this might be released into the wild?  Trying to gauge whether to implement a hack, or wait it out...
Status: Fixed
The fix should be on the current Canary channel. Could someone verify whether the fix is working as intended?
Just tested on one example, and it appears to be working as intended...
Tested on 'Version 37.0.2053.3 canary' and it is working fine.
Regards

Comment 44 by saya...@gmail.com, Jun 17 2014

I just tested in Version 37.0.2054.2 canary and it's working too :)
Did you want to try to get it merged to earlier releases like 36?
Yes, please. That would be great!
Labels: -M-35 M-36 Merge-Requested
Status: Started
asvitkine: Yeah.

Adjusting labels for merge consideration.
Labels: -Merge-Requested Merge-Approved
Project Member

Comment 49 by bugdroid1@chromium.org, Jun 19 2014

Labels: -Merge-Approved merge-merged-1985
The following revision refers to this bug:
  http://src.chromium.org/viewvc/blink?view=rev&rev=176548

------------------------------------------------------------------
r176548 | asanka@chromium.org | 2014-06-19T21:17:37.721531Z

Changed paths:
   M http://src.chromium.org/viewvc/blink/branches/chromium/1985/Source/core/html/HTMLAnchorElement.cpp?r1=176548&r2=176547&pathrev=176548
   A http://src.chromium.org/viewvc/blink/branches/chromium/1985/LayoutTests/http/tests/security/anchor-download-allow-data-expected.txt?r1=176548&r2=176547&pathrev=176548
   A http://src.chromium.org/viewvc/blink/branches/chromium/1985/LayoutTests/http/tests/security/anchor-download-allow-data.html?r1=176548&r2=176547&pathrev=176548

Merge 176085 "Allow filename suggestions via a[download] for dat..."

> Allow filename suggestions via a[download] for data URIs
> 
> Currently filename suggestions specified via a[download] are only honored if
> the interface origin is allowed to read content retrieved from the target
> resource origin. An embedder may enforce additional restrictions such as only
> honoring the suggested name if there are no cross-origin redirects encountered
> while fetching the resource.
> 
> The suggested filename determination algorithm at
> http://www.w3.org/TR/html5/links.html#downloading-resources allows an exception
> for data URIs. They should be considered same-origin as the interface. This
> isn't currently the case since the origin of a data URI is considerd to be
> unique and is not same-origin with anything since they lack a server-based
> naming authority.
> 
> This CL implements the exception for data URIs so that they are considered
> same-origin as their containing document for the purpose of handling the
> suggested filename for a[download].
> 
> BUG= 373182 
> 
> Review URL: https://codereview.chromium.org/300543002

TBR=asanka@chromium.org

Review URL: https://codereview.chromium.org/344013004
-----------------------------------------------------------------
Status: Fixed

Comment 51 Deleted

Will this be hotfixed into current live (35)?
#52: No. The fix was made too late in the cycle for Chrome 35. It'll be included in Chrome 36.
 Issue 391245  has been merged into this issue.

Comment 55 Deleted

problema continua, solo se arreglo cuando el archivo a descargar esta en el mismo dominio de la pagina que lo llama.
problem continue. Version 36.0.1985.125 m
For me now is ok with version 36.0.1985.125 m.
I'm using the following code:

function DownloadWithFileName(uri, name) {
    var link = document.createElement('a');
    link.href = uri;
    link.setAttribute('download', name);
    document.body.appendChild(link);
    link.click();
    document.body.removeChild(a);
}
Now it is working for me.
I am using Chrome 36.0.1985.125.
It can be tested with the code at: http://jsfiddle.net/KPEGU/1764/
The file will be correctly named to export.csv.
this link ok in version 34 ,but versions 35 and 36 problem:
 <a href="http://davidwalsh.name/demo/some-realy-crazy-file-name-389247823879472398.txt" download="important.txt">Download file</a>

Comment 61 Deleted

Comment 62 Deleted

this happens when the file is not in the site interface
#60: I'm guessing that the web page and the download are on different origins. We no longer honor the download attribute suggested filename for cross origin requests. Clicking on the link still initiates a download. But the the filename is only derived from factors solely dependent on the server (e.g. Content-Disposition header in the response and the URL).

Comment 65 Deleted

But, if the source does not put these factors or restrictions you mention, the download attribute should work, as I did in 34 and previous versions

Comment 67 by Deleted ...@, Aug 5 2014

#64
windows 7..64bits
chrome Versión 36.0.1985.125 dev-m

create this page html in your web server(i test in Tomcat and Internet information server):

<html>
<head>
</head>
<body >
<a href="http://davidwalsh.name/demo/some-realy-crazy-file-name-389247823879472398.txt" download="important.txt">Download file</a>
</body >
 </html>

when download file this link ok in version 34 and older, file download is "important.txt". But versions 35 and 36,file download is "/some-realy-crazy-file-name-389247823879472398.txt".
If the source does not put factors or restrictions(e.g. Content-Disposition header in the response and the URL), the download attribute should work, as I did in 34 and previous versions
Is there any workaround for naming a file now for a download that is cross site  using any other library or anything?
Yea scroll up or try this... 


-----------code-----------------
function downloadFile (sUrl, fileName) {
        window.URL = window.URL || window.webkitURL;

        var xhr = new XMLHttpRequest();
        xhr.open('GET', sUrl, true);
        xhr.responseType = 'blob';

        xhr.onload = function(e) {
                var res = xhr.response;               
                 var blob = new Blob([res], {type:"audio/mp3"});

                url = window.URL.createObjectURL(blob);
                var a = document.createElement("a");
                document.body.appendChild(a);
                a.style = "display: none";
                a.href = url;
                a.download = fileName.replace(/\./g,'')+'.mp3';
                a.click();
                window.URL.revokeObjectURL(url);
        };

         xhr.send(); 
}
 -----------/code-----------------
Still not working on OS X version 37.  I tried a really simple HTML page test and it is still not working for me:

<html>
<body>
<a href="https://www.google.com/images/srpr/logo11w.png" download="IssueFixed!.png">click me</a>
</body>
</html>
Labels: Restrict-AddIssueComment-EditIssue
#70 and for future reference: See #64.

Sign in to add a comment