Filesaver.js: Problems saving in iOS Safari

[gawry]

Edit by @eligrey: Please tell Apple how this bug is affecting you in https://bugs.webkit.org/show_bug.cgi?id=102914 if you want this fixed.

Edit by @jimmywarting
The safari bug #102914 has been marked as fixed now

according to the commit position, download attribute is fixed in WebKit v602.1.27.
The latest beta build (Safari Technology Preview) is based on WebKit v602.1.25, and of course doesn't contain this patch, so there's no simple way to test.

In the meantime, if you want to support Safari 7, you'll probably want to use Downloadify (uses Flash, not HTML5).

---

Issues we have had with Safari

• [x] Blob is not supported
  
  This has been solved with Blob.js using BlobBuilder as fallback and then base64 data uri if that are not supported either
• [x] URL.createObjectUrl
  Has been covered by both FileSaver.js and blob.js
  Blob.js overrule createObjectUrl with it's own base64 url constructor only if it's a "fake blob" (i.e not a File or Blob representation) it will use window.URL, fallback to window.webkitURL or use it's own base64 function to create those "fake blobs" data-uri
• [ ] The "can't open blob url" issue (partly supported) - screenshot

            The page you opened redirected you to a page that isn't supported by safari
Safari can't open the page becuse Safari can't be redirected to address that begin with "blob:".

• This is mostly cased by unsupported mime type, Safari do support opening blob url, but only if it's a mimetype that safari can understand like simple plain/text or a common image like image/png.
  
  
  
  • This will result in a new tab from which the user can just hit ⌘+S to save it
  
  
• ATM FileSaver.js looks at the mimetype to see if it is application/octet-stream (wish is commonly used to force saving files from the server)
  If it's then it read the blob as base64 using FileReader to open a data:attachment/file" + base64 url in order to save it.
  
  
  
  • It's not possible to create a blob with attachment/file type directly and open it, then you will get errors like this: Failed to load resource: Frame load interrupted it has to be base64 for some reason...
  
  
  • the resulting filename will be "unknown" when doing this
  
  
• [ ] The blank page error partial supported - (formuly known as "can't open blob url", see above)
  
  This can easily be reproduced by doing:

window.onclick = function(){
    var blob = new Blob(["Hi"], {type: 'application/octet-stream'});
    var url = URL.createObjectURL(url);
    window.open(url);
}

If you replace window.open with location.href = you will get the Failed to load resource: Frame load interrupted and be unable to save the file that is not the case for all mimetype, mimetypes that Safari can display can be opened this way

A little side note here is that window.open only works on trusted events meaning:

• It will only be able to open the url when user interacts with the website like a onclick event (more about isTrusted event here - almost pointless becuse browser support)

I have also found out that the trusted event persist for 1000 ms, so you could do:

window.onclick = function(){
    setTimeout(function(){
        var blob = new Blob(["Hi"], {type: 'application/octet-stream'});
        var url = URL.createObjectURL(url);
        window.open(url);
    }, 950); // Any longer then 1sec will make the window.open blocked again
}

So the conclusion here about safari is

1. download attribute in safari is not supported
2. It will try other means to save the blob by opening a new url
3. If the mimetype can be rendered by safari it will be able to display it in a new tab
4. If the mimetype is application/octet-stream:
   
   4.1 Create a base64 link with FileReader api
   
   4.2 try to open a new tab using window.open + base64 url
   
   4.3 if it was more then 1 sec before the user interaction happened it will use the current page instead
   but that is likely going to fail because (see first example using location.href) Failed to load resource: Frame load interrupted This may still work if the mimetype is not application/octet-stream and the saveAs was not called synchronous
5. Safari don't have anything like msSaveAs()
6. safest way to force the file to be saved is to have a data:attachment/file" + base64 ready and open that link using window.open() when the user interacts with the website (or at least to it under 1 second)
7. when saving it as a attachment filename will be "unknown"

[noway]

Your Blob.js uses native blob constructor in Google Chrome, no?
This is defined by this line:

if (typeof Blob !== "function")

[ggozad]

I can verify that Filesaver does not work with 6.0.2. Safari _does_ have a native Blob constructor.
When Blob.js is not included, a new window opens with a blob: url which safari cannot open.
If Blob.js is included, a data: url opens. However the data seems to be the base64 representation of toString of the datea used to construct the blob. In my case where I construct from an array of bytes, I get [object Uint8Array].

Both Chrome, as well as Firefox (opening in a new window as blob) work as advertised.

[bendavis78]

Does anyone know of a workaround for this?

[marktheunissen]

This doesn't work on Safari. I suggest updating your REAME.md file so that people are aware of the regression.

[eligrey]

As I do not have a Mac, I really have no idea what exactly is causing the issue. It's up to you Mac users to fix this or donate a Mac/MacBook to me.

[eligrey]

Apparently just mentioning an issue in a commit closes the issue. I didn't mean to do that.

[marktheunissen]

Thanks for updating that. Mountain Lion does run in VirtualBox, if you're interested.

http://www.macbreaker.com/2013/01/iatkos-ml2-mountain-lion-virtualbox.html

[eligrey]

I used to run OSX in VirtualBox and updates to VB or OSX broke compatibility every so often, so I'd rather not. The lack of hw acceleration is also pretty important.

If you are not a developer you can pay someone who is and owns a Mac to fix this bug if donating a MacBook to me is too much for you. Frankly, seeing as FileSaver.js is a tool for developers most of you are probably developers and you should have no trouble debugging the issue at hand.

[Keyamoon]

I tried to reproduce and fix this issue but everything works fine for me in Safari 6 on OS X.

[eligrey]

@gawry @noway421 @ggozad @bendavis78 @Buttyx @marktheunissen Are you using Blob.js? Is URL, DOMURL, or webkitURL defined in Safari 6? If not, then I can guess that there is no issue and that everyone here is just neglecting to include Blob.js. The Blob API is not solely the Blob constructor, but also the URL.createObjectURL utility. If a browser does not support _both_ of these things, then it needs Blob.js.

[marktheunissen]

@eligrey I'm using Safari 6, and doing testing on the demo page: http://eligrey.com/demos/FileSaver.js/

When clicking the 'Save' button, a new tab opens with the text in it and the url "data:text/plain..." in the address bar.

[eligrey]

@marktheunissen Thanks. Is URL, DOMURL, or webkitURL defined? If none of those are defined then it seems to be working properly.

[marktheunissen]

[eligrey]

Tell me if this fixes it for you: https://github.com/eligrey/Blob.js/commit/6f36e8aab6cd009790a8266cf3419f7b1c12d1b5

[marktheunissen]

I don't have an implementation of FileSaver anywhere to test this change, sorry. I'll let one of the others chime in, as we have moved to a different solution. Thanks for the help.

[eligrey]

