Bug 162788 - FileSaver.js does not work in WebKit
Summary: FileSaver.js does not work in WebKit
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL: https://eligrey.com/demos/FileSaver.js/
Keywords: WebExposed
Depends on:
Blocks: 156056
  Show dependency treegraph
 
Reported: 2016-09-30 09:16 PDT by Chris Dumez
Modified: 2016-10-01 10:29 PDT (History)
12 users (show)

See Also:


Attachments
Patch (6.68 KB, patch)
2016-09-30 10:15 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (9.45 KB, patch)
2016-09-30 10:34 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews121 for ios-simulator-elcapitan-wk2 (13.57 MB, application/zip)
2016-09-30 11:27 PDT, Build Bot
no flags Details
Patch (10.47 KB, patch)
2016-09-30 13:09 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2016-09-30 09:16:17 PDT
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.
Comment 1 Chris Dumez 2016-09-30 10:15:14 PDT
Created attachment 290345 [details]
Patch
Comment 2 Chris Dumez 2016-09-30 10:31:36 PDT
Comment on attachment 290345 [details]
Patch

Oh, I need to skip the new test on WK1.
Comment 3 Chris Dumez 2016-09-30 10:34:27 PDT
Created attachment 290346 [details]
Patch
Comment 4 Build Bot 2016-09-30 11:27:37 PDT
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
Comment 5 Build Bot 2016-09-30 11:27:42 PDT
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
Comment 6 Chris Dumez 2016-09-30 11:36:01 PDT
(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.
Comment 7 Chris Dumez 2016-09-30 13:09:49 PDT
Created attachment 290372 [details]
Patch
Comment 8 Chris Dumez 2016-09-30 13:10:52 PDT
Comment on attachment 290372 [details]
Patch

Clearing flags on attachment: 290372

Committed r206659: <http://trac.webkit.org/changeset/206659>
Comment 9 Chris Dumez 2016-09-30 13:10:57 PDT
All reviewed patches have been landed.  Closing bug.
Comment 10 Tony Hursh 2016-09-30 13:22:32 PDT
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.
Comment 11 Chris Dumez 2016-09-30 13:42:05 PDT
(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?
Comment 12 Simon Lampen 2016-09-30 13:55:56 PDT
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
Comment 13 Chris Dumez 2016-09-30 14:03:10 PDT
(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.
Comment 14 Simon Lampen 2016-09-30 16:08:56 PDT
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.
Comment 15 Tony Hursh 2016-09-30 16:09:55 PDT
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!