Ios download link dialog

Avoid pronouns such as you, your, me, and my, which are sometimes interpreted as insulting or patronizing. Avoid explaining the alert buttons. If your alert text and button titles are clear, there should be no need to explain what the buttons do. Generally, use two-button alerts. Two-button alerts provide an easy choice between two alternatives. Single-button alerts inform, but give no control over the situation. Alerts with three or more buttons create complexity and can require scrolling, which is a bad user experience.

If you find that you need more than two choices, consider using an action sheet instead. See Action Sheets. Give alert buttons succinct, logical titles. The best button titles consist of one or two words that describe the result of selecting the button. As with all button titles, use title-style capitalization and no ending punctuation.

To the extent possible, use verbs and verb phrases that relate directly to the alert title and message—for example, View All, Reply, or Ignore.

Use OK for simple acceptance. Avoid using Yes and No. Place buttons where people expect them. Hitting the back button to return to previous tab content isn't always cheap or even possible. IE has the some of the same problems, but has msSaveBlob as a workaround. It also doesn't open content into the same tab by default. Safari doesn't have anything to solve these issues simply as far as I can tell.

Seems that Safari still can't download some blobs but still tries to display them even if they fail like. Also the blob name is used for the displayed content instead of the download attribute, so that's also super cryptic for the users. These reports have occurred for years, so I anticipate no resolution to Apple adding the download attribute. The best solution recommended was converting to a data: url and base64 encoding the content stream.

That bloats the content needlessly, and still doesn't preserve the filename. Search by keywords or tags Submit Search Clear search query Additional information about Search by keywords or tags Supported Searches:. Click again to start watching. Probably easiest to post that here, but feel free to email it to me if you'd like. From here selecting "Save to Files" defaults the filename to "Unknown" however I can edit the filename prior to saving. Executing same code on Safari on macOS works well, i.

Michaela, could you also attach a screen recording to FB of this bug happening? Sounds like a bug. 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. I've attached it to the radar as well.

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

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. I have verified that the blobs have the mime-type set correctly. 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. 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. 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. If it's not going to happen within, say I'm happy to help though if that will speed things along.

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 If you have a specific use case with the "download" attribute that doesn't work in iOS Thank you for following up.

In contrast, data: URLs work there. Is this on purpose? Both methods work correctly in Safari itself. Thanks for testing! Please file a new bug report for this follow-up issue so we can track it separately. I'm using file saver and download only opens a new tab in iOS This sounds like you are working on a WebKit-based application that needs to perform downloads.