An implementation of FileSaver for testing the change.

[jordanaustin]

I use FileSaver.js on a web application and I have support on mobile Safari and Safari on OS X desktop. As long as you include Blob.js as described in the README it works. Please note that Safari has support for Blob constructor but you cannot navigate to a Blob URI, therefore it has to fallback on a Data URI and the data will open in a new window.

There is an issue in Blob.js when attempting to save large images, but that is unrelated to the bug being reported here.

I think this reported bug should be closed unless someone has a specific demo showing the issue described.

[marktheunissen]

@missing What version of Safari? This bug only exists in Safari 6 as far as we know.

I just tried the implementation as provided by @eligrey above in the 'demo' folder on master, and the bug remains.

[marktheunissen]

@missing Yes, it does open the data: URI in a new tab (as you can see in my screenshot above), but isn't the point of this library to make the browser save the file locally?

The other problem is that you can't provide a default filename in this 'fallback' mode, so the user has to re-type it.

[jordanaustin]

@marktheunissen I have it working on Safari 6.0.5. So on this demo page it doesn't work? http://eligrey.com/demos/FileSaver.js/

[marktheunissen]

Well, it doesn't behave as expected. It does provide a fallback where you get a data: url, and that does show the correct data in the tab. The problem is that it doesn't trigger the browser to automatically download the data, and when a user chooses "Save As" from the File menu, they have to re-type the name of the file that they typed on the first page.

I'm not sure if this can be fixed by any library, it's probably a deficiency in the Safari browser. All I'm saying is that the user experience provided to Safari users is so different to other browsers, that this should be emphasized in the README so that implementers are aware of it.

[eligrey]

@marktheunissen Btw, you may be getting a cached version of the page as I have the site configured with pretty aggressive caching, so try clearing your cache before trying again.

and when a user chooses "Save As" from the File menu, they have to re-type the name of the file that they typed on the first page

Safari does not support saving filenames, only Chrome and Firefox (and possibly the new Opera) do at this time.

[jordanaustin]

@marktheunissen I understand the frustrations, I've been fighting with Safari and downloading data for a long time as well. The sad fact is that Safari hasn't implemented any of the other fallbacks that can be used here. This library first tries to use the W3C version of FileSaver and then goes to the anchor tag download attribute and finally to data URI. Mobile Safari on iOS handles data URIs in a special way however, if you mimetype it with text/csv for example when it pops you into the new window you'll get the iOS "Open In" bar which lets you open in other applications on your device that have registered as opening csv.

In my opinion Safari hasn't implemented these other filesystem apis because they don't expose the filesystem to users on iOS. Maybe we can update the README to better reflect that.

As of right now filenames work on the follow: Chrome, Firefox 20+ & Opera NEXT (new version of the Blink rendering engine).

[marktheunissen]

Sure thing. I'm not desperate for this bug to be solved in Filesaver, because we aren't using the library. I'm just helping out with testing.

I guess the point is that most people would read the compatibility charts on the README file and expect that the user experience is the same across all browsers - that's the point of a shim like this.

To have a very different user experience for one browser could be a deal breaker for a developer, and it sucks to have to go and test the library before discovering that on Safari it isn't consistent.

[eligrey]

@missing @marktheunissen I updated the readme to make it clear which browsers support saving filenames and which don't. As it stands, IE10, Firefox, Chrome, and Opera Next support it.

[jordanaustin]

@eligrey thanks, was just about to say IE10 too.

[badray]

I got issue with using FileSaver on Safari 6.0.5 on OSX. Including or not the Blob.js does not change nothing. Every time it just redirects me to:
blob:http://myhost/{blob_id}
like:

Code sample in coffeescript:

file_parts = []
file_parts.append([1,2,3,4])
file_parts.append([5,6,7,8])
blob = new Blob(file_parts, {type: "application/octet-stream"})
downloaded_file_name = 'file_name'
saveAs(blob, downloaded_file_name)

Looking further for any patches. I also can help with testing it on OSX ;).

[jordanaustin]

@badray what about if you try the demo found here: http://eligrey.com/demos/FileSaver.js/

[badray]

@missing i forgot to tell that i tried it :)

Every save button on demo opens a new window instead with generated content opened. Url is always like: "data:{data_mime};charset={charset};base64,{encoded data in base64}"

For example:

[jordanaustin]

@badray if you look through this thread of comments you'll see that basically the only thing Safari can handle is putting the content into a new window as a dataURL. From that point you can right click and save the data. This is a huge shortcoming on Safari's side. See the comments for more details on it.

On Safari for iOS however, this is definitely the way you want it to work because iOS uses "Open In" rather than exposing the file system. So what happens if you mimetype a document as a CSV for example when you call saveAs (using blob.js) you'll be popped into a new window and you'll get a table of your data, however at the top you'll also get an "Open In" bar which allows any application that has registered to handle CSV to be displayed. You can then open the CSV in whichever app you choose that can handle CSV.

[badray]

@missing ok i understand everything, but this doesn't change the fact that saving blob with some byte stream with mime type application/octet-stream doesn't work on Safari in any way. I think Safari should be marked as 'partialy supported'. I wondering if it is possible to write some flash fallback to achieve this thing.

[Merg1255]

You can check that with a VM on Mac Safari 6.0.5, it also says that blob urls are not able to display on the page. I hope someone will provide a patch on this. :)

[nradisch]

I'm hearing about the same problem @badray is having. I just get a blob:http..... error with no way to save the data. A workaround, even a lame one, would be nice.

[Sakari369]

Hey all. I noticed the same thing, that when testing out the Safari image saving, it tries to open up a blob://file URL and this doesn't work. This with Safari Version 6.0.5 on Mac Os X 10.8.

Now, I tested the Demo Page (http://eligrey.com/demos/FileSaver.js/) on same Safari, and here the image saving correctly falls back to the base64 URI encoding, and you see the image open up on a new tab.

I compared the FileSaver.js, canvas-toBlob.js and Blob.js files on the Demo page to the most recent versions found in github, and figured out that the error is caused by changes in most recent version of Blob.js, updating the two other files didn't affect the image saving.

I copied these two lines:

if (typeof Blob !== "function" || typeof URL === "undefined")
if (typeof Blob === "function" && typeof webkitURL !== "undefined") var URL = webkitURL;

From the previous version that can be found on the demopage, and replaced these two lines:

if (!(typeof Blob === "function" || typeof Blob === "object") || typeof URL === "undefined")
if ((typeof Blob === "function" || typeof Blob === "object") && typeof webkitURL !== "undefined") self.URL = webkitURL;

In the newest version of Blob.js with the lines from above.

And now the image saving works correctly in Safari 6 :)

Also tested this solution working on Safari 5.10.1 running on Mac Os X 10.6.8. So with this solution it seems to work in Safari, both 5 & 6.

