Looks like there is a weird download issue in chrome on android. If you click on save and hit download it throws an error message as shown below "was not able to download the file because of an unknown issue".
Weird thing, the image has been actually saved and can be opened through the download list.
Chrome ver.: 58.0.3029.83
Android ver.: 7.0.0

I'm having the same issue, the difference is that the same message appeared but my blob file was not downloaded on android chrome.
Hello, I solved this issue by not using the package and doing it manually... I don't know if it helps but here is my code:
let blob = new Blob([ticket],{type: "application/octet-stream"}),
filename = "ticket.pdf",
reader = new FileReader();
reader.onload = function (event) {
let save = document.createElement('a');
save.href = event.target.result;
save.download = filename;
document.body.appendChild(save);
save.click();
document.body.removeChild(save);
window.URL.revokeObjectURL(save.href);
};
reader.readAsDataURL(blob);
I'm just a junior programmer, and I don't know if this FileReader part is in the package, but if it was maybe it would work on Android Chrome. I really would like to use the package and not my own code for it's compatibility perks!
@rsmelo92 I think we used your solution before switching to FileSaver.js. If I remember correctly there was some weird issues with this as well ant that is why we started using FileSaver.js. But I might be misremembering so try testing it as much as you can. It could have been just an Ios or IE bug I am not sure.
@cordasfilip Yes you are right, I discovered that fact the hard way.
But since that day I changed my solution and I believe now it works in every platform ( It was tested in up to date versions of IE and Edge, Chrome, Mozilla, Opera, Safari, iOS and Android Chrome). It's a mix of FileSaver.js and other solutions for compatibility.
// Get if is smartphone
if (Math.max(document.documentElement.clientWidth, window.innerWidth || 0) <= 1024) {
reader.onload = function (event) {
console.log("onload", event)
// If chrome android
if (window.chrome) {
let save = document.createElement('a');
save.href = event.target.result;
save.download = filename;
document.body.appendChild(save);
save.click();
document.body.removeChild(save);
}
// If iPhone etc
else if(navigator.platform && navigator.platform.match(/iPhone|iPod|iPad/)){
let url = window.URL.createObjectURL(blob);
window.location.href = url;
}
else{
// Any other browser
saveAs(blob, filename);
}
window.URL.revokeObjectURL(save.href);
};
reader.readAsDataURL(blob);
}
else{
//Desktop if safari
if (navigator.platform.match(/MacIntel/) || navigator.userAgent.indexOf('Safari')) {
let url = window.URL.createObjectURL(blob);
window.location.href = url;
}
else{
// If normal browser use package Filesaver.js
saveAs(blob, filename);
}
}
Reported this problem at:
https://bugs.chromium.org/p/chromium/issues/detail?id=733304
Chrome has fixed this in M59
@mpkorstanje Chrome 60 ref https://bugs.chromium.org/p/chromium/issues/detail?id=733304#c7
Ah. Bummer. Not a big problem with their release cycle.
Well, this problem stoods for months already. Perhaps Android 7 is to be blamed, but still, this took too long.
Have anyone tried @rsmelo92 's code?
Should I use it? Is it planned to be incorporated in this package until the issue is resolved?
With Android 7.0, Chrome 59.0.3071.125 as well as Chrome Beta 60.0.3112.78 on Google Nexus 6, I'm still seeing this issue. According to https://bugs.chromium.org/p/chromium/issues/detail?id=733304#c7 it was fixed in Chrome 60?
The work around provided by rsmelo92 to use a dataURI to save seems to work only for tiny files. Anyone know of another work around that could support larger files?
Seems to be affecting many sites that use Javascript to save files...
I haven't tried on large files but I did implement @rsmelo92 workaround and the error is indeed gone.
I hope the maintainers of this library will implement some aspect of this workaround...
So it appears the file size limitations are around ~2MB for the Data URI workaround posted by @rsmelo92, found the following bug that appears to reference the issue:
https://bugs.chromium.org/p/chromium/issues/detail?id=69227
In regards to the fix implemented in Chrome 60, in my testing it only works for files up to ~30MB. I've updated https://bugs.chromium.org/p/chromium/issues/detail?id=733304#c10 accordingly.
If you want to make it easy for the g-man you could take my plunker and have it generate different file sizes.
@jimmywarting has this been solved, modified?
Closed this as being to staled for to long.
Browser have been updated, and a hole rewrite for v2 has emerged that may or may not have solved the problem. if this is still an issue we can reopen it or create a new issue
Can you reopen please and instruct me how to test it using the latest version? Is there a npm pre-release package?
I'll be happy to help by doing some QA on the rc.
Sure, there is a pre-release package
think you can install it using npm install file-saver@next
or exact number npm install [email protected]
alternativ is just to download the file
Has this issue been resolved and should be closed with the new version?
I still haven't got to test it yet, Hopefully in about a week (I'm rewriting my site, and it takes longer than expected).
If you get to test it before I do, please let me know what were the results.
For a very simple test I made, this seems to have been resolved on android chrome. I haven't tested it on iPhone yet.
Fixed for me with last release (version 2.0.0). (bug was present with 2.0.0-rc4)
Most helpful comment
Chrome has fixed this in M59