Bug 162788 – FileSaver.js does not work in WebKit

• Component: DOM
• Status: RESOLVED FIXED

[Chris Dumez]

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.

[Chris Dumez]

Created attachment 290345 [details]
Patch

[Chris Dumez]

Comment on attachment 290345 [details]
Patch

Oh, I need to skip the new test on WK1.

[Chris Dumez]

Created attachment 290346 [details]
Patch

[Build Bot]

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

[Build Bot]

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

[Chris Dumez]

(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.

[Chris Dumez]

Created attachment 290372 [details]
Patch

[Chris Dumez]

Comment on attachment 290372 [details]
Patch

Clearing flags on attachment: 290372

Committed r206659: <http://trac.webkit.org/changeset/206659>

[Chris Dumez]

All reviewed patches have been landed.  Closing bug.

[Tony Hursh]

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.

[Chris Dumez]

(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?

[Simon Lampen]

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

[Chris Dumez]

(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.

[Simon Lampen]

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.

[Tony Hursh]

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!