Now, I also tested the newest version of Blob.js on Safari 5.10.1, and here the newest version works correctly, falls back to base64 URI encoding. But with Safari 6 it comes up with the blob:// error .. the above solution fixes this for both.

Maybe Safari 5 and Safari 6 are doing something differently when it comes to Blob.js detecting the support, I didn't investigate more on that, all I know that by doing the above it works in all browsers I've tested: Firefox 24, Chrome 30.0.1599.101, Safari 6.0.5 and Safari 5.10.1.

Didn't create a patch for this, but maybe @eligrey you might want to downgrade the support detection to the old one ?

[eligrey]

I'll leave any code changing decisions to people with Safari 6 (i.e. not me). If any of you feel that you have sufficiently solved this issue, please submit a pullreq and I'll look it over. I will push the latest copies of FileSaver.js, canvas-toBlob.js, and Blob.js to the demo on eligrey.com once I've accepted a pullreq.

[Sakari369]

Seems like they've fixed something related to Blob handling in Safari 6.1, that came to Software Update couple of weeks ago. So, the code that is now at the repository works with Safari 6.1, but not with 6.0.5. Maybe 6.0.5 was actually broken.

Works also with Safari 5.10.1, it falls back correctly to the dataURI encoding.
Btw. I'm using your code with http://GeoKone.NET, thanks for making canvas-toBlob.js, Blob.js and FileSaver.js @eligrey !! :)

[Merg1255]

Someone should confirm this working on Safari 6.1 and 7 on the new system.

[eligrey]

@inDigiNeous GeoKone looks neat. I'm glad to be such a help :)

[eligrey]

@inDigiNeous and @Merg1255 are you getting your filenames saved?

[gawry]

It doesn't save automatically like on Chrome but at least now opens the file in a new tab allowing me to cmd+s to save the file.

[ggozad]

Seems like Safari 7.0 is b0rken again.... You might want to reopen this. For the record:
Testing using the example in the README, there is no file nor data:URI. Inclusion of blob.js does not make a difference.

[Merg1255]

Yes, this must be revisited for Safari 7, for anyone who has a system with this configuration.

[ggozad]

For the record:
I inspected the blobs generated and they are correct. So the broken blob implementation of 6 is fixed. However saveAs does neither save nor open a data:URI tab.

[gawry]

It seems to work for me on Safari 7. Here is the data uri generated.

data:text/plain;charset=UTF-8;base64,dGVzdA==

On Fri, Nov 8, 2013 at 3:02 PM, Yiorgis Gozadinos
[email protected]:

For the record:
I inspected the blobs generated and they are correct. So the broken blob
implementation of 6 is fixed. However saveAs does neither save nor open a
data:URI tab.

—
Reply to this email directly or view it on GitHubhttps://github.com/eligrey/FileSaver.js/issues/12#issuecomment-28078900
.

• Gustavo Gawryszewski [email protected] [email protected] +55
  21 4106-0075 | [phone] www.tactio.com.br
  http://www.tactio.com.br/ *

As informações existentes nessa mensagem e nos arquivos anexados são para
uso restrito, sendo seu sigilo protegido por lei. Caso não seja
destinatário, saiba que leitura, divulgação ou cópia são proibidas. Favor
apagar as informações e notificar o remetente. O uso impróprio será tratado
conforme as normas da empresa e a legislação em vigor.

Antes de imprimir este e-mail/documento, pense em seu compromisso com o
Meio Ambiente

[Merg1255]

You must see the JS messages. If the blob is the same, then having a data URL with this blob file should normally work. More feedback could be nice.

[ggozad]

Had some time to further look into this. Safari 7 _works_ opening a blob. This however requires the user to disable blocking pop-ups in Safari settings, which is the default behavior.

[secumundo]

I might be completely stupid, but Safari 7 doesn't play nice with blobs. A

<a href="blob:https://host.name/fbe50e07-ac25-41b8-a371-5f2d5d477b6a" download="Whatever" target="_parent">

results in Frame Load Interrupted. Works without problems in FF and Chrome. Additionally, the Safari generated blobURL is misleading anyway, as it points to the remote host, not to the local computer where it is actually stored.

[rokkit]

Safari fail with Failed to load resource error, when blob's content-type is set to application/octet-stream With text/plain it will open up a new tab, but it not work for downloading zip and other extentions.

[eligrey]

Just another reminder: I do not have a Mac so if you Mac users want this fixed you must handle this yourself and submit pullreqs if you figure out how to fix this for Safari 7.

[Merg1255]

It would be great if someone with a Mac submitted a pull request here.

[ggozad]

I am not certain what is the problem that @rokkit or @secumundo have with blobs and 7. It seems to work fine for me, albeit the file is not downloaded, just the blob opened in a tab. This is certainly annoying but not something fixable.

[eligrey]

@ggozad That definitely _sounds_ fixable to me by forcing mime types or something. Without a Mac this is only speculation though.

[lucidtech]

reviving an older project using fs and blob... I am having similar issues in Safari7. I recognize this isn't advancing the topic... @ggozad I get the tab open - but nothing in it. Will see if I can try @eligrey suggestion around mime types

[jdragojevic]

Not sure if this is helpful or noise, but we are implementing this in amara, and here's what I see with Safari on mavericks.

[gabrielstuff]

Seems the issue is related to webkitRequestFileSystem. Don't you think ? using a url in the form of 'data:Application/octet-stream,' + encodeURIComponent(dataToDownload);

I've been able to get safari to open new window and download a file but the new safari 7 behavior which avoid pop up by default is a nightmare.
Maybe a solution with a fallback to "flash button" would be the solution ...

Thanks anyway for the amazing work.

[ssorallen]

Safari 7 implements the Blob interface, but it does not handle opening blob: URLs like a couple other posters have pointed out. Since window.Blob exists, the fake createObjectURL from Blob.js isn't used to create data: URLs in place of blob: ones.

Any ideas on how to feature detect the Safari 7 environment to let Blob.js fall back to data URLs? It currently falls under the second feature check of Blob.js and assumes the URLs generated by URL.createObjectURL will be handled by the browser.

[eligrey]

Thanks for the clarification @ssorallen. I guess the only way to test if blob: URLs work is to insert a script with an src of

URL.createObjectURL(new Blob(["blob_urls_work()"], {type:"application/javascript"}))

Can anyone think of a synchronous idea? The fix I mentioned would require waiting for that script to load, so you can't use Blob APIs immediately after Blob.js loads.

[Merg1255]

Why not just check for the browser that needs to have a patch?..

[ssorallen]

@Merg1255 I was trying to avoid user agent string sniffing and instead find a way to detect that the browser can't handle opening blob: URLs.

[eligrey]

