Support download attribute feature

• Component: WebKit Misc.
• Status: RESOLVED FIXED

[Brent Fulgham]

Umbrella issue to capture various things related to a fully-working <a download> feature.

Hi guys, super excited to see this bug being fixed!

I've downloaded the nightly from last night and it works great with download links that are inserted in to the DOM ahead of time and then clicked.

What we have been looking for, and this works in Chrome, is to help with dynamic content generated at the time someone clicks (e.g. a new PDF, a CSV of data from the page etc).

Would you mind having a look at this demo page for FileSaver.js and consider if there are any outstanding (unreported) bugs preventing this from working now?:

https://eligrey.com/demos/FileSaver.js/

From what I can see, Safari fails to execute the simulated click event sent to the generated <a download> element. This is different behaviour to what I see in Chrome and Firefox.

If I take that generated element, insert it in to the DOM, and click it manually, everything works as expected.

Just as a follow up to my previous comment, I can programmatically despatch a click event to a normal "<a>" element and Safari responds, but despatching a click event to "<a download>" does not.

[Simon Lampen]

Hi Brent,
I downloaded the nightly from 30 Sept and have tested it on the use case here: https://eligrey.com/demos/FileSaver.js/ and it console logs the reason "Synthetic clicks on anchors that have a download attribute are ignored."

So I understand that the code is dispatching a call to element.click() which is being interpreted as "synthetic", I understand that but the call has a user click generated click event further up the call stack. 
Also to support this treatment Firefox, Chrome and even Edge, dare I say it, all allow this and treat the element.click() as a "real" user generated event, further more, if the element does not have a download attribute, then the click call is also honoured.

Are you able to review your blocking of this call and allow it if the call stack has a user click in it.
We are desperately looking for some uniformity in cross browser behavior here.

Cheers
Simon

[Chris Dumez]

(In reply to comment #2)
> Just as a follow up to my previous comment, I can programmatically despatch
> a click event to a normal "<a>" element and Safari responds, but despatching
> a click event to "<a download>" does not.

Yes, this is intentional and as per the HTML specification. I also know that Chrome currently does not do this but they agreed to fix it.

That said, we can probably be a little more permissive than we currrently are. I will take a look and test the demo you provided.

Thanks for testing :)

[Sergey]

Hi. I try to save blob files using fileSaverJs, downloadjs or anchor download attribute. Its works well in Linux, but I also have to use iPad Safari, Chrome and FireFox browsers. The task is to implement client-side downloading zip, pdf and excel format files. When iPadOs version was 14.xx just Safari could correctly save files.  Other browsers just open it. After updating this version to the 15.5 I 
noticed that Chrome is also begun working well with all of the above approaches. But to fix Safari all formats downloading after updating, I had to delete options (object with type) while creating new Blob(), because it stopped downloading pdf files. I read that passing correct type solves problem, but to fix my problems I should delete it. The main problem is Firefox. It just opens file If I pass file type, otherwise it doesn't do anything. Is there ideas how making it download files? 

Firefox version is 101
FileSaver version is 1.3.2
I use AngularJS

source example

 httpGet(url, param).then(function (response) {
     saveAs(new Blob([response.data]), "someName");
 })