Bug 167341 - [iOS] Add support for the download attribute
Summary: [iOS] Add support for the download attribute
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on: 167337
Blocks: 156056
  Show dependency treegraph
 
Reported: 2017-01-23 16:14 PST by Chris Dumez
Modified: 2019-08-21 15:58 PDT (History)
37 users (show)

See Also:


Attachments
Testcase (2.23 KB, text/html)
2018-06-18 23:01 PDT, Frédéric Wang (:fredw)
no flags Details
WIP Patch (26.31 KB, patch)
2019-01-25 12:58 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (35.42 KB, patch)
2019-01-25 13:28 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (36.12 KB, patch)
2019-01-25 13:38 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (429.46 KB, patch)
2019-01-25 15:04 PST, Chris Dumez
no flags Details | Formatted Diff | Diff
Screen Video Of Bug (2.09 MB, video/quicktime)
2019-08-20 08:28 PDT, Michaela Merz
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2017-01-23 16:14:59 PST
Add support for the download attribute on iOS (for things like ebooks).
Comment 1 Chris Dumez 2017-01-23 16:18:35 PST
Test case at:
https://bugs.webkit.org/show_bug.cgi?id=162788#c15
Comment 2 Chris Dumez 2017-01-24 12:55:57 PST
When you click such link, you get a dialog saying it failed to install the profile (instead of opening the file in iBooks).
Comment 3 Radar WebKit Bug Importer 2017-01-31 15:01:57 PST
<rdar://problem/30296281>
Comment 4 Adam Lippai 2017-06-30 06:54:17 PDT
iOS 11 beta has major file handling changes. Do the new APIs help fixing this bug? Is there any chance this can be shipped with Mobile Safari 11?
Comment 5 Ben Frain 2017-12-05 12:12:34 PST
Can’t believe we are still waiting for this and it is nearly 2018. 

It’s difficult to make a simple cross-browser mobile app that allows a user to backup their config on iOS. 

Is there any timeline for this or is it another feature reserved for apps that live in the app store?

I should qualify; I’m talking about a prompt to save off to icloud/dropbox etc. Not just serve the user a dirty raw text file with no option to save.
Comment 6 Ben Frain 2018-01-23 11:42:07 PST
Just to be clear, even in ios11, it is not possible to save a file (json/text/md etc) to ‘Files’ app. 

For example visit the text file on iOS: https://wordpress.org/plugins/readme.txt

You cannot save that txt file to ‘Files’ from Safari share menu on iOS.
Comment 7 Marcela Errazquin 2018-03-16 04:20:58 PDT
Is there an update as to when this bug will be addressed? I find it hard to believe that this is not available functionality in iOS11.
Comment 8 Jonathan Lahue 2018-03-18 09:46:24 PDT
This is also something I need. I'm making an educational web app and it's a must to be able to save json files.
https://www.npmjs.com/package/file-saver works perfectly on most browsers, but not iOS 😢
Comment 9 David Morehead 2018-06-17 11:16:11 PDT
built a web app which allows users to save layered .psd files from web-gl ..on IOS I have to open the .psd in an iframe, then expect the user to figure out that they have to; select "More" (NOT "open in documents")  then "save to files" (NOT "Save Image") >> "On my ipad" >> "Procreate" ..then exit Safari, open Procreate, and open the psd.


..all of this instead of the browser standard click to download (not even long press) ..then "Always Open Files of This Type" (the first time) from then on, one click to Download & automatically Open.
Comment 10 Frédéric Wang (:fredw) 2018-06-18 23:01:01 PDT
Created attachment 343024 [details]
Testcase

Link in comment 1 seems dead, so here is a simple testcase.
Comment 11 Frédéric Wang (:fredw) 2018-06-19 01:52:43 PDT
Preliminary analysis: The code involved is the same as in bug 165627 comment 6. When the anchor is clicked, the Web Process dispatches a "decide policy for navigation action":

# WebKit::WebFrameLoaderClient::dispatchDecidePolicyForNavigationAction
# WebCore::PolicyChecker::checkNavigationPolicy
# WebCore::FrameLoader::loadWithDocumentLoader
# WebCore::FrameLoader::loadWithNavigationAction
# WebCore::FrameLoader::loadURL
# WebCore::FrameLoader::loadFrameRequest
# WebCore::FrameLoader::urlSelected
# WebCore::FrameLoader::urlSelected
# WebCore::HTMLAnchorElement::handleClick

On the UI Process, we arrive on

# WebKit::NavigationState::NavigationClient::decidePolicyForNavigationAction
# WebKit::WebPageProxy::decidePolicyForNavigationAction

Then some proprietary code is executed and we arrive on the decideHandlerWithPolicies callback:

(1) For attachment 343024 [details] (data: URL) it returns WKNavigationActionPolicyAllow and tryAppLink fails with
    Error Domain=NSURLErrorDomain Code=-1002 "(null)" UserInfo={NSErrorFailingURLKey=data:image/png%3Bbase64,iVBORw0KGgoAAAANSUhEUgAAADYAAAA3BAMAAAC1N6RLAAAAMFBMVEWCARyBB0a/AQ0NSo4odqvXf4D/hgZmqMnLp5ykwjP/ ... rkJggg==}
   Finally the alert message of comment 2 is displayed.

(2) For other links (e.g. https://www.w3schools.com/TAGS/tryit.asp?filename=tryhtml5_a_download) it returns _WKNavigationActionPolicyAllowWithoutTryingAppLink
   and again the alert message of comment 2 is displayed.
   However, if one forces the tryAppLink code to be executed before, we get:
   Error Domain=NSOSStatusErrorDomain Code=-10814 "(null)"

In both case, forcing _WKNavigationActionPolicyDownload still results in the same error message mentioned in comment 2.
Comment 12 Arcangelo Vicedomini 2018-07-10 03:20:08 PDT
Hello, This issue was opened 1year and 6months ago, and I really cannot understand why this is not yet resolved, after 4 years since the publication of the specs (HTML5 W3C publication was on October 2014).

Me, and a lot of other companies that I know, downloads a blob via RESTful API and uses the HTML5 `<a href="{objectUrl}" download="resume.pdf">Download resume</a>` technique, which works in all other major browsers (Chrome, FF, Edge and Opera), or the `window.saveAs` function.

I've tried both solution on my Web App and we're unable to download a single PDF to the users' iPhone or iPad.

Is there any ETA for this issue to be resolved? 

Best regards,

Arcangelo
Comment 13 Frédéric Wang (:fredw) 2018-07-10 03:31:45 PDT
(In reply to Arcangelo Vicedomini from comment #12)
> Is there any ETA for this issue to be resolved? 

As mentioned in comment 11, fixing this will certainly involve proprietary code so it is up to Apple to fix it. And in general, there is unfortunately no ETA about when a bug will be fixed in releases: https://trac.webkit.org/wiki/FAQ#WhenwillbugXXXbefixed ; sorry about that.
Comment 14 Adam Lippai 2018-09-26 07:09:50 PDT
Using Service Workers and streams we face other problems: https://github.com/jimmywarting/StreamSaver.js/issues/69#issuecomment-424716393

If it has a different cause, I'd be happy to file a new issue.
Comment 15 Henrik Joreteg 2018-12-12 23:52:58 PST
My company has built a web app that doctors use during surgery to produce anesthesia charts. The final product of the web app is a PDF that the doctors download.

The user flow is great in every major browser except Safari on iOS.

This has been a giant thorn in our side and frankly makes Apple look bad. Because we have to explain to these doctors that if they're using an iPad they have to do extra work to of saving the final report. The UX flow for this is not ideal, by the way.

Adding support for the `download` attribute, especially now that iOS 11+ has a Files app... would be a huge relief for us and our product team.

**Please** consider adding this.

Thank you!
Comment 16 jon.ronnenberg 2018-12-13 00:10:38 PST
@Henrik, you're in luck!

I'm pretty sure I've found the holy grail in cross-browser PDF download.

Here is a live example: https://dotnetcarpenter.github.io/FileReader_Chrome/

And here is the repo: https://github.com/dotnetCarpenter/FileReader_Chrome

```js
fetch('example.pdf', {
    method: 'get',
})
.then(response => response.blob())
.then(blob => {
    const fileName = 'example.pdf'
    if (navigator.msSaveBlob) { // IE11 and Edge 17-
        navigator.msSaveBlob(blob, fileName)
    } else { // every other browser
        const reader = new FileReader()
        reader.onloadend = () => {
            const a = document.createElement("a")
            a.href = reader.result
            a.style.display = 'none'
            a.download = fileName
            document.body.appendChild(a)
            a.click()
            a.parentNode.removeChild(a)
        }
        reader.readAsDataURL(blob)
    }
})
```

For IE11 support, if you do not use a transpiler then, you can substitute fetch with https://github.com/axios/axios and change fat arrows` to ES5 anonymous functions. But everything else should "Just work".
Comment 17 Nicola Zanon 2018-12-13 00:47:42 PST
Hi,

we rely on the download attribute for our application as well. Works like a charm for all the major browser except Safari on IOS.

Is there any update, timeline by any chance?

Anything we can do to help?

Thank you!
Comment 18 Thomas Steiner 2018-12-13 10:57:23 PST
+1, this would make a couple of our use cases easier as well.
Comment 19 Henrik Joreteg 2018-12-13 13:59:59 PST
(In reply to jon.ronnenberg from comment #16)
> @Henrik, you're in luck!
> 
> I'm pretty sure I've found the holy grail in cross-browser PDF download.
> 
> Here is a live example: https://dotnetcarpenter.github.io/FileReader_Chrome/
> 
> And here is the repo: https://github.com/dotnetCarpenter/FileReader_Chrome
> 
> ```js
> fetch('example.pdf', {
>     method: 'get',
> })
> .then(response => response.blob())
> .then(blob => {
>     const fileName = 'example.pdf'
>     if (navigator.msSaveBlob) { // IE11 and Edge 17-
>         navigator.msSaveBlob(blob, fileName)
>     } else { // every other browser
>         const reader = new FileReader()
>         reader.onloadend = () => {
>             const a = document.createElement("a")
>             a.href = reader.result
>             a.style.display = 'none'
>             a.download = fileName
>             document.body.appendChild(a)
>             a.click()
>             a.parentNode.removeChild(a)
>         }
>         reader.readAsDataURL(blob)
>     }
> })
> ```
> 
> For IE11 support, if you do not use a transpiler then, you can substitute
> fetch with https://github.com/axios/axios and change fat arrows` to ES5
> anonymous functions. But everything else should "Just work".

Have you tried this in iOS Safari. I tried doing it with a FileReader to no avail. Your last step still depends on the `download` attribute, no? The other issue I'm having is I have no way to give the blob file a proper name. It's always "unknown" :-/
Comment 20 jon.ronnenberg 2018-12-14 07:18:52 PST
(In reply to Henrik Joreteg from comment #19)
> (In reply to jon.ronnenberg from comment #16)
> > @Henrik, you're in luck!
> > 
> > I'm pretty sure I've found the holy grail in cross-browser PDF download.
> > 
> > Here is a live example: https://dotnetcarpenter.github.io/FileReader_Chrome/
> > 
> > And here is the repo: https://github.com/dotnetCarpenter/FileReader_Chrome
> > 
> > ```js
> > fetch('example.pdf', {
> >     method: 'get',
> > })
> > .then(response => response.blob())
> > .then(blob => {
> >     const fileName = 'example.pdf'
> >     if (navigator.msSaveBlob) { // IE11 and Edge 17-
> >         navigator.msSaveBlob(blob, fileName)
> >     } else { // every other browser
> >         const reader = new FileReader()
> >         reader.onloadend = () => {
> >             const a = document.createElement("a")
> >             a.href = reader.result
> >             a.style.display = 'none'
> >             a.download = fileName
> >             document.body.appendChild(a)
> >             a.click()
> >             a.parentNode.removeChild(a)
> >         }
> >         reader.readAsDataURL(blob)
> >     
> > ```
> > 
> > For IE11 support, if you do not use a transpiler then, you can substitute
> > fetch with https://github.com/axios/axios and change fat arrows` to ES5
> > anonymous functions. But everything else should "Just work".
> 
> Have you tried this in iOS Safari. I tried doing it with a FileReader to no
> avail. Your last step still depends on the `download` attribute, no? The
> other issue I'm having is I have no way to give the blob file a proper name.
> It's always "unknown" :-/
 

Yes, I have tried on an iPhone, with iOS12 and it worked fine. https://dotnetcarpenter.github.io/FileReader_Chrome/ Which iOS version did you test with?

The trick is to base64 encode the `a.href` content, which is what the `FileReader` does. `a.download` doesn't work on iOS Safari, as you know, but sets the file name in Chrome and Firefox.

In IE11 (and Edge) you do not need to base64 encode the binary PDF data but can use `navigator.msSaveBlob` (and `navigator.msSaveOrOpenBlob`), so we can just use that.

One other solution (but won't force save) is to have a normal link that points to your server and your server response with the binary PDF data and the following 3 headers:

```
Content-Length: <blob.size>
Content-Type: application/pdf
Content-Disposition: attachment;filename=<defaultName>
```
_Source: https://msdn.microsoft.com/en-us/library/hh772332(v=vs.85).aspx_


Hope it helps.

PS. It would still be far easier if Apple got support for the `download` attribute on iOS.
Comment 21 jon.ronnenberg 2018-12-14 07:22:14 PST
The MS documentation link should have been https://msdn.microsoft.com/en-us/library/hh772332(v=vs.85).aspx
Comment 22 jon.ronnenberg 2018-12-14 07:28:54 PST
Hmmm... According to https://msdn.microsoft.com/en-us/library/hh772331(v=vs.85).aspx you could try to force save a PDF document with the following headers (I haven't tested this though):

```
Content-Length: <blob.size>
Content-Type: application/pdf
Content-Disposition: attachment;filename=<defaultName>
X-Download-Options: noopen
```
Comment 23 jon.ronnenberg 2018-12-17 10:13:31 PST
(In reply to jon.ronnenberg from comment #20)

I wrote "binary PDF data" a couple of times. That's not accurate. My IDE (vscode) reports my test file as binary data but it turns out that both Github and AmazoneS3 servers response with the data as base64 (according to Firefox Network tool).

The "example.pdf" is (like all other PDFs) a mixed of ASCII and different encodings, neither are binary.
.
> (In reply to Henrik Joreteg from comment #19)
> > The other issue I'm having is I have no way to give the blob file a proper name.
> > It's always "unknown" :-/

I have no solution for setting the name on iOS Safari.
Other than fixing this bug (167341).
Comment 24 Henrik Joreteg 2018-12-18 21:02:24 PST
For a more thorough explanation of the situation and the iterations I went through, see this twitter thread: https://twitter.com/HenrikJoreteg/status/1074578495592898560

Forgive the somewhat frustrated tone, it's because, well... I was somewhat frustrated.

I realize things have to be prioritized and some things are harder than they seem. Anyway, I do think this would be a great addition and I would really appreciate someone's efforts to resolve this. <3
Comment 25 Jeff Slater 2019-01-09 10:07:37 PST
Work with a lot of clients using sales enablement tools. One lacking feature is the ability to save sales information to pdfs while offline. Currently the sales teams of several clients are using IOS devices but may be switching soon to a platform that will support this feature.
Comment 26 Chris Dumez 2019-01-25 12:58:43 PST
Created attachment 360148 [details]
WIP Patch
Comment 27 Chris Dumez 2019-01-25 13:28:14 PST
Created attachment 360153 [details]
Patch
Comment 28 Chris Dumez 2019-01-25 13:38:17 PST
Created attachment 360154 [details]
Patch
Comment 29 Chris Dumez 2019-01-25 15:04:22 PST
Created attachment 360170 [details]
Patch
Comment 30 Geoffrey Garen 2019-01-25 15:42:09 PST
Comment on attachment 360170 [details]
Patch

r=me
Comment 31 WebKit Commit Bot 2019-01-25 16:44:22 PST
Comment on attachment 360170 [details]
Patch

Clearing flags on attachment: 360170

Committed r240530: <https://trac.webkit.org/changeset/240530>
Comment 32 WebKit Commit Bot 2019-01-25 16:44:25 PST
All reviewed patches have been landed.  Closing bug.
Comment 33 Mauricio Taranto 2019-02-22 12:22:01 PST
HI All,

Im still having issues on download for IOS devices. I saw that this bug was closed bug it was already deployed?

I try the anchor workaround but seems not be working fine, since the file name is always unknown.

Any one knows if this is already in "prod"?


Thanks,
Comment 34 Chris Dumez 2019-02-22 12:32:53 PST
(In reply to Mauricio Taranto from comment #33)
> HI All,
> 
> Im still having issues on download for IOS devices. I saw that this bug was
> closed bug it was already deployed?
> 
> I try the anchor workaround but seems not be working fine, since the file
> name is always unknown.
> 
> Any one knows if this is already in "prod"?
> 
> 
> Thanks,

No, support for the download attribute on iOS is not in production yet, it is not even available in a public beta yet.
Comment 35 Chris Dumez 2019-06-03 13:42:20 PDT
(In reply to Chris Dumez from comment #34)
> (In reply to Mauricio Taranto from comment #33)
> > HI All,
> > 
> > Im still having issues on download for IOS devices. I saw that this bug was
> > closed bug it was already deployed?
> > 
> > I try the anchor workaround but seems not be working fine, since the file
> > name is always unknown.
> > 
> > Any one knows if this is already in "prod"?
> > 
> > 
> > Thanks,
> 
> No, support for the download attribute on iOS is not in production yet, it
> is not even available in a public beta yet.

For people interested in testing this feature, it is enabled in the iOS 13 Developer beta 1, along with true downloads support in MobileSafari.
Please file issues you find on this bug tracker, thanks.
Comment 36 Michaela Merz 2019-08-17 15:18:34 PDT
Though in principal, the download attribute works - there are still a few issues.

With home-screen installed "PWAs": After clicking the link with download attribute set, a page pops up that shows the correct file-type, but "unknown" as file name. After clicking this page ("Open in ..") the file target selection menu opens, shows the correct file-name / type and allows to select the target for the file. In other words: The first page after clicking the download in PWAs doesn't have the name set correctly.

iOS Public Beta 6
Comment 37 David Kilzer (:ddkilzer) 2019-08-17 21:11:14 PDT
(In reply to Michaela Merz from comment #36)
> Though in principal, the download attribute works - there are still a few
> issues.
> 
> With home-screen installed "PWAs": After clicking the link with download
> attribute set, a page pops up that shows the correct file-type, but
> "unknown" as file name. After clicking this page ("Open in ..") the file
> target selection menu opens, shows the correct file-name / type and allows
> to select the target for the file. In other words: The first page after
> clicking the download in PWAs doesn't have the name set correctly.
> 
> iOS Public Beta 6

Thanks!  Could you file a Feedback Assistant issue for this bug, and paste the FB number here?  (You can also file a bug on this website.)
Comment 38 Michaela Merz 2019-08-18 15:35:15 PDT
I filed it again via the developer account on the iPhone. Do you want me to open a new bug here too?

m.
Comment 39 David Kilzer (:ddkilzer) 2019-08-18 20:58:56 PDT
(In reply to Michaela Merz from comment #38)
> I filed it again via the developer account on the iPhone. Do you want me to
> open a new bug here too?

No need to open a new bug here, but we need the Feedback Assistant ID (FBnnnnnnnn) in order to find it.  Probably easiest to post that here, but feel free to email it to me if you'd like.  Thanks!
Comment 40 dgriffin 2019-08-19 08:17:18 PDT
While testing this on iOS 13 Developer beta 7 using FileSaver JS I noted the following - 

If file type is CSV I am immediately prompted to download the file with expected filename, no new tabs or page redirects, so all good.

If file type is PDF then current page is redirected to the object URL created by FileSaver JS. From here selecting "Save to Files" defaults the filename to "Unknown" however I can edit the filename prior to saving.

Should PDF files not behave as CSV files do in this instance?

Executing same code on Safari on macOS works well, i.e. Both CSV and PDF files are immediately downloaded with expected filenames.

Thanks.
Comment 41 Michaela Merz 2019-08-19 08:22:28 PDT
@ddkilzer here's the Feedback Assistant ID: FB7067179 

I'd like top add that we are not using any plugin or library, just "vanilla" links with download attribute.

m.
Comment 42 David Kilzer (:ddkilzer) 2019-08-19 18:42:37 PDT
(In reply to Michaela Merz from comment #41)
> @ddkilzer here's the Feedback Assistant ID: FB7067179 
> 
> I'd like top add that we are not using any plugin or library, just "vanilla"
> links with download attribute.
> 
> m.

Thanks!  For other Apple employees:  FB7067179 maps to <rdar://problem/54447901>.

Michaela, could you also attach a screen recording to FB7067179 of this bug happening?
Comment 43 David Kilzer (:ddkilzer) 2019-08-19 18:49:08 PDT
(In reply to dgriffin from comment #40)
> While testing this on iOS 13 Developer beta 7 using FileSaver JS I noted the
> following - 
> 
> If file type is CSV I am immediately prompted to download the file with
> expected filename, no new tabs or page redirects, so all good.
> 
> If file type is PDF then current page is redirected to the object URL
> created by FileSaver JS. From here selecting "Save to Files" defaults the
> filename to "Unknown" however I can edit the filename prior to saving.
> 
> Should PDF files not behave as CSV files do in this instance?
> 
> Executing same code on Safari on macOS works well, i.e. Both CSV and PDF
> files are immediately downloaded with expected filenames.

Sounds like a bug.  Could you file a Feedback Assistant bug report and give the FBnnnnnnnn ID here?  Would be best you could create a self-contained test, or provide a website that it reproduces on.

If you can't create a test case, grabbing full HTTP respnose headers would be the second best information to include in the bug report.  MobileSafari prefers the filename in the Content-Disposition header, but falls back to extracting a filename from the URL, then tries to use the MIME type if the filename has no extension.  (This is an oversimplification of what it does, but hopefully you get the idea.)
Comment 44 dgriffin 2019-08-20 04:14:06 PDT
(In reply to David Kilzer (:ddkilzer) from comment #43)
> (In reply to dgriffin from comment #40)
> > While testing this on iOS 13 Developer beta 7 using FileSaver JS I noted the
> > following - 
> > 
> > If file type is CSV I am immediately prompted to download the file with
> > expected filename, no new tabs or page redirects, so all good.
> > 
> > If file type is PDF then current page is redirected to the object URL
> > created by FileSaver JS. From here selecting "Save to Files" defaults the
> > filename to "Unknown" however I can edit the filename prior to saving.
> > 
> > Should PDF files not behave as CSV files do in this instance?
> > 
> > Executing same code on Safari on macOS works well, i.e. Both CSV and PDF
> > files are immediately downloaded with expected filenames.
> 
> Sounds like a bug.  Could you file a Feedback Assistant bug report and give
> the FBnnnnnnnn ID here?  Would be best you could create a self-contained
> test, or provide a website that it reproduces on.
> 
> If you can't create a test case, grabbing full HTTP respnose headers would
> be the second best information to include in the bug report.  MobileSafari
> prefers the filename in the Content-Disposition header, but falls back to
> extracting a filename from the URL, then tries to use the MIME type if the
> filename has no extension.  (This is an oversimplification of what it does,
> but hopefully you get the idea.)

Hi,

Feedback Assistant ID is FB7081863.

Thanks.
Comment 45 Michaela Merz 2019-08-20 08:28:46 PDT
Created attachment 376769 [details]
Screen Video Of Bug

As requested, a screen video is attached.
Comment 46 David Kilzer (:ddkilzer) 2019-08-20 09:58:41 PDT
(In reply to Michaela Merz from comment #45)
> Created attachment 376769 [details]
> Screen Video Of Bug
> 
> As requested, a screen video is attached.

Thanks!  I've attached it to the radar as well.
Comment 47 David Kilzer (:ddkilzer) 2019-08-20 09:59:54 PDT
(In reply to dgriffin from comment #44)
> (In reply to David Kilzer (:ddkilzer) from comment #43)
> > (In reply to dgriffin from comment #40)
> > > While testing this on iOS 13 Developer beta 7 using FileSaver JS I noted the
> > > following - 
> > > 
> > > If file type is CSV I am immediately prompted to download the file with
> > > expected filename, no new tabs or page redirects, so all good.
> > > 
> > > If file type is PDF then current page is redirected to the object URL
> > > created by FileSaver JS. From here selecting "Save to Files" defaults the
> > > filename to "Unknown" however I can edit the filename prior to saving.
> > > 
> > > Should PDF files not behave as CSV files do in this instance?
> > > 
> > > Executing same code on Safari on macOS works well, i.e. Both CSV and PDF
> > > files are immediately downloaded with expected filenames.
> > 
> > Sounds like a bug.  Could you file a Feedback Assistant bug report and give
> > the FBnnnnnnnn ID here?  Would be best you could create a self-contained
> > test, or provide a website that it reproduces on.
> > 
> > If you can't create a test case, grabbing full HTTP respnose headers would
> > be the second best information to include in the bug report.  MobileSafari
> > prefers the filename in the Content-Disposition header, but falls back to
> > extracting a filename from the URL, then tries to use the MIME type if the
> > filename has no extension.  (This is an oversimplification of what it does,
> > but hopefully you get the idea.)
> 
> Hi,
> 
> Feedback Assistant ID is FB7081863.
> 
> Thanks.

Thanks!  For other Apple employees:  FB7081863 maps to <rdar://problem/54506430>.

I assume you were testing this on Safari for iOS (MobileSafari), correct?
Comment 48 David Kilzer (:ddkilzer) 2019-08-20 10:07:24 PDT
Michaela & dgriffin:

Can both of you check the MIME type returned from your download URLs?

There was another change in iOS 13 that stopped sniffing the contents of HTTP responses that were returned as "application/octet-stream" (as a security hardening measure).  That means if your PDF isn't sent as "application/pdf" (or similar) and the JPEG image isn't sent as "image/jpeg", then Safari (or Web.app) may not be able to infer the type of the file.

Also, you should check that a "Content-Disposition" header is sent with an "attachment" attribute and a "filename" attribute if you want to ensure that the file downloaded has the correct name:  <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition>

If both the MIME type and the Content-Disposition header are being sent, and you STILL see the "Unknown" name in the preview (or no preview--because PDF and JPEG files should have previews!), then please let me know.  (I would prefer that you add comments to the Feedback Assistant bug reports that you filed, but I will also monitor this bug for comments.)
Comment 49 Michaela Merz 2019-08-20 13:55:11 PDT
In our case, we're sending blobs. So the download is an internal browser issue. Not sure if one can even manipulate the headers in this case. However - the blobs have the mime-type set correctly (and it is shown correctly) and the file name is based via the download attribute. As you can see in the video, the second page shows all relevant data correctly, it's just the "in between" page that has problems.
Comment 50 dgriffin 2019-08-21 08:20:55 PDT
Re: I assume you were testing this on Safari for iOS (MobileSafari), correct?
Correct, Safari for iOS 13 beta 7.

We are also using blobs as the file is created dynamically on the client once the user selects the download link. As such the href attribute ends up looking something like "blob:https://whatever.com/adf21c2c-4ca2-4b1a-9fc7-340430a425cs", with the download attribute set to the desired filename, i.e. "Transactions.pdf". I have verified that the blobs have the mime-type set correctly. When we then select the "Save to Files" option from the PDF preview page via the Action menu, the "Save to Files" dialogue displays "'Unknown.pdf' will be saved to iCloud Drive."

Aside from the filename issue, does the expected behavior differ on Safari for iOS versus macOS in that on macOS the PDF file is not previewed, rather it is immediately downloaded with the desired filename. On Safari for iOS must a PDF always be previewed? 

With our equivalent CSV file on Safari for iOS the file is not previewed, rather the user is prompted to View or Download the file with the correct filename displayed. This would be the ideal behavior for us for PDFs but I accept this may not apply to PDFs on Safari for iOS for whatever reasons.

Thanks.
Comment 51 David Kilzer (:ddkilzer) 2019-08-21 15:58:32 PDT
(In reply to dgriffin from comment #50)
> We are also using blobs as the file is created dynamically on the client
> once the user selects the download link. As such the href attribute ends up
> looking something like
> "blob:https://whatever.com/adf21c2c-4ca2-4b1a-9fc7-340430a425cs", with the
> download attribute set to the desired filename, i.e. "Transactions.pdf". I
> have verified that the blobs have the mime-type set correctly. When we then
> select the "Save to Files" option from the PDF preview page via the Action
> menu, the "Save to Files" dialogue displays "'Unknown.pdf' will be saved to
> iCloud Drive."

Interesting.

> Aside from the filename issue, does the expected behavior differ on Safari
> for iOS versus macOS in that on macOS the PDF file is not previewed, rather
> it is immediately downloaded with the desired filename. On Safari for iOS
> must a PDF always be previewed? 

At one point, MobileSafari always tried to show a preview for downloaded PDF since that was the most useful thing it could do.  I didn't work on the new download manager in iOS 13, so MobileSafari may not try to show a preview every time now (I'm not sure).

> With our equivalent CSV file on Safari for iOS the file is not previewed,
> rather the user is prompted to View or Download the file with the correct
> filename displayed. This would be the ideal behavior for us for PDFs but I
> accept this may not apply to PDFs on Safari for iOS for whatever reasons.

This sounds like a bug we'd want to fix, but I can't predict whether it will be fixed by iOS 13 GM since it was reported quite late in the seed builds.  (Best to report issues after Dev Seed 1 to give maximum time to fix--just FYI for future reference.)

BTW, an online (or offline) demo for either the FileSaver JS framework (dgriffin) or Web.app (Michaela) would be extremely useful to us to make sure we're seeing the same issue you're seeing (versus us creating our own "client-assembled blob" test webpage or web app).