@ssorallen could you elaborate on blob: restrictions? Is it only that you can't navigate directly to them, or are the restrictions similar to data: URIs in IE where they can only be used for <img> etc.?

[ssorallen]

URLs generated by Safari 7's URL.createObjectURL don't follow the blob URL scheme standard and might be usable as a Safari 7 identifier. That is assuming that when Blob URLs are fixed in the future, the generated URLs would follow the standard.

Chrome (on OS X) contains unescaped slashes but still works:

blob:http%3A//localhost%3A8000/f9e751c8-ec01-4b0b-a8fd-651bb2604bae

Firefox (on OS X):

blob:83d5e571-e3ea-514f-aad6-cf3c8f27bd91

Safari (on OS X) contains unescaped colons and slashes:

blob:http://localhost:8000/ca7b637d-5ead-4d95-bbcb-341234b6ca18

IE10:

blob:DC9D54F7-762C-BA47-B5BC-2B2C5805EE37

@eligrey I haven't been able to figure out even an async way to test that a Blob URL is supported. I tried setting Image.src, but it doesn't fire a load event in any browser.

[ssorallen]

@eligrey Safari 7 simply does nothing with URLs starting with blob:. I get the same screen @jdragojevic posted that says "Safari can't be redirected to addresses that begin with 'blob:'."

[eligrey]

@ssorallen Thanks, I will probably use a check for unescaped colons or just use a Safari user agent check for a synchronous fix. Also, you're mentioning image.src="blob:..." not triggering a load event in any browser: make sure you create the event listener for the load event _before_ setting the image src.

[ssorallen]

Well this is annoying. Safari 7 supports blob: URLs as the src attribute of script tags. This prints "Blob URLs supported" in Safari 7:

var blob = new Blob(["test()"], {type: "application/javascript"});
window.test = function() { console.log("Blob URLs supported") };
var script = document.createElement("script");
script.src = URL.createObjectURL(blob);
document.body.appendChild(script);

[ssorallen]

Aha, this example of loading an SVG as a blob from Mozilla does the trick. Safari 7 prints "unsupported". Chrome, Firefox, and IE10 print "SUPPORT".

var svg = new Blob(
  ["<svg xmlns='http://www.w3.org/2000/svg'></svg>"],
  {type: "image/svg+xml;charset=utf-8"}
);
var img = new Image();
img.onload = function() { console.log("SUPPORT"); };
img.onerror = function() { console.log("unsupported"); };
img.src = URL.createObjectURL(svg);;

EDIT: It looks like this is due to Safari not supporting SVGs, not Blob URLs.
EDIT 2: Safari supports SVGs just fine. This might be a valid test.

[Merg1255]

So, instead of looking for blob support in general, since Safari is the only one that has some issues, lets try to solve it by detecting the browser.

[ssorallen]

@secumundo There's a decent fallback to blob URLs for some MIME types: base64-encoded data: URLs. The point is to detect browsers that don't support blob URLs to offer a reasonable, albeit diminished, fallback. "Get a decent browser" warning is effectively what you get now, and it's a crummy user experience.

@Merg1255 If this library detects Safari 7 and assumes it's broken, then this library will have to update again when Safari 7 fixes blob: URLs. Detecting blob: URL support prevents this library from breaking potentially working browsers in the future.

@eligrey This seems to be a valid test: https://github.com/ssorallen/blob-feature-check I used Browserstack to test Safari 6 and Safari 6.1, and it looks like neither version supports blob.

[eligrey]

@ssorallen What result does Safari 7 give?

[ssorallen]

Safari 7 fails the test. You can open the test page using browserstack.com.
That's where I tested Safari 6 and 6.1 as well.

Am Sonntag, 9. Februar 2014 schrieb Eli Grey :

@ssorallen https://github.com/ssorallen What result does Safari 7 give?

Reply to this email directly or view it on GitHubhttps://github.com/eligrey/FileSaver.js/issues/12#issuecomment-34588428
.

Ross Allen

[secumundo]

@ssorallen be it as it may, we can't fall back to prehistoric work-arounds as we move gigabytes of data through xhr and blob-urls. If apple can't provide a decent browser, time to change to Firefox.

[fungiboletus]

@secumundo Safari is the only one available browser on iOs. Personally, I prefer a «prehistoric» workaround than broken feature on the most popular tablets.

[thbwd]

Okay, I'm too having problems in Safari 7(.0.1). They are exactly like above but additionally there's something very strange:
Every time when I tried to download something (using saveAs()) and reload the page Safari prints out:
Failed to load resource: WebKit encountered an internal error on all scripts and stylesheets and destroys all cookies and local storage data.
Does anybody else has this problem? And does somebody know how to solve it.

[jordanaustin]

One thing to understand is that even is Safari supports blob URLs, they haven't implemented any modern (experimental) API support for either the HTML download attribute (http://www.w3.org/html/wg/drafts/html/master/links.html#downloading-resources) or something like IE implemented with the msSaveBlob method.

To my knowledge the only way to force Safari (Desktop) into downloading a file is to use the old application/octet-stream trick. But this is far from ideal. It doesn't give you a file extension and it doesn't give you the opportunity to name the file.

On Safari for iOS there is a little hope, but you have to change your thinking about "saving" a bit. Like Safari for the desktop you don't have the download attribute or some magic saveBlob method. But you do have the iOS open-in bar. Basically you can use window.open() or add the dataURL to an anchor href and if it's a mime-type that other applications on your device are registered to open then the open-in bar will appear and give you the ability to open/save that file in that application. For example Dropbox and Google Drive are both registered for practically every mime-type so something like text/csv will give you the open-in bar and you can then import it into Dropbox or whatever. Is this really "saving"? No, not really, but this is nearly identical to how native apps work on iOS because you don't have a normal filesystem to browse. The biggest issue I've found with this method is that images don't appear to ever give you an open in bar.

Basically we need Safari to implement something like the download attribute so we can handle saving blobs the same all the other browsers do.

[udondan]

I try to save a client side generated Zip file and I am experiencing the same as described above by @idmean.

Safari is randomly either showing the blob content OR failing with an error Failed to load resource: Das Laden des Frames wurde unterbrochen, which is german and means something like "loading of frame was interrupted". When that error appears, afterwards all requests to other files fail with Failed to load resource: WebKit encountered an internal error. Which means, this not only not works in Safari but as well breaks the whole application.

I tried to debug this and find a solution for hours with my knowledge (=none) about Blobs and the recent kickass features available. Nothing.

I don't see how this can be fixed without Safari fixing it on their side. Now I'll disable downloading in my app completely for browsers which do not support Blob url's, using above test posted by @ssorallen.

Are there any workarounds available? I can only see:

• Forwarding the content base64 encoded to the server and respond with a downloadable file. Ugly data roundtrip plus potential security issue.
• Use Downloadify. Flash sucks and this would require the user to actually click on a Flash button. You can't trigger the save-action with JS.
• Generate the file on the server in the first place. Yay!

