Bug 167341

Test case at: https://bugs.webkit.org/show_bug.cgi?id=162788#c15

When you click such link, you get a dialog saying it failed to install the profile (instead of opening the file in iBooks).

<rdar://problem/30296281>

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?

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.

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.

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.

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 😢

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.

Created attachment 343024 [details] Testcase Link in comment 1 seems dead, so here is a simple testcase.

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.

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

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

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.

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!

@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".

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!

+1, this would make a couple of our use cases easier as well.

(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" :-/

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

The MS documentation link should have been https://msdn.microsoft.com/en-us/library/hh772332(v=vs.85).aspx

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 ```

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

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

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.

Created attachment 360148 [details] WIP Patch

Created attachment 360153 [details] Patch

Created attachment 360154 [details] Patch

Created attachment 360170 [details] Patch

Comment on attachment 360170 [details] Patch r=me

Comment on attachment 360170 [details] Patch Clearing flags on attachment: 360170 Committed r240530: <https://trac.webkit.org/changeset/240530>

All reviewed patches have been landed. Closing bug.

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,

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

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

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

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

I filed it again via the developer account on the iPhone. Do you want me to open a new bug here too? m.

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

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.

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

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

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

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

Created attachment 376769 [details] Screen Video Of Bug As requested, a screen video is attached.

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

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

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

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.

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.

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

(In reply to David Kilzer (:ddkilzer) from comment #51) > (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). ------------------------------------------------------------ I'm trying to determine the likely timescales for an iOS fix for this. If it's not going to happen within, say... 3 months, then we'll apply an ugly workaround. I'm happy to help though if that will speed things along. ------------------------------------------------------------ Looks like there's been no movement on this issue since 2019-08-21. Has anyone done any work on this since then ? David - is it the case that all you're waiting for is a test case ? Or has this been pushed down your list of priorities ?

(In reply to Peter Kemp from comment #52) > (In reply to David Kilzer (:ddkilzer) from comment #51) > > (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). > ------------------------------------------------------------ > I'm trying to determine the likely timescales for an iOS fix for this. If > it's not going to happen within, say... 3 months, then we'll apply an ugly > workaround. > I'm happy to help though if that will speed things along. > ------------------------------------------------------------ > Looks like there's been no movement on this issue since 2019-08-21. > Has anyone done any work on this since then ? > David - is it the case that all you're waiting for is a test case ? Or has > this been pushed down your list of priorities ? Sorry, I should have been clearer about next steps when I posted previously. Support for the "download" attribute was added in iOS 13.0. If you have a specific use case with the "download" attribute that doesn't work in iOS 13.0 or later, you need to file a new bug here on bugs.webkit.org with steps to reproduce and (if possible) a reduced test case that will reproduce the issue. Thank you for following up.

(In reply to David Kilzer (:ddkilzer) from comment #53) > (In reply to Peter Kemp from comment #52) > > (In reply to David Kilzer (:ddkilzer) from comment #51) > > > (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). > > ------------------------------------------------------------ > > I'm trying to determine the likely timescales for an iOS fix for this. If > > it's not going to happen within, say... 3 months, then we'll apply an ugly > > workaround. > > I'm happy to help though if that will speed things along. > > ------------------------------------------------------------ > > Looks like there's been no movement on this issue since 2019-08-21. > > Has anyone done any work on this since then ? > > David - is it the case that all you're waiting for is a test case ? Or has > > this been pushed down your list of priorities ? > > Sorry, I should have been clearer about next steps when I posted previously. > > Support for the "download" attribute was added in iOS 13.0. > > If you have a specific use case with the "download" attribute that doesn't > work in iOS 13.0 or later, you need to file a new bug here on > bugs.webkit.org with steps to reproduce and (if possible) a reduced test > case that will reproduce the issue. > > Thank you for following up. Oops, are you referencing FB7081863 (<rdar://problem/54506430>) that was noted in a previous comment?

I just realized that the `download` attribute doesn't work with blob: URLs in WKWebView. In contrast, data: URLs work there. Is this on purpose? Both methods work correctly in Safari itself. Here's a small demo: https://wkwebview-download.glitch.me/.

(In reply to Thomas Steiner from comment #55) > I just realized that the `download` attribute doesn't work with blob: URLs > in WKWebView. In contrast, data: URLs work there. Is this on purpose? Both > methods work correctly in Safari itself. Here's a small demo: > https://wkwebview-download.glitch.me/. Thanks for testing! Please file a new bug report for this follow-up issue so we can track it separately.

> Please file a new bug report for this follow-up issue so we can track it separately. Here we go: https://bugs.webkit.org/show_bug.cgi?id=216918.

Is this bug fixed? I'm using file saver and download only opens a new tab in iOS 14. I double checked and the content type header I used is in the correct format (image/png)

Any news about this bug? download works now, but files are always named "document" it's not comfortable for the user since if it's a PDF the user cannot open it directly, he/she has to renamed to .pdf extension. this issue is not existing on firefox, edege, opera and safari.

(In reply to Robert Northland from comment #59) > Any news about this bug? > download works now, but files are always named "document" > it's not comfortable for the user since if it's a PDF the user cannot open > it directly, he/she has to renamed to .pdf extension. > this issue is not existing on firefox, edege, opera and safari. This indicates this is a MobileSafari bug, not a WebKit one (since all browsers use WebKit on iOS).

please re-read my comment I said this issue does NOT exist on safari, firefox, opera and edge

(In reply to Robert Northland from comment #61) > please re-read my comment > I said this issue does NOT exist on safari, firefox, opera and edge Hi Robert. This sounds like you are working on a WebKit-based application that needs to perform downloads. WebKit does not do all the work of managing downloads -- you need to implement the various WKDownload delegate methods to handle specific details of file handling. You should be able to find examples of this in Firefox source code. I don't think what you are reporting is a WebKit engine bug (though it may be a reflection of poor documentation on our side!).

Hi Brent, no I just use JS to populate a blob and save it.

(In reply to Robert Northland from comment #63) > Hi Brent, > no I just use JS to populate a blob and save it. I'm confused. What is the use case where this fails, if the problem does not occur in Safari, Firefox, or Chrome? Do you just mean that you can download in some other fashion in those apps, but the JS use case you have does not work? I think this bug is getting confusing. Could you please file a new bug with specific steps so we can investigate?

I get a blob from XMLHttpRequest: then I populate the <a> link element with "download" attribute like this ----------- if(window.navigator.msSaveBlob){ navigator.msSaveBlob(blob,form.blobName.value); }else if(window.navigator.msSaveOrOpenBlob){ navigator.msSaveOrOpenBlob(blob,form.blobName.value); }else{ if(this['FileReader']){ reader = new FileReader(); reader.onload = function(event){ aLink = document.createElement('a'); aLink.setAttribute("download",form.blobName.value); aLink.setAttribute("href",reader.result); document.body.appendChild(aLink); aLink.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: true, view: window})); aLink.remove(); }; reader.onerror = function(event){ alert("saveBlob reader.onerror*:* "+String(event.error)); }; reader.readAsDataURL(blob); }else{ windowUrl = this['URL'] || this['webkitURL'] || null; if(windowUrl){ url = windowUrl.createObjectURL(blob); if(url){ aLink = document.createElement('a'); aLink.setAttribute("download",form.blobName.value); aLink.setAttribute("href",url); document.body.appendChild(aLink); aLink.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: true, view: window})) aLink.remove(); revokeTimeout = setTimeout(function(){windowUrl.revokeObjectURL(url)},250); }else{ alert("saveBlob windowUrl*:* url null"); } }else{ alert("saveBlob*:* windowUrl null"); } } } ---------- Only on chrome IOS, the name of the file to save is always "Document" rather than the name I gave to with download attributes

(In reply to Robert Northland from comment #65) > I get a blob from XMLHttpRequest: > then I populate the <a> link element with "download" attribute like this > > ----------- > > if(window.navigator.msSaveBlob){ > navigator.msSaveBlob(blob,form.blobName.value); > }else if(window.navigator.msSaveOrOpenBlob){ > navigator.msSaveOrOpenBlob(blob,form.blobName.value); > }else{ > if(this['FileReader']){ > reader = new FileReader(); > reader.onload = function(event){ > aLink = document.createElement('a'); > aLink.setAttribute("download",form.blobName.value); > aLink.setAttribute("href",reader.result); > document.body.appendChild(aLink); > aLink.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: > true, view: window})); > aLink.remove(); > }; > reader.onerror = function(event){ > alert("saveBlob reader.onerror*:* "+String(event.error)); > }; > reader.readAsDataURL(blob); > }else{ > windowUrl = this['URL'] || this['webkitURL'] || null; > if(windowUrl){ > url = windowUrl.createObjectURL(blob); > if(url){ > aLink = document.createElement('a'); > aLink.setAttribute("download",form.blobName.value); > aLink.setAttribute("href",url); > document.body.appendChild(aLink); > aLink.dispatchEvent(new MouseEvent('click', {bubbles: true, cancelable: > true, view: window})) > aLink.remove(); > revokeTimeout = > setTimeout(function(){windowUrl.revokeObjectURL(url)},250); > }else{ > alert("saveBlob windowUrl*:* url null"); > } > }else{ > alert("saveBlob*:* windowUrl null"); > } > } > } > > ---------- > > Only on chrome IOS, the name of the file to save is always "Document" rather > than the name > I gave to with download attributes Ah, that's because Chrome on iOS hasn't yet adopted the new WKDownload delegate methods, but this is currently being worked on (see crbug.com/1252380).

(In reply to Brent Fulgham from comment #62) > (In reply to Robert Northland from comment #61) > > please re-read my comment > > I said this issue does NOT exist on safari, firefox, opera and edge Got it -- I overlooked Chrome here (I just somehow saw it in the list, even though you didn't write that). Ali explained below. Thanks!

Years have passed and the problem reappears in Google iOS. This time Safari is not the focus. However, Chrome now shows the same bug. As already mentioned by other users, instead of downloading after clicking, it opens the iPhone video stream. How can I get around this problem? I've tried using HTTP_RANGE, it still doesn't work. The download with both HTTP_RANGE and the download attribute are working in Safari, but not in Chrome iOS. Ignore the grammatical, I'm Brazilian and it may contain typos. Translated with www.DeepL.com/Translator (free version)

(In reply to Matheus Azzi from comment #68) > Years have passed and the problem reappears in Google iOS. This time Safari > is not the focus. However, Chrome now shows the same bug. As already > mentioned by other users, instead of downloading after clicking, it opens > the iPhone video stream. How can I get around this problem? I've tried using > HTTP_RANGE, it still doesn't work. > > The download with both HTTP_RANGE and the download attribute are working in > Safari, but not in Chrome iOS. > > Ignore the grammatical, I'm Brazilian and it may contain typos. > > Translated with www.DeepL.com/Translator (free version) Hi Matheus -- this was explained by Ali (a Chrome engineer) in an earlier message: "Chrome on iOS hasn't yet adopted the new WKDownload delegate methods, but this is currently being worked on (see crbug.com/1252380)"

Hello, I am still seeing issues with the download attribute specifically when using it to download TXT and XML files on iOS Safari. Instead of downloading the file, it opens it in the browser. Please advise next steps. This is on iOS version 16.6.1

Hello, I am still seeing issues with the download attribute specifically when using it to download TXT and XML files on iOS Safari. Instead of downloading the file, it opens it in the browser. Please advise next steps. This is on iOS version 16.6.1

Please file a new bug report, preferably with steps to reproduce that we can follow.

Ok thanks, added here: https://bugs.webkit.org/show_bug.cgi?id=263608