Bug 156056 - Support download attribute feature
Summary: Support download attribute feature
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Brent Fulgham
URL:
Keywords:
Depends on: 99025 102785 102914 156057 156067 156069 156099 156100 156177 156583 162531 162535 162631 162703 162765 162788 163693 163742 167341
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-30 22:10 PDT by Brent Fulgham
Modified: 2018-06-19 01:54 PDT (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Fulgham 2016-03-30 22:10:33 PDT
Umbrella issue to capture various things related to a fully-working <a download> feature.
Comment 1 eddieloeffen 2016-09-27 17:46:23 PDT
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.
Comment 2 eddieloeffen 2016-09-27 17:50:27 PDT
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.
Comment 3 Simon Lampen 2016-09-30 00:04:19 PDT
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
Comment 4 Chris Dumez 2016-09-30 07:39:58 PDT
(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 :)