All of that sucks. How are you others doing it, who have this problem?

[lucidtech]

i pop an error message for safari and point users to chrome/ff/ie10/11

downloadify wont work either due to the security restriction in safari.

server side file mirror seems the only alternative to blocking unless/until safari changes

C.

On May 14, 2014, at 3:04 AM, udondan [email protected] wrote:

I try to save a client side generated Zip file and I am experiencing the same as described above by @idmean.

Safari is randomly either showing the blob content OR failing with an error Failed to load resource: Das Laden des Frames wurde unterbrochen, which is german and means something like "loading of frame was interrupted". When that error appears, afterwards all requests to other files fail with Failed to load resource: WebKit encountered an internal error. Which means, this not only not works in Safari but as well breaks the whole application.

I tried to debug this and find a solution for hours with my knowledge (=none) about Blobs and the recent kickass features available. Nothing.

I don't see how this can be fixed without Safari fixing it on their side. Now I'll disable downloading in my app completely for browsers which do not support Blob url's, using above test posted by @ssorallen.

Are there any workarounds available? I can only see:

Forwarding the content base64 encoded to the server and respond with a downloadable file. Ugly data roundtrip plus potential security issue.
Use Downloadify. Flash sucks and this would require the user to actually click on a Flash button. You can't trigger the save-action with JS.
Generate the file on the server in the first place. Yay!
All of that sucks. How are you others doing it, who have this problem?

—
Reply to this email directly or view it on GitHub.

[udondan]

Downloadify seems to work in Safari. Tested it on http://starter.pixelgraphics.us but as said, you will need to click an element in the Flash movie to be able to save a file to the disk. https://github.com/dcneiner/Downloadify/issues/6 So it would theoretically be possible to lay that Flash button over my save button. But I'm not considering this as a real option. I really want to keep my sites free of any Flash.

[thbwd]

@udondan This crash of WebKit was so annoying that I decided to show up a box with an iframe to Safari users. In this then I set the src of the iframe to something like "data:application/octet-stream;base64," + data. Most of times this worked well, and Safari just downloaded the file (if it was a zip file, pictures had to be saved manually). But of course this is not a good solution and in this project the files were just around 2 MB, so I don't what happens if you try to display a 500 MB zip file in an iframe.

[lucidtech]

so... thats odd because on my Safari it doesn't work at all.

C.

On May 14, 2014, at 9:14 AM, udondan [email protected] wrote:

Downloadify seems to work in Safari. Tested it on http://starter.pixelgraphics.us but as said, you will need to click an element in the Flash movie to be able to save a file to the disk. dcneiner/Downloadify#6 So it would theoretically be possible to lay that Flash button over my save button. But I'm not considering this as a real option. I really want to keep my sites free of any Flash.

—
Reply to this email directly or view it on GitHub.

[eligrey]

I'm probably capable of fixing this issue for you people, if any of you are willing to make the necessary sacrifice.

[lucidtech]

i'll stump up $50 towards a mac mini. just need another 11 folks :-/

C.

On May 15, 2014, at 1:36 PM, Eli Grey [email protected] wrote:

I'm probably capable of fixing this issue for you people, if any of you are willing to make the necessary sacrifice.

—
Reply to this email directly or view it on GitHub.

[eligrey]

If you have a spare macbook pro or air you can email me if you want to ship it to me.

[udondan]

I guess that's unlikely. :) Did you think about registering with https://pledgie.com/ and/or https://www.gittip.com/ If every of the 83 watchers of this project would donate just $15 you'd have your new MB Pro.

[udondan]

@idmean Thanks for the hint with the Iframe! This actually works in my case as well. My zips are max 100kb and for me it works in 100% of the cases.

I created a fork based on that info and the ObjectUrl test above: https://github.com/udondan/FileSaver.js This works in my specific case where I only have to serve small ZIP files, no images etc. I did not test it with other files than ZIP. Of course this will download a file in Safari with the name "Unknown", which is still not a solution, but better than opening a page with gibberish or crashing. To instruct the user he has to rename the ZIP file I implemented a callback. You can use it like that:

saveAs(data, "filename.zip", function(filename) {
  alert("Please rename to " + filename + " due to bad browser.");
});

There is a condition to only use this fallback if the filesize is max 2MB, as this was reported by @idmean as working _most of times_.

Now the funny thing is, this still throws the error Failed to load resource: Loading of frame was interrupted every time you download a file. Additionally it shows the whole base64 string in the console, which can get funny if you have really big files. ;) But no crash like described above with the ObjectUrl.

@eligrey Let me know if I should send a pull request. As said, it works in my specific case for ZIP's. And I did not test older Safari versions. (since that's not possible unless you have 1 Mac for every version...) As well I did not understand too much of the original code. For instance I did not see where there is the data-uri fallback that some here were talking about. So I implemented my own. So even if it works, it might not be the best solution. _If_ there is this data-uri fallback, the callback maybe should be added there as well for consistent behavior in older Firefox and Opera versions.

The fork as well gives Meteor support. Meteor puts every file inside a function(){} container. Therefore saveAs is not available outside of that function. Added this since I need it for clean implementation in my package zipzap

[secumundo]

