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.

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

Chrome 65 : Can't open same-window link to "blob: #408

Closed
simonaberry opened this issue Mar 16, 2018 · 19 comments
Closed

Chrome 65 : Can't open same-window link to "blob: #408

simonaberry opened this issue Mar 16, 2018 · 19 comments

Comments

@simonaberry
Copy link

It seems that the latest update to Chrome (65) has lead to the window.saveAs() to fail in Chrome Extensions or Packaged Apps .

The error helpfully suggest try target="_blank".

Do you know if we can pass a target to saveAs ?

@eligrey
Copy link
Owner

eligrey commented Mar 16, 2018

I think most browsers auto-close newly-opened download tabs now. I went ahead and added target="_blank" for all cases.

@mlev
Copy link

mlev commented Mar 21, 2018

With this change in Chrome 65 and 67 (Canary) my downloads are now blocked as pop-ups. v1.3.3 still works fine in both versions.

@eligrey eligrey reopened this Mar 22, 2018
@eligrey
Copy link
Owner

eligrey commented Mar 22, 2018

I guess we should conditionally detect chrome extensions & packaged apps before adding target="_blank".

eligrey added a commit that referenced this issue Mar 22, 2018
@simonaberry
Copy link
Author

Why not leave it up to the user (developer) to specify the target via a option parameter?

@davidcalhoun
Copy link

davidcalhoun commented Mar 23, 2018

Can confirm that 1.3.3 is working fine with Chrome 64 and 65. There was something breaking in the latest releases and downloads don't work at all for me now on 1.3.8.

If there were major changes, I suggest bumping the major or minor package version (semver) to make it more clear. Thanks!

@bittermanq
Copy link

Have you found any correlations with Adblock? In my project similar code (not FileSaver) stops working with Adblock, and only with Chrome 65.

@crystalfp
Copy link

No AdBlock, Chrome 65, loading FileSaver through Require.js.
Inside one of my files it is accessed this way:

define(["file-saver"], function(fileSaver) {

1.3.2 should call fileSaver(...) but does nothing
1.3.3 fileSaver is undefined
1.3.4 fileSaver is undefined
1.3.6 should call fileSaver.saveAs(...) but does nothing
1.3.8 should call fileSaver.saveAs(...) but does nothing

So really don't know what to do. On year ago, in another project it worked flawlessly, but with a previous version of Chrome.

@simonaberry
Copy link
Author

My workaround (for a Chrome Packaged App) was to not use fileSaver, but rather chrome.fileSystem.chooseEntry

function saveAs(blob, filename, type) {

        function errorHandler(err) {
          console.log('err' + JSON.stringify(err));
        }


        chrome.fileSystem.chooseEntry({
          type: 'saveFile',
          suggestedName : filename ,
          accepts : [{
            extensions : [type]
          }],
          acceptsAllTypes : false
        }, function(writableFileEntry) {
          writableFileEntry.createWriter(function(writer) {
            writer.onerror = errorHandler;
            writer.onwriteend = function(e) {
              console.log('write complete');
            };
            writer.write(blob);
          }, errorHandler);
        });
}

@crystalfp
Copy link

Nice, but I have no access to chrome.fileSystem
I start my application this way (on Windows, Chrome latest version):

chrome.exe --app=https://127.0.0.1:3000/index.html --start-maximized --allow-insecure-localhost --allow-file-access-from-files

What flag I'm missing?

@simonaberry
Copy link
Author

I don't think you will get access to chrome.filesystem in that mode. You may have to wait for the official fix ;-(.

@crystalfp
Copy link

crystalfp commented Mar 27, 2018

Yes, I was too fast. I have not a packaged application, but a simple browser based app. This explains the missing fileSystem.

OK back to a simple <a href="" download=filename> ...

@zoharshavit
Copy link

any news about this issue?

@crystalfp
Copy link

Well, implemented the following code that works like a charm (launched from a button):

const aElement    = document.createElement("a");
aElement.href     = "data:text/plain;charset=UTF-8," + encodeURIComponent(textToExport);
aElement.target   = "_self";
aElement.download = filename;
document.body.appendChild(aElement);
aElement.click();
document.body.removeChild(aElement);

No need to support browsers besides Chrome, so this is OK for me.
Anyway, thanks for your help!
mario

@hardiksondagar
Copy link

To avoid what is essentially user-mediated cross-origin information leakage, Blink will start to ignore the presence of the download attribute on anchor elements with cross-origin attributes.

https://www.chromestatus.com/feature/4969697975992320

@crystalfp
Copy link

This is true in general. I need only to download from same origin. Actually I run a server on localhost and my browser connects only to localhost.

@bilalasif
Copy link

bilalasif commented Apr 9, 2018

@davidcalhoun I am trying to install 1.3.3 by using bower install file-saver#1.3.3 it installs 1.3.2 bower.json says it is 1.3.3 but in comments of filesave.js file it still says 1.3.2. I did a bower cache clean as well any idea what am I doing wrong?
My extension on chrome stopped working unable to identify the reason for that

@onaralili
Copy link

Unfortunately, it stopped working on my extension as well. Update FilerSaver to the new version, still no effect.

@KurtPreston
Copy link

@eligrey Echoing @crystalfp here. target=_blank will be blocked by Chrome 65+, however target=_self works just fine.

@qing-ke
Copy link

qing-ke commented May 26, 2018

I have the same problem,what should I do?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests