Download ignores download attribute












3














Following a number of tutorials and examples on line I have constructed a file download system built on jQuery on the client and MS WebAPI on the server.



Providing direct links to the files isn't possible as the API requires authentication, thus the file URL is an API endpoint not the file location.



On the server I have this:



[HttpGet]
[Route("download/{filename}")]
public HttpResponseMessage DownloadFile(string filename)
{
try
{
// https://gist.github.com/joeriks/3714093
string path = string.Format("{0}/Exports/{1}", root, filename);

HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
var stream = new FileStream(path, FileMode.Open);
result.Content = new StreamContent(stream);
result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
result.Content.Headers.ContentDisposition.FileName = "download.txt";
return result;

}
catch (Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}


Which returns a response as expected:



HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 4809
Content-Type: application/octet-stream
Expires: -1
Server: Microsoft-IIS/10.0
Content-Disposition: attachment; filename=download.txt
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: content-Type, accept, origin, X-Requested-With, X-Authentication, X-Nonce, name
Date: Thu, 25 Oct 2018 13:07:25 GMT


With the text content in the response.
So far all is as I would hope.



On the client I have the following for handling responses from my API:



// https://stackoverflow.com/a/23797348
let disposition = jqXHR.getResponseHeader('Content-Disposition');

if (disposition && disposition.indexOf('attachment') !== -1) {
let filename = "scada-download.txt";
let matches = /filename[^;=n]*=((['"]).*?2|[^;n]*)/.exec(disposition);
if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, '');

let type = jqXHR.getResponseHeader('Content-Type');
let blob = new Blob([data], { type: "text/csv" });

var downloadUrl = URL.createObjectURL(blob);
let $a = $("<a id='temp_download_link' style='display: none;' />").attr("href", downloadUrl).attr("download", filename);
$("body").append($a);
$a.trigger("click");
}


This does as advertised, and adds an anchor to the page, and clicks it triggering the download.



The download works, and saves a file with the correct contents.



The only bit that doesn't work is that in both browsers I've tested it in (Chrome 69, FF: 62) the default file name provided is simply a GUID.



The api and the client code are both running from my local dev machine at present, http://127.0.0.1:9000/[client | api] so cross origin shouldn't be playing any part.



The call to the api is made via ajax. Ultimately the jQuery $.ajax() method



For clarity sake, the anchor inserted into the DOM is:



<a id="temp_download_link" style="display: none;" href="blob:http://127.0.0.1:9000/c2c5ffb5-3f22-4a57-8775-4e0bbfbfef9e" download="download.txt"></a>


The default filename provided by Chrome is the GUID in the URL, FF generates a seemingly unconnected 6 character random string.



Specifically,
Why are the browsers ignoring both the download="download.txt" attribute of the anchor and the Content-Disposition: attachment; filename=download.txt?



UPDATE:



I forked this fiddle:



http://jsfiddle.net/Qjvb3/



And added some other values for the href attribute, it seems that the whole setting the filename is flaky at best:



http://jsfiddle.net/yubjqwvs/



UPDATE 2



I've copied the link from a working example into my fiddle, it works from the original site, but not from fiddle.



http://jsfiddle.net/yubjqwvs/2/



I have a feeling that the answer will boil down to "Why does it work on David Walsh Blog, but not on fiddle?"










share|improve this question
























  • maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
    – Alex
    Nov 12 '18 at 14:20












  • @Alex, I hadn't tried it - but I have now. Makes no difference
    – Morvael
    Nov 14 '18 at 8:24










  • I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
    – noobed
    Nov 14 '18 at 9:55










  • In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
    – noobed
    Nov 14 '18 at 12:12










  • @Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
    – noobed
    Nov 14 '18 at 12:13
















3














Following a number of tutorials and examples on line I have constructed a file download system built on jQuery on the client and MS WebAPI on the server.



Providing direct links to the files isn't possible as the API requires authentication, thus the file URL is an API endpoint not the file location.



On the server I have this:



[HttpGet]
[Route("download/{filename}")]
public HttpResponseMessage DownloadFile(string filename)
{
try
{
// https://gist.github.com/joeriks/3714093
string path = string.Format("{0}/Exports/{1}", root, filename);

HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
var stream = new FileStream(path, FileMode.Open);
result.Content = new StreamContent(stream);
result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
result.Content.Headers.ContentDisposition.FileName = "download.txt";
return result;

}
catch (Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}


Which returns a response as expected:



HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 4809
Content-Type: application/octet-stream
Expires: -1
Server: Microsoft-IIS/10.0
Content-Disposition: attachment; filename=download.txt
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: content-Type, accept, origin, X-Requested-With, X-Authentication, X-Nonce, name
Date: Thu, 25 Oct 2018 13:07:25 GMT


With the text content in the response.
So far all is as I would hope.



On the client I have the following for handling responses from my API:



// https://stackoverflow.com/a/23797348
let disposition = jqXHR.getResponseHeader('Content-Disposition');

if (disposition && disposition.indexOf('attachment') !== -1) {
let filename = "scada-download.txt";
let matches = /filename[^;=n]*=((['"]).*?2|[^;n]*)/.exec(disposition);
if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, '');

let type = jqXHR.getResponseHeader('Content-Type');
let blob = new Blob([data], { type: "text/csv" });

var downloadUrl = URL.createObjectURL(blob);
let $a = $("<a id='temp_download_link' style='display: none;' />").attr("href", downloadUrl).attr("download", filename);
$("body").append($a);
$a.trigger("click");
}


This does as advertised, and adds an anchor to the page, and clicks it triggering the download.



The download works, and saves a file with the correct contents.



The only bit that doesn't work is that in both browsers I've tested it in (Chrome 69, FF: 62) the default file name provided is simply a GUID.



The api and the client code are both running from my local dev machine at present, http://127.0.0.1:9000/[client | api] so cross origin shouldn't be playing any part.



The call to the api is made via ajax. Ultimately the jQuery $.ajax() method



For clarity sake, the anchor inserted into the DOM is:



<a id="temp_download_link" style="display: none;" href="blob:http://127.0.0.1:9000/c2c5ffb5-3f22-4a57-8775-4e0bbfbfef9e" download="download.txt"></a>


The default filename provided by Chrome is the GUID in the URL, FF generates a seemingly unconnected 6 character random string.



Specifically,
Why are the browsers ignoring both the download="download.txt" attribute of the anchor and the Content-Disposition: attachment; filename=download.txt?



UPDATE:



I forked this fiddle:



http://jsfiddle.net/Qjvb3/



And added some other values for the href attribute, it seems that the whole setting the filename is flaky at best:



http://jsfiddle.net/yubjqwvs/



UPDATE 2



I've copied the link from a working example into my fiddle, it works from the original site, but not from fiddle.



http://jsfiddle.net/yubjqwvs/2/



I have a feeling that the answer will boil down to "Why does it work on David Walsh Blog, but not on fiddle?"










share|improve this question
























  • maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
    – Alex
    Nov 12 '18 at 14:20












  • @Alex, I hadn't tried it - but I have now. Makes no difference
    – Morvael
    Nov 14 '18 at 8:24










  • I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
    – noobed
    Nov 14 '18 at 9:55










  • In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
    – noobed
    Nov 14 '18 at 12:12










  • @Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
    – noobed
    Nov 14 '18 at 12:13














3












3








3







Following a number of tutorials and examples on line I have constructed a file download system built on jQuery on the client and MS WebAPI on the server.



Providing direct links to the files isn't possible as the API requires authentication, thus the file URL is an API endpoint not the file location.



On the server I have this:



[HttpGet]
[Route("download/{filename}")]
public HttpResponseMessage DownloadFile(string filename)
{
try
{
// https://gist.github.com/joeriks/3714093
string path = string.Format("{0}/Exports/{1}", root, filename);

HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
var stream = new FileStream(path, FileMode.Open);
result.Content = new StreamContent(stream);
result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
result.Content.Headers.ContentDisposition.FileName = "download.txt";
return result;

}
catch (Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}


Which returns a response as expected:



HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 4809
Content-Type: application/octet-stream
Expires: -1
Server: Microsoft-IIS/10.0
Content-Disposition: attachment; filename=download.txt
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: content-Type, accept, origin, X-Requested-With, X-Authentication, X-Nonce, name
Date: Thu, 25 Oct 2018 13:07:25 GMT


With the text content in the response.
So far all is as I would hope.



On the client I have the following for handling responses from my API:



// https://stackoverflow.com/a/23797348
let disposition = jqXHR.getResponseHeader('Content-Disposition');

if (disposition && disposition.indexOf('attachment') !== -1) {
let filename = "scada-download.txt";
let matches = /filename[^;=n]*=((['"]).*?2|[^;n]*)/.exec(disposition);
if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, '');

let type = jqXHR.getResponseHeader('Content-Type');
let blob = new Blob([data], { type: "text/csv" });

var downloadUrl = URL.createObjectURL(blob);
let $a = $("<a id='temp_download_link' style='display: none;' />").attr("href", downloadUrl).attr("download", filename);
$("body").append($a);
$a.trigger("click");
}


This does as advertised, and adds an anchor to the page, and clicks it triggering the download.



The download works, and saves a file with the correct contents.



The only bit that doesn't work is that in both browsers I've tested it in (Chrome 69, FF: 62) the default file name provided is simply a GUID.



The api and the client code are both running from my local dev machine at present, http://127.0.0.1:9000/[client | api] so cross origin shouldn't be playing any part.



The call to the api is made via ajax. Ultimately the jQuery $.ajax() method



For clarity sake, the anchor inserted into the DOM is:



<a id="temp_download_link" style="display: none;" href="blob:http://127.0.0.1:9000/c2c5ffb5-3f22-4a57-8775-4e0bbfbfef9e" download="download.txt"></a>


The default filename provided by Chrome is the GUID in the URL, FF generates a seemingly unconnected 6 character random string.



Specifically,
Why are the browsers ignoring both the download="download.txt" attribute of the anchor and the Content-Disposition: attachment; filename=download.txt?



UPDATE:



I forked this fiddle:



http://jsfiddle.net/Qjvb3/



And added some other values for the href attribute, it seems that the whole setting the filename is flaky at best:



http://jsfiddle.net/yubjqwvs/



UPDATE 2



I've copied the link from a working example into my fiddle, it works from the original site, but not from fiddle.



http://jsfiddle.net/yubjqwvs/2/



I have a feeling that the answer will boil down to "Why does it work on David Walsh Blog, but not on fiddle?"










share|improve this question















Following a number of tutorials and examples on line I have constructed a file download system built on jQuery on the client and MS WebAPI on the server.



Providing direct links to the files isn't possible as the API requires authentication, thus the file URL is an API endpoint not the file location.



On the server I have this:



[HttpGet]
[Route("download/{filename}")]
public HttpResponseMessage DownloadFile(string filename)
{
try
{
// https://gist.github.com/joeriks/3714093
string path = string.Format("{0}/Exports/{1}", root, filename);

HttpResponseMessage result = new HttpResponseMessage(HttpStatusCode.OK);
var stream = new FileStream(path, FileMode.Open);
result.Content = new StreamContent(stream);
result.Content.Headers.ContentType = new MediaTypeHeaderValue("application/octet-stream");
result.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("attachment");
result.Content.Headers.ContentDisposition.FileName = "download.txt";
return result;

}
catch (Exception ex)
{
throw new HttpResponseException(HttpStatusCode.InternalServerError);
}
}


Which returns a response as expected:



HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 4809
Content-Type: application/octet-stream
Expires: -1
Server: Microsoft-IIS/10.0
Content-Disposition: attachment; filename=download.txt
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST, PUT, DELETE, GET, OPTIONS
Access-Control-Allow-Headers: content-Type, accept, origin, X-Requested-With, X-Authentication, X-Nonce, name
Date: Thu, 25 Oct 2018 13:07:25 GMT


With the text content in the response.
So far all is as I would hope.



On the client I have the following for handling responses from my API:



// https://stackoverflow.com/a/23797348
let disposition = jqXHR.getResponseHeader('Content-Disposition');

if (disposition && disposition.indexOf('attachment') !== -1) {
let filename = "scada-download.txt";
let matches = /filename[^;=n]*=((['"]).*?2|[^;n]*)/.exec(disposition);
if (matches != null && matches[1]) filename = matches[1].replace(/['"]/g, '');

let type = jqXHR.getResponseHeader('Content-Type');
let blob = new Blob([data], { type: "text/csv" });

var downloadUrl = URL.createObjectURL(blob);
let $a = $("<a id='temp_download_link' style='display: none;' />").attr("href", downloadUrl).attr("download", filename);
$("body").append($a);
$a.trigger("click");
}


This does as advertised, and adds an anchor to the page, and clicks it triggering the download.



The download works, and saves a file with the correct contents.



The only bit that doesn't work is that in both browsers I've tested it in (Chrome 69, FF: 62) the default file name provided is simply a GUID.



The api and the client code are both running from my local dev machine at present, http://127.0.0.1:9000/[client | api] so cross origin shouldn't be playing any part.



The call to the api is made via ajax. Ultimately the jQuery $.ajax() method



For clarity sake, the anchor inserted into the DOM is:



<a id="temp_download_link" style="display: none;" href="blob:http://127.0.0.1:9000/c2c5ffb5-3f22-4a57-8775-4e0bbfbfef9e" download="download.txt"></a>


The default filename provided by Chrome is the GUID in the URL, FF generates a seemingly unconnected 6 character random string.



Specifically,
Why are the browsers ignoring both the download="download.txt" attribute of the anchor and the Content-Disposition: attachment; filename=download.txt?



UPDATE:



I forked this fiddle:



http://jsfiddle.net/Qjvb3/



And added some other values for the href attribute, it seems that the whole setting the filename is flaky at best:



http://jsfiddle.net/yubjqwvs/



UPDATE 2



I've copied the link from a working example into my fiddle, it works from the original site, but not from fiddle.



http://jsfiddle.net/yubjqwvs/2/



I have a feeling that the answer will boil down to "Why does it work on David Walsh Blog, but not on fiddle?"







jquery ajax asp.net-web-api download






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 15:27

























asked Oct 25 '18 at 13:29









Morvael

1,85122040




1,85122040












  • maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
    – Alex
    Nov 12 '18 at 14:20












  • @Alex, I hadn't tried it - but I have now. Makes no difference
    – Morvael
    Nov 14 '18 at 8:24










  • I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
    – noobed
    Nov 14 '18 at 9:55










  • In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
    – noobed
    Nov 14 '18 at 12:12










  • @Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
    – noobed
    Nov 14 '18 at 12:13


















  • maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
    – Alex
    Nov 12 '18 at 14:20












  • @Alex, I hadn't tried it - but I have now. Makes no difference
    – Morvael
    Nov 14 '18 at 8:24










  • I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
    – noobed
    Nov 14 '18 at 9:55










  • In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
    – noobed
    Nov 14 '18 at 12:12










  • @Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
    – noobed
    Nov 14 '18 at 12:13
















maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
– Alex
Nov 12 '18 at 14:20






maybe a stupid question, but have you tried filename="download.txt"? also, cleared the cache (really, completely cleared the whole cache)?
– Alex
Nov 12 '18 at 14:20














@Alex, I hadn't tried it - but I have now. Makes no difference
– Morvael
Nov 14 '18 at 8:24




@Alex, I hadn't tried it - but I have now. Makes no difference
– Morvael
Nov 14 '18 at 8:24












I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
– noobed
Nov 14 '18 at 9:55




I think this fiddle will help us debug more. There has to be a reason, no matter how oddly it looks
– noobed
Nov 14 '18 at 9:55












In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
– noobed
Nov 14 '18 at 12:12




In the example you gave there are a couple of things to note. Firstly the button "It doesn't save" actually works as expected, because it tries to open the link instead of downloading it. (it's described here in the specification: html.spec.whatwg.org/multipage/links.html#as-a-download). Second the .woff file is not downloaded because of the download attribute. Actually what happens is that the browser is trying to redirect your page to the link, but doesn't understand how to render .woff thus downloading it. You can this by changing .woff with css/font-awesome.css instead. :)
– noobed
Nov 14 '18 at 12:12












@Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
– noobed
Nov 14 '18 at 12:13




@Morvael I've played and tweaked a bit with your demo - jsfiddle.net/kos3rjfq/19. I could edit my initial answer as it is truly not relevant for the case. :)
– noobed
Nov 14 '18 at 12:13












2 Answers
2






active

oldest

votes


















0














I personally used downloadjs to avoid similar problems in my case:




  • An AJAX request is made to download the file; that's simply a PHP script with appropriate header (Content-Disposition: attachment; filename="...")

  • The user click on the link, which use a hashchange event to trigger the download upon which I pass the AJAX response to downloadjs. I suppose the same could be done using a Blob URL.


The code of downloadjs is pretty similar to jsfiddle loosely based on your example. It works fine with Firefox 63, Opera 56 (I guess it should work on Chrome) and it fails on IE 11, but well, that's IE.




  • downloadjs creates an hidden link with a timeout set to 66ms (I suppose it is to wait for the DOM to be ready or something like that).

  • The timeout invoke click() on the link which probably call the native handler.


With your code, and using click() as well as document.getElementById() rather than jQuery, given us this jsfiddle. Contrary to downloadjs, I don't use a window.setTimeout and it works fine, at least in Fx 63. This might simply be a way to bypass a browser bug.



In your case, my guess is that jQuery is not firing the default handler when you invoke trigger('click') which I fails to understand since trigger documentation seems to tell us it does:




As of jQuery 1.3, .trigger()ed events bubble up the DOM tree; an event
handler can stop the bubbling by returning false from the handler or
calling the .stopPropagation() method on the event object passed into
the event. Although .trigger() simulates an event activation, complete
with a synthesized event object, it does not perfectly replicate a
naturally-occurring event.



To trigger handlers bound via jQuery without also triggering the
native event, use .triggerHandler() instead.
(quoted from jquery documentation)




Perhaps that the default click on links is not considered a handler (?) for jquery and does not get fired.






share|improve this answer





























    0














    The reason I see is that you are using jQuery .attr() function instead of .prop() function.
    There is a difference between HTML5 properties and attributes. The first one gives markup to elements in cases for event binding and etc, while the other gives access to/sets the value of the DOM element itself.



    I'll link an explanation that could be useful here.






    share|improve this answer





















    • This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
      – Morvael
      Nov 14 '18 at 8:28











    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52990499%2fdownload-href-blobhttp-url-guid-download-filename-ignores-download-at%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    2 Answers
    2






    active

    oldest

    votes








    2 Answers
    2






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I personally used downloadjs to avoid similar problems in my case:




    • An AJAX request is made to download the file; that's simply a PHP script with appropriate header (Content-Disposition: attachment; filename="...")

    • The user click on the link, which use a hashchange event to trigger the download upon which I pass the AJAX response to downloadjs. I suppose the same could be done using a Blob URL.


    The code of downloadjs is pretty similar to jsfiddle loosely based on your example. It works fine with Firefox 63, Opera 56 (I guess it should work on Chrome) and it fails on IE 11, but well, that's IE.




    • downloadjs creates an hidden link with a timeout set to 66ms (I suppose it is to wait for the DOM to be ready or something like that).

    • The timeout invoke click() on the link which probably call the native handler.


    With your code, and using click() as well as document.getElementById() rather than jQuery, given us this jsfiddle. Contrary to downloadjs, I don't use a window.setTimeout and it works fine, at least in Fx 63. This might simply be a way to bypass a browser bug.



    In your case, my guess is that jQuery is not firing the default handler when you invoke trigger('click') which I fails to understand since trigger documentation seems to tell us it does:




    As of jQuery 1.3, .trigger()ed events bubble up the DOM tree; an event
    handler can stop the bubbling by returning false from the handler or
    calling the .stopPropagation() method on the event object passed into
    the event. Although .trigger() simulates an event activation, complete
    with a synthesized event object, it does not perfectly replicate a
    naturally-occurring event.



    To trigger handlers bound via jQuery without also triggering the
    native event, use .triggerHandler() instead.
    (quoted from jquery documentation)




    Perhaps that the default click on links is not considered a handler (?) for jquery and does not get fired.






    share|improve this answer


























      0














      I personally used downloadjs to avoid similar problems in my case:




      • An AJAX request is made to download the file; that's simply a PHP script with appropriate header (Content-Disposition: attachment; filename="...")

      • The user click on the link, which use a hashchange event to trigger the download upon which I pass the AJAX response to downloadjs. I suppose the same could be done using a Blob URL.


      The code of downloadjs is pretty similar to jsfiddle loosely based on your example. It works fine with Firefox 63, Opera 56 (I guess it should work on Chrome) and it fails on IE 11, but well, that's IE.




      • downloadjs creates an hidden link with a timeout set to 66ms (I suppose it is to wait for the DOM to be ready or something like that).

      • The timeout invoke click() on the link which probably call the native handler.


      With your code, and using click() as well as document.getElementById() rather than jQuery, given us this jsfiddle. Contrary to downloadjs, I don't use a window.setTimeout and it works fine, at least in Fx 63. This might simply be a way to bypass a browser bug.



      In your case, my guess is that jQuery is not firing the default handler when you invoke trigger('click') which I fails to understand since trigger documentation seems to tell us it does:




      As of jQuery 1.3, .trigger()ed events bubble up the DOM tree; an event
      handler can stop the bubbling by returning false from the handler or
      calling the .stopPropagation() method on the event object passed into
      the event. Although .trigger() simulates an event activation, complete
      with a synthesized event object, it does not perfectly replicate a
      naturally-occurring event.



      To trigger handlers bound via jQuery without also triggering the
      native event, use .triggerHandler() instead.
      (quoted from jquery documentation)




      Perhaps that the default click on links is not considered a handler (?) for jquery and does not get fired.






      share|improve this answer
























        0












        0








        0






        I personally used downloadjs to avoid similar problems in my case:




        • An AJAX request is made to download the file; that's simply a PHP script with appropriate header (Content-Disposition: attachment; filename="...")

        • The user click on the link, which use a hashchange event to trigger the download upon which I pass the AJAX response to downloadjs. I suppose the same could be done using a Blob URL.


        The code of downloadjs is pretty similar to jsfiddle loosely based on your example. It works fine with Firefox 63, Opera 56 (I guess it should work on Chrome) and it fails on IE 11, but well, that's IE.




        • downloadjs creates an hidden link with a timeout set to 66ms (I suppose it is to wait for the DOM to be ready or something like that).

        • The timeout invoke click() on the link which probably call the native handler.


        With your code, and using click() as well as document.getElementById() rather than jQuery, given us this jsfiddle. Contrary to downloadjs, I don't use a window.setTimeout and it works fine, at least in Fx 63. This might simply be a way to bypass a browser bug.



        In your case, my guess is that jQuery is not firing the default handler when you invoke trigger('click') which I fails to understand since trigger documentation seems to tell us it does:




        As of jQuery 1.3, .trigger()ed events bubble up the DOM tree; an event
        handler can stop the bubbling by returning false from the handler or
        calling the .stopPropagation() method on the event object passed into
        the event. Although .trigger() simulates an event activation, complete
        with a synthesized event object, it does not perfectly replicate a
        naturally-occurring event.



        To trigger handlers bound via jQuery without also triggering the
        native event, use .triggerHandler() instead.
        (quoted from jquery documentation)




        Perhaps that the default click on links is not considered a handler (?) for jquery and does not get fired.






        share|improve this answer












        I personally used downloadjs to avoid similar problems in my case:




        • An AJAX request is made to download the file; that's simply a PHP script with appropriate header (Content-Disposition: attachment; filename="...")

        • The user click on the link, which use a hashchange event to trigger the download upon which I pass the AJAX response to downloadjs. I suppose the same could be done using a Blob URL.


        The code of downloadjs is pretty similar to jsfiddle loosely based on your example. It works fine with Firefox 63, Opera 56 (I guess it should work on Chrome) and it fails on IE 11, but well, that's IE.




        • downloadjs creates an hidden link with a timeout set to 66ms (I suppose it is to wait for the DOM to be ready or something like that).

        • The timeout invoke click() on the link which probably call the native handler.


        With your code, and using click() as well as document.getElementById() rather than jQuery, given us this jsfiddle. Contrary to downloadjs, I don't use a window.setTimeout and it works fine, at least in Fx 63. This might simply be a way to bypass a browser bug.



        In your case, my guess is that jQuery is not firing the default handler when you invoke trigger('click') which I fails to understand since trigger documentation seems to tell us it does:




        As of jQuery 1.3, .trigger()ed events bubble up the DOM tree; an event
        handler can stop the bubbling by returning false from the handler or
        calling the .stopPropagation() method on the event object passed into
        the event. Although .trigger() simulates an event activation, complete
        with a synthesized event object, it does not perfectly replicate a
        naturally-occurring event.



        To trigger handlers bound via jQuery without also triggering the
        native event, use .triggerHandler() instead.
        (quoted from jquery documentation)




        Perhaps that the default click on links is not considered a handler (?) for jquery and does not get fired.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 12 '18 at 23:43









        NoDataFound

        5,7401741




        5,7401741

























            0














            The reason I see is that you are using jQuery .attr() function instead of .prop() function.
            There is a difference between HTML5 properties and attributes. The first one gives markup to elements in cases for event binding and etc, while the other gives access to/sets the value of the DOM element itself.



            I'll link an explanation that could be useful here.






            share|improve this answer





















            • This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
              – Morvael
              Nov 14 '18 at 8:28
















            0














            The reason I see is that you are using jQuery .attr() function instead of .prop() function.
            There is a difference between HTML5 properties and attributes. The first one gives markup to elements in cases for event binding and etc, while the other gives access to/sets the value of the DOM element itself.



            I'll link an explanation that could be useful here.






            share|improve this answer





















            • This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
              – Morvael
              Nov 14 '18 at 8:28














            0












            0








            0






            The reason I see is that you are using jQuery .attr() function instead of .prop() function.
            There is a difference between HTML5 properties and attributes. The first one gives markup to elements in cases for event binding and etc, while the other gives access to/sets the value of the DOM element itself.



            I'll link an explanation that could be useful here.






            share|improve this answer












            The reason I see is that you are using jQuery .attr() function instead of .prop() function.
            There is a difference between HTML5 properties and attributes. The first one gives markup to elements in cases for event binding and etc, while the other gives access to/sets the value of the DOM element itself.



            I'll link an explanation that could be useful here.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 13 '18 at 10:25









            noobed

            1,012818




            1,012818












            • This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
              – Morvael
              Nov 14 '18 at 8:28


















            • This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
              – Morvael
              Nov 14 '18 at 8:28
















            This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
            – Morvael
            Nov 14 '18 at 8:28




            This didn't sound likely to me, asI'm not messing with the node once I have inserted it into the DOM, so it shouldn't make any difference (the initial value is never changed so even if it wasn't a pure reflected property I should get the same result). I tried it anyway, but got the same result.
            – Morvael
            Nov 14 '18 at 8:28


















            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.





            Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


            Please pay close attention to the following guidance:


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f52990499%2fdownload-href-blobhttp-url-guid-download-filename-ignores-download-at%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            這個網誌中的熱門文章

            Academy of Television Arts & Sciences

            L'Équipe

            1995 France bombings