|Summary:||Support download attribute feature|
|Product:||WebKit||Reporter:||Brent Fulgham <bfulgham>|
|Component:||WebKit Misc.||Assignee:||Brent Fulgham <bfulgham>|
|Severity:||Normal||CC:||adam, allan.jardine, bugmail, cdumez, eddieloeffen, eoconnor, nmrugg, simonlampen, tony.hursh, webkit|
|Version:||WebKit Nightly Build|
|Bug Depends on:||99025, 102785, 102914, 156057, 156067, 156069, 156099, 156100, 156177, 156583, 162531, 162535, 162631, 162703, 162765, 162788, 163693, 163742, 167341|
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 :)