Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Doesn't seem to work in Chrome 50 and later #205

Closed
calebsander opened this issue Mar 6, 2016 · 8 comments
Closed

Doesn't seem to work in Chrome 50 and later #205

calebsander opened this issue Mar 6, 2016 · 8 comments

Comments

@calebsander
Copy link

When I try to save a file, it fails about 95% of the time and says Failed - no file. The download on the left is one where it worked, while the one on the right is one where it failed.
Error
I see the same issue on the demo page. Even in the following very simple code (where FileSaver.js contains the contents of https://raw.githubusercontent.com/eligrey/FileSaver.js/master/FileSaver.min.js), it fails to work almost all the time:

<html>
    <head>
        <script src = 'file:///[redacted]/FileSaver.js'></script>
        <script>
            if (window.saveAs && window.Blob) saveAs(new Blob(['abc'], {type: 'text/plain'}), 'test.txt');
            else alert('Missing dependencies');
        </script>
    </head>
</html>
@calebsander
Copy link
Author

I just tested it in Chrome 49.0.2623.75 on Ubuntu and it seems to work fine.

@andriuskv
Copy link

I am having same issue in Chrome 50.0.2661.11, but it fails about 50% of the time.

@maclav3
Copy link

maclav3 commented Mar 14, 2016

Same here.

The separate condition for Chrome is causing problems for me on the current google-chrome-beta (50.0.2661.26):

if (view.chrome) {
    revoker();
} else {
    setTimeout(revoker, arbitrary_revoke_timeout);
}

https://github.com/eligrey/FileSaver.js/blob/master/FileSaver.js#L55

I admit I haven't delved into the code enough to understand the whole revocation process, but if I remove the condition and use the setTimeout code in Chrome 50, everything seems to be OK.

Also, the setTimeout code seems to be compatible with the current google-chrome stable (49.0.2623.87).

@evilaliv3 evilaliv3 mentioned this issue Mar 19, 2016
Closed
@calebsander calebsander changed the title Doesn't seem to work in Chrome 51.0.2669.0 Doesn't seem to work in Chrome 50 and later Mar 25, 2016
@yairza yairza mentioned this issue Mar 28, 2016
Closed
@yairza
Copy link

yairza commented Mar 28, 2016

I deleted my remark, it works great on osx
On Mar 28, 2016 7:22 PM, "Maciej" notifications@github.com wrote:

Hello,

I tested the workaround on google-chrome-beta on Linux 64bit, I don't know
about OSX - maybe it's OS-dependent. I won't be able to test it on OSX
soon, but I might check another Linux machine tonight and let you know if
it still works.
28.03.2016 2:02 PM "yairza [Masked]"

<FWD-737QTYSMENAIYCQANIQDDYCOEFGCQMB3ACWAIOKCGADFMIDABYQCZZCIFFE3KALYAC4WXQARUB3FQDNTI23GOETC4QGMMCC2DSUFJKAQ5ASOSQ53AHJB2VSJZEM7EEBRAOXC5O2VGUACCKDIFAQHIILGEELCALRACYQS4TAWFAB7QAXYAGIATMIDQZYNEEFAAAQA====@
opayq.com> napisał(a):

Preview: @maclav3 I tested your workaround on chrome beta (50.0.2661.3
This email is forwarded from a MASKED EMAIL you created using
DoNotTrackMe
https://dnt.abine.com/help.
IF THIS IS SPAM, CLICK HERE TO BLOCK.
<
https://dnt.abine.com/#/block_email/c4e743b9@opayq.com/FWD-737QTYSMENAIYCQANIQDDYCOEFGCQMB3ACWAIOKCGADFMIDABYQCZZCIFFE3KALYAC4WXQARUB3FQDNTI23GOETC4QGMMCC2DSUFJKAQ5ASOSQ53AHJB2VSJZEM7EEBRAOXC5O2VGUACCKDIFAQHIILGEELCALRACYQS4TAWFAB7QAXYAGIATMIDQZYNEEFAAAQA====@opayq.com

Want to shop safely and privately online? Get DoNotTrackMe Premium
https://dnt.abine.com/#premium.

@maclav3 https://github.com/maclav3 I tested your workaround on chrome
beta (50.0.2661.37) on OSX 10.11 and it didnt solved it :(

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
https://github.com/eligrey/FileSaver.js/issues/205#issuecomment-202356345>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#205 (comment)

eligrey added a commit that referenced this issue Mar 28, 2016
@eligrey
Semi-workaround for #205
62d219a 
This solution still isn't technically correct because it could take more
than 40 seconds to download a file. I could simply not revoke any files,
but then users would run into issues once they have saved a cumulative
total of over 500MB (
https://bugs.chromium.org/p/chromium/issues/detail?id=375297 )

Complain to @sicking and @arunranga for creating and standardizing an
incomplete revocation API.
@eligrey eligrey closed this as completed Mar 28, 2016
@eligrey
Copy link
Owner

eligrey commented Mar 28, 2016

If the blob revocation API doesn't get fixed in the next 2 years, remind me to double this value (as I would imagine as time goes on more complicated web apps are going to want to save larger and larger files). Sorry, not much more I can do except specify an arbitrary timeout.

timoxley added a commit to timoxley/browser-filesaver that referenced this issue Mar 29, 2016
@timoxley
Merge branch 'master' of github.com:eligrey/FileSaver.js
b0f60ee 
* 'master' of github.com:eligrey/FileSaver.js:
  Removing dead link from demo
  Update demo scripts
  Adding Edge to the browser support table
  Semi-workaround for eligrey#205
  Update sourcecode date
  Fix issue eligrey#207
  Fix eligrey#165, Saving multiple files
  License clarification
  Update version (to go with eligrey#175)
  update dist and readme
  more accurate base64 data processing; moved safari check to variables
  Update dist
  Update dist
  removed encodeURI and fixed Safari detection
  better regex check
  Workaround for downloading application/octet-stream in Safari
  Closes eligrey#164
@timoxley timoxley mentioned this issue Mar 29, 2016
Merged
@MrDefinite
Copy link

Still face the same issue on Windows and Mac Chrome 50.
However it doesn't happen if I simply use data URI like this: http://jsfiddle.net/qm5AG/1621/

@wangwenming
Copy link

OSX, Chrome 65.0.3325.181, It doesn't work!

@rajsite
Copy link

rajsite commented Jun 19, 2019 •
edited
Loading

Seems like the related Chromium issue was fixed in Chrome 66: https://bugs.chromium.org/p/chromium/issues/detail?id=827932

Was Chrome the only reason to have the setTimeout before calling revokeObjectURL() workaround?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@eligrey @rajsite @wangwenming @calebsander @MrDefinite @maclav3 @andriuskv @yairza