This is really an issue that needs to be solved by Apple. All current versions of major browsers support the blob-download directly. I need to be able to download arbitrary sizes, no problem blob-downloading 500 Megs with Firefox or Chrome. Even IE has (it's own) solution.

[udondan]

Just to complete my above attempt. The callback is gone and I removed the feature check, as it hit on other Browsers which actually have no problem opening the Blob. It now is a simple check for Safari 7 in UA.

I updated my fork, the zipzap package and set up a demo: https://zipzap.meteor.com/

@idmean I did some further testing with Safari and I have 100% success with saving files up to 150MB in Safari on iOS. It just takes ages. About 1~2 seconds per MB, so about 5 minutes for saving 150MB. In a case like that I'd prefer downloading that data from the server.

That said, I'm dropping this package now. I need something that works cross-browser. The _Unknown_ in one major browser is no final solution for me and I doubt there is a fix. As well other browsers with big marketshare are important to me. I could imagine it would be possible to hack something together for IE<10 by generating a MHTML with javascript and then simply triggering a click on the linked zip. Problem is the file size support, I think limited to 32kb of 64KB. As well I discovered it doesn't work for one single Browser on iOS. The original demo seems to work, but actually not saving anything but opening the text/image file, which doesn't seem to be the intend of the package. (=save) So it has very different behavior depending on the file type, which should be prominently described in the readme.

I invested like a week after work into this now and this is as far as I am willing to go. There's a lot of work to be done before this can be used cross-browser. Or wait some years until we have better browser support.

I'm switching back to server side generated files now.

[eligrey]

@udondan As I've stated before, I can try to fix this issue on my own. It'll only cost you $600 (I accept PayPal and check) in order for me to purchase a Mac mini (the cheapest Mac OS X device).

[udondan]

No, it is not.

• I am pretty sure you won't be able to fix it.
• I am working on a non-profit project. Nothing I do is for the purpose of making money. Therefore I'm not paying you a wealth for a tiny feature I already dropped. I suggested you to fund raise it. You didn't even bother to respond.
• I changed my mind, I wouldn't even pay you 1 bug, because you are the rudest and most brazen guy I have ever seen here on github. Closing tickets with "you are even too lazy to...", "go to stackoverflow" and repeatedly asking everyone who opens an issue to pay you an iPhone or Mac... that's simply bad manners.

So the only thing you get from me is a big GFYS. You asked for it.

[eligrey]

I'm not going to spend $600 out of my own pocket to fix a bug in the software I'm giving away for free.

Closing tickets

Look at this ticket. Does it say closed to you? (Hint: it's not) I close tickets that ask for help using my software because this is an issue tracker for problems with my software. If you want free programming support, StackOverflow is a very nice site for that. If you want programming support from me, I selectively offer paid support wrt email inquiries.

Try and ask for programming support to make a Chrome app on http://crbug.com/new and tell me how helpful they are. Issue trackers are not general help forums.

[eligrey]

Does the latest update to Blob.js resolve the issue for any of you?

[rgravina]

However saveAs does neither save nor open a data:URI tab.

I'm seeing this also in Safari 7.0.4 (9537.76.4).

My code is similar to:

blob = new Blob([someJpegData], {type: 'image/jpeg'})
saveAs(blob, 'the-image.jpg')

As @ggozad mentioned, it is due to "Block popup windows" being ON by default in Safari (I rarely use Safari, so never needed to turn it on). When unchecked, it opens the file in a new tab. HOWEVER, the FileSaver.js demo does open it in a new tab, even when popup windows are blocked. I'm not sure why.

Does the latest update to Blob.js resolve the issue for any of you?

Unfortunately, no. It appears that the behaviour is the same with or without Blob.js

[eligrey]

@rgravina if the demo is working in Safari 7 but your code isn't working in Safari 7, it sounds like you're running saveAs outside of an event handler for user interaction. User interaction (e.g. click on something, resulting in a popup) is usually allowed by popup blockers to make popups.

[ayoubnejm]

Hello, any idea how can i save a PDF file in IE9 using FileSaver, thank's.

[cphill02]

ayoubnejm makes me sad :-1:

[ayoubnejm]

cphill02 why ??

[eligrey]

@ayoubnejm Saving an application/pdf-type file with JavaScript is not possible in IE<10 (text/plain and text/html _are_ possible though). You probably want to use Downloadify or some other Flash-based tool.

[ayoubnejm]

@cphill02 Thank's

[theo-armour]

My two cents, given some of the recent comments:

@eligrey Eli is awesome.

If Eli, creates a Paypal link somewhere I will contribute to the cause.

[theo-armour]

[email protected] does not seem to be registered with PayPal...

On Sat, May 31, 2014 at 2:12 PM, Eli Grey [email protected] wrote:

@theo-armour https://github.com/theo-armour PayPal donations can be
sent to [email protected]

—
Reply to this email directly or view it on GitHub
https://github.com/eligrey/FileSaver.js/issues/12#issuecomment-44759867.

[theo-armour]

A small thank you has been sent.

I hope it gets to you.

PayPal reports that the money went to a person with a name that is not at
all similar to 'eligrey'

On Sat, May 31, 2014 at 2:42 PM, Eli Grey [email protected] wrote:

Oh, yeah sorry it's actually [email protected]. I misremembered that.

—
Reply to this email directly or view it on GitHub
https://github.com/eligrey/FileSaver.js/issues/12#issuecomment-44760484.

[eligrey]

Yeah, that's fine. The money will still get to me.

[rgravina]

it sounds like you're running saveAs outside of an event handler for user interaction.

@eligrey You were right about this! Thanks, calling from the event handler works - however the blob is returned by an XMLHttpRequest, so it is fired from callback. But I should be able to figure this out. Thanks again!

[halo]

Some people on this issue report that Blobs work on Safari 7, others say it doesn't, some say it works only sometimes and some say it only works with certain content types.

This is what I have experienced the following with regard to Blobs in Safari 7.0.2.

• I create a bunch of different Blobs (various mimes, up to dozens of MB in size)
• I create URLs for each of those using window.URL.createObjectURL
• I can show images, videos, and audio files inline, using these blob:-URLs
• Even opening them in new Tabs works perfectly fine (i.e. PDF, video, audio, plaintext)

BUT

As soon as I attempt to open a Blob in a new Tab, which has the content type application/octet-stream or application/zip, it won't open PLUS all the other URLs I created before immediately stop working! I just get the famous "The page you opened .. is not supported by Safari" page we already saw a screenshot of. Just as if the entire Blob memory had disappeared.

This is the only thing I can consistently reproduce. I don't know whether it's a bug in Safari or a security feature (albeit a weird one). But with this information it should at least be possible to create a repeatable test case. Can anyone confirm this or am I nuts? :)

[eligrey]

Thanks for the clarification @halo. I'm going to update the readme with your information. As for other users: Participating in WebKit bug 102914 may help get the issue completely addressed and fixed.

[halo]

Thanks, I posted a comment there. Note that the link you sent is for the cross-platform Webkit _rendering engine_, which is used by the _user agents_ Chrome and Safari. Google has, on top of that, implemented the download attribute in a custom way for Chrome. Apple has not implemented something custom for Safari. Webkit simply doesn't have it.

I created a jsfiddle test case for what I experienced. I verified it on two different MacBooks, one with Safari 7.0.1 on Mac OS 10.9.1 and one with 7.0.2 on Mac OS 10.9.2. I also filed an Apple Bug Report for Safari. It would be cool if someone could verify the jsfiddle.

I'm not using FileSaver (yet...), but what I do to prevent this bug is that I check the content type of the Blob urls and see if they are "normal enough" to be opened by Safari (most files are images, videos, audio or plaintext anyway). In that case I create the link, otherwise I don't and tell the end-user "dude, your Safari cannot open this file type at all"

[lpand]

I’ve got OSX 10.9.2 and Safari 7.0.3 and the behavior is exactly what described in the fiddle (tested it).

Thanks @halo and @eligrey

[ttencate]

The fiddle is still reproducible on Safari 7.0.5, OSX 10.9.4.

[ogonkov]

Safari 7.0.5 (9537.77.4)

Have the same issue. When i attempt to save text Safari just opens new tab with text. Same with image - it's just opens in new tab, but not prompts to save it.

[Merg1255]

Has anyone filed an issue for this browser? Would be nice to have an update.

[halo]

I filed a bug report for Safari at bugreport.apple.com on 2014-06-28 (over a month ago) with ticket ID 17495855 (those are not public, so you can unfortunately not look up the status). I described the problem, provided steps to reproduce, affected versions, etc.

No response yet at all. Still open and unranked. (To be honest, I doubt anybody will look at it).

EDIT: Maybe go ahead and post one yourself as well? Who knows, the more the better :)

