FileSaver.js does not work in WebKit: - https://eligrey.com/demos/FileSaver.js/ It works in Firefox and Chrome, but in WebKit, we get a "Synthetic clicks on anchors that have a download attribute are ignored." warning. It appears we are too strict in restricting synthetic clicks.
Created attachment 290345 [details] Patch
Comment on attachment 290345 [details] Patch Oh, I need to skip the new test on WK1.
Created attachment 290346 [details] Patch
Comment on attachment 290346 [details] Patch Attachment 290346 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/2176489 New failing tests: fast/dom/HTMLAnchorElement/anchor-download-user-triggered-synthetic-click.html
Created attachment 290354 [details] Archive of layout-test-results from ews121 for ios-simulator-elcapitan-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews121 Port: ios-simulator-elcapitan-wk2 Platform: Mac OS X 10.11.6
(In reply to comment #4) > Comment on attachment 290346 [details] > Patch > > Attachment 290346 [details] did not pass ios-sim-ews (ios-simulator-wk2): > Output: http://webkit-queues.webkit.org/results/2176489 > > New failing tests: > fast/dom/HTMLAnchorElement/anchor-download-user-triggered-synthetic-click. > html This is expected as <a download> does not work on iOS. I'll skip the new test on this platform. Feel free to review.
Created attachment 290372 [details] Patch
Comment on attachment 290372 [details] Patch Clearing flags on attachment: 290372 Committed r206659: <http://trac.webkit.org/changeset/206659>
All reviewed patches have been landed. Closing bug.
Wait: so <a download... isn't going to work in iOS even if there's an app that can handle the file type? That's less than ideal for those who are writing JS applications that generate documents. In my case I'm using Javascript to generate epub files that I'd like to open in iBooks; others are creating word processor files, spreadsheets (should open in iWork), PDFs, images (should go to Photos), etc. Please reconsider making iOS a first-class citizen in this respect. :-) I appreciate all the work; the last nightly works great with my epub stuff in the desktop browser.
(In reply to comment #10) > Wait: so <a download... isn't going to work in iOS even if there's an app > that can handle the file type? That's less than ideal for those who are > writing JS applications that generate documents. In my case I'm using > Javascript to generate epub files that I'd like to open in iBooks; others > are creating word processor files, spreadsheets (should open in iWork), > PDFs, images (should go to Photos), etc. > > Please reconsider making iOS a first-class citizen in this respect. :-) > > I appreciate all the work; the last nightly works great with my epub stuff > in the desktop browser. Thanks for the feedback, I simply haven't tested on iOS yet (it may just work). I'll take a look soon. Do you have a particular demo page I could use to test on iOS?
Hi Chris, Thanks for looking into iOS usage. iOS or in fact any device that may have limited bandwidth is a key use case for the <a dowload> feature, because the work around is to post back the data you want to the server and have the server simply bounce the data back down to the client in a more traditional download. This effectively triples the bandwidth required to download data already on the client. So the <a download> feature is a great bandwidth saver for iOS devices. Would the https://eligrey.com/demos/FileSaver.js/ page still be a useful demo? Thanks for the work so far. Cheers Simon
(In reply to comment #12) > Hi Chris, > Thanks for looking into iOS usage. > iOS or in fact any device that may have limited bandwidth is a key use case > for the <a dowload> feature, because the work around is to post back the > data you want to the server and have the server simply bounce the data back > down to the client in a more traditional download. This effectively triples > the bandwidth required to download data already on the client. So the <a > download> feature is a great bandwidth saver for iOS devices. > Would the https://eligrey.com/demos/FileSaver.js/ page still be a useful > demo? > Thanks for the work so far. > Cheers Simon To be clear, what would you expect to happen on iOS for https://eligrey.com/demos/FileSaver.js/ if <a download> was working as expected? Without the download attribute support, it merely navigates to the blob URL and displays the image.
Good question, so I guess it would be that all content-disposition types that have a handler would be opened and displayed in a new tab. If they don't have a handler, some UI indication would help users understanding. In your example, yes an image would be displayed, or a pdf file etc. However currently (before any of your fixes) the example txt file displays a blank tab. If a xlsx file were downloaded some ui feedback like "files of type 'application/xlsx' have no default handler" or something like that.
Hi, Chris. I put up a stripped-down example here: http://pulpgrinder.com/wktest/ The first link is a normal link to an epub file. The second link ajaxes in the epub file as a blob, then uses the download attribute to (attempt) to download the file Both links work fine in the latest nightly for OS X desktop, saving the linked epub file to the downloads folder as expected (yay!). In mobile Safari (iOS 10.0.2) tapping the normal link offers to open the epub in iBooks, just as it has all along). The dynamically generated link doesn't work. Note that this is just the normal iOS Safari. I don't have the Webkit nightly installed on the iOS device (I'd be glad to try it if there's some easy way to install it). Ideally for me the second link would behave exactly the same as the first, by offering to open the link in iBooks. Thanks for looking into this!