[ogonkov]

What the problem with Safari in short?

[halo]

• There is no functionality to download a Blob URL
• If you open a Blob URL which is not a supported data-type, Safari freaks out

[Merg1255]

Hm, it seems like the only way to get it notices is to spread the bug report on places where devs will notice, ie HN.

[nvcken]

@eligrey
I just make test on safari 7, it do not work ?
Has any solution?

[bitomule]

I'm having the same problem. Any fix for this?

[puppeteer701]

using Safari 7.0.6, bug still present

saveAs(new Blob([s2ab(wbout)], {type: "application/octet-stream"}), "test.xlsx")

[Disorrder]

same bug in safari.
Demo page works well, but there are 2013 year version. I have new one, but even "Hello, world" doesn't work (iPad 4, MacOSX)
var blob = new Blob(["Hello, world!"], {type: "text/plain;charset=utf-8"});
saveAs(blob, "hello world.txt");

[rscardinho]

Hey guys. This code is downloading the file:

var downloadLink = document.createElement('a');
downloadLink.setAttribute('href', 'data:application/octet;charset=utf-8,' + encodeURIComponent(fileURL));
downloadLink.setAttribute('download', fileName);

var clk = document.createEvent("MouseEvent");
clk.initEvent("click", true, true);
downloadLink.dispatchEvent(clk);
document.body.appendChild(downloadLink);
downloadLink.dispatchEvent(clk);

BUT in the console logs this message: "Failed to load resource: Frame load interrupted"

I'm on Safari 8

[itbalaji315]

Hi rscardinho but still its open without the file name and extension

[itbalaji315]

Heyy guys anyone help me i want to download a file to csv from when i click the hyperlink.

but it should work with safari browser

[itbalaji315]

Please help

[mmjr]

Anything new on this issue? we have opened a bug apple bugreport.
no response...

[t2n]

Downloading blobs doesn't seem to work on OSX Safari 8.0.2. I can't think of any other way around than to upload locally created file and download it the old way... Or block users from that feature on Safari browser telling them to use Chrome or Firefox to export things. Any thoughts on this?

[devinivy]

Continues to be a problem. Just looking for a reasonable workaround.

[AshesOfOwls]

:+1:

[devinivy]

Downloads typically initiate from some user click. The workaround for safari is to use that click. Basically, add an event handler to an anchor tag. If you can synchronously change the href in time during the event handler to a blob URL, then you're all set. It doesn't exactly cater to every use-case, but it works.

[halo]

@devinivy Interesting, could you provide a jsfiddle, please?

[devinivy]

Here! http://jsfiddle.net/0ts5y7f3/3/
It doesn't work well with application/octet-stream, per your jsfiddle above. But it does allow you to open any attachment in a new window, which I am otherwise completely unable to do with Safari 8.

[lpgeiger]

OSX Safari 8.04 the issue persists for .xlsx files using octet-stream.

[atoftegaard]

Can confirm this issue persists for Safari 8.0.6, using text/plain

[andreiho]

Issue persists in Safari 8.0.8 (10600.8.9), using "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet".

[antelle]

So far, an attempt to download a file as octet-stream results in error in Safari 9 as well.
I have found a workaround to download binary files _without opening as plaintext_ in Safari and checked it in Safari 7, 8 and 9.
I have submitted a pull request #175 with workaround for safari.
There's a limitation: you cannot change downloaded file name (it will be 'Unknown'). But it downloads the file with correct content in Safari, without opening it for view.

[viral2010]

Hi,

I am not able to save file in IE 10. Version # -10.0.9200. When i try to save file from this url - http://eligrey.com/demos/FileSaver.js/, it is giving me same error. I have attached file which i get when i try to save the file and the file is not saved.

[assadtony]

Any news on this? Still unable to download XLSX files in Safari.
@andreiho @keyscores, did you get to a workaround to download XLSX files?
Thanks :)

[jack-fdrv]

With Safari and var file = new Blob([data], { type: 'application/octet-stream' }); it autosave file but the name is 'Unknown' instead name that I have specified.

[ciscohsieh]

When I tried using { type: 'application/octet-stream' }, I see "Failed to load resource: Frame load interrupted" in the developer tool console.

[agairing]

The bug "https://bugs.webkit.org/show_bug.cgi?id=102914" seems now to be fixed. Can anybody assess if the bugfix solves the problem with downloads in Safari - or do we have to wait until the new Safari version is available?

[antelle]

@agairing according to the commit position, this is fixed in WebKit v602.1.27.
The latest beta build (Safari Technology Preview) is based on WebKit v602.1.25, and of course doesn't contain this patch, so there's no simple way to test.
I've just downloaded WebKit Nightly rev.199584, v602.1.29 and it doesn't work (I tested only the download attribute itself, not FileSaver.js).
btw, the feature is still marked as in development, so I assume it's ok that currently it is still broken.

[Rankel]

Woow i see some good progress in this issue with Webkit, i hope to see this fixed soon in stable versions of ios!

[eddiefletchernz]

The latest version of Webkit NIghtlies now supports , however there seems to be a bug with FileSaver.js that is stopping the click event being despatched.

https://github.com/eligrey/FileSaver.js/issues/268

[WuglyakBolgoink]

If the mimetype can be rendered by safari it will be able to display it in a new tab

we have some problem with latest Safari-Browser version (mobile + desktop). If I click first time -> image/pdf will be open in same tab, if I click again -> it open a new tab. Sometimes it open new tab from first time... Is it possible to say "open file always in a new tab"?

Mimetypes: "image/png" or "image/jpeg" have same effect...

Thank you for your help!

[nepaul]

still not work on macOS Sierra Safari Version 10.0.1 (12602.2.14.0.7)!

[petrunov]

Is there even a solution to this issue? Simply changing the mime type is not working for me.

[nadelicious]

not working in safari version Version 10.0.1 (11602.2.14.0.7)

[fsinisi90]

Not working right now on Safari 10. It would be nice to get this information on the presentation page...

[radek-anuszewski]

I also have this problem. I download file from Angular service:

return $http
        .get(baseUrl + '/downloadReport', {
            responseType: 'arraybuffer',
            params: {
                //some params
            },
        })
        .then(DownloadFileService.downloadExcelFile);

And then inside DownloadFileService:

function downloadExcelFile (response) {
    _downloadFile(response.data, _getFileName(response), DOWNLOAD_FILE.OLDER_EXCEL);
}

function _getFileName (response) {
    return response.headers('Filename');
}

function _downloadFile (fileData, fileName, fileType) {
    FileSaver.saveAs(new $window.Blob([fileData], {type: fileType}), fileName);
}

But in console I got blob:http error. File type is application/vnd.ms-excel.

[NoFriendsss]

Same problem here on Safari 10.0. I can't download an application/vnd.ms-excel file type.
But working fine on Chrome & Firefox.

here is a part of my code (angular 2) :

data.service.ts :

exportObject(): Observable<any> {
  const args: RequestOptionsArgs = {
    headers: new Headers({ 'Content-Type': 'application/zip' });,
    responseType: ResponseContentType.Blob
  };

  return this.http.get(${this.apiUrl}/exportObject, args).map(
  data => {
    return data.blob();
  });
}

my-component.ts :

this.dataService.exportObject().subscribe(
  blob => {
    saveAs(blob,${this.componentObj.name}-config.zip);
  }
);

[sirbarrence]

FileSaver.js works for me in my application and on the demo page in the latest Safari Technology Preview Release 23 (Safari 10.2, WebKit 12604.1.5) on Sierra. Saves to the Downloads folder with the correct filename and everything!

(Might have been fixed in a previous Preview release. I can't recall the last Preview I tried.)

[sirbarrence]

Also works in Safari 10.1 in the latest macOS Sierra 10.12.4 Beta, so I would guess that real users might get this in the next few months.

[meletis]

Yes, confirmed. I also works for me in Safari 10.1 released yesterday.

[davidpelayo]

Confirmed it's working on Safari 10.1, but not in previous versions.

[jimmywarting]

Should we close this issue now? ;P

[sirbarrence]

Should probably update the supported browser info in README.md

On May 22, 2017 at 7:02:11 AM, Jimmy Karl Roland Wärting (
[email protected]) wrote:

Should we close this issue now? ;P

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eligrey/FileSaver.js/issues/12#issuecomment-303068736,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAx0HlVZIReHoeX8j3yRVc8f0smrRw9Aks5r8WszgaJpZM4AWU7q
.

[toby5box]

FWIW I can report this problem still exists on Safari 9.1.1 (El Capitan).

[aishmita-aggarwal]

I am also experiencing the same issue on Safari 9.1.2 (El Capitan).

[davidpelayo]

Yes. Let's update supported browser in README and close this issue.

[Ruffio]

@eligrey if this issue is resolved/closed, should the Frontpage be updated?

Currently it states:
Safari 6.1+

Blobs may be opened instead of saved sometimes—you may have to direct your Safari users to manually press ⌘+S to save the file after it is opened. Using the application/octet-stream MIME type to force downloads can cause issues in Safari.

[tayfunyasar]

It still doesn't work on my tablet.
IOS: 11.0.2 (15A421)

var wbout = XLSX.write(wb, { bookType: 'xlsx', bookSST: false, type: 'binary', }); fileSaver.saveAs(new Blob([s2ab(wbout)], { type: 'application/octet-stream', }), name);

[CinnamonRage]

I can agree with @tayfunyasar, it's not working on iOS for me. I have submitted a bug report to Apple regarding the lack of download attribute for all the good it's likely to do.

[dotnetCarpenter]

It's only fixed on Desktop Safari. iOS safari does still not (iOS 12.1) support the download attribute.
https://bugs.webkit.org/show_bug.cgi?id=167341

[pawepaw]

It still doesn't work on my tablet.
IOS: 11.0.2 (15A421)

var wbout = XLSX.write(wb, {
  bookType: 'xlsx',
  bookSST: false,
  type: 'binary',
});
fileSaver.saveAs(new Blob([s2ab(wbout)], {
  type: 'application/octet-stream',
}), name);

So what's the recommended workaround for that? I'm facing same issue.

I understand that i can either leave 'application/octet-stream' and it'll not work on IOS Safari or change it to proper content-type 'application/pdf' in my case but it'll open file in new tab with strange url 'blob:something'? Is there any other chance to force saving file in safari ios?

[generalov]

@pawepaw I suppose that the opening in new tab is expected behavior for Safari <12 on iOS because the browsers do not have an access to file system. This gives the user a chance to save a file with an additional click to the cloud storage.

[dotnetCarpenter]

I can save a file on iOS but not give it a name. @pawepaw See here: https://dotnetcarpenter.github.io/FileReader_Chrome/

[crisz]

This is still not working on iOS, with the exact same symptoms as described above. In my opinion this issue should not be closed

[classicPintus]

Confirm for me also. Unfortunately the problem is still there

[Jason-LI-M]

I can save a file on iOS but not give it a name. @pawepaw See here: https://dotnetcarpenter.github.io/FileReader_Chrome/

Not working

[CinnamonRage]

This is resolved in the new safari in iOS 13 with the introduction of three download manager.

[Stofkat]

can this be reopened? this is still an existing issue

[IhorBilobran]

I had the same issue with images download. iPhone, Safari. This helped:
const blob = new Blob([file], { type: 'image/jpeg' });
const url = window.URL.createObjectURL(blob);
saveAs(url, fileName);

[DevJhns]

I had the same issue with images download. iPhone, Safari. This helped:
const blob = new Blob([file], { type: 'image/jpeg' });
const url = window.URL.createObjectURL(blob);
saveAs(url, fileName);

this code allowed you to DOWNLOAD file in your file system or OPEN it in safari tab?

[HansLanger]

2020 and still the same problem? UNKNOW as name, and can't download octet-stream?? wow.
I'm lucky because i can say to my users "Safari is not a modern browser, just use chrome,firefox or edge"

[snipe]

@HansLanger Maintaining open source projects takes a lot of time, and sometimes people's priorities change, and life gets in the way. People create software and let you use it for free, so maybe don't be an ass in the face of free labor. Having a crappy attitude doesn't get problems solved any faster.

[HansLanger]

@snipe: If you understand the problem you would understand that I was NOT complaining about FileSaver.js. I was complaining about Safari (which is not free). Sorry for the confusion.

[snipe]

@HansLanger thanks for the clarification. (Safari is free, if you don't mind dropping $1k on an iPhone ;-) )

Did you try the solution @DevJhns mentioned?

[HansLanger]

@HansLanger thanks for the clarification. (Safari is free, if you don't mind dropping $1k on an iPhone ;-) )

Did you try the solution @DevJhns mentioned?

Yes, I tried everything on an Iphone. It just does not work. The Initial @gawry post describes everything perfectly, its a great information, but Apple has not solve the problem, and that is why my first comment.

[JamesDougherty]

Looks like the "download" attribute was added in iOS 13 as of April 2020.

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.

https://bugs.webkit.org/show_bug.cgi?id=167341