Issue metadata
Sign in to add a comment
|
a[download] attribute not honoured in extension context on Chrome 65
Reported by
thembr...@gmail.com,
Jan 12 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36 Steps to reproduce the problem: 1. Open any extension page in a new tab (e.g install https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm and open chrome-extension://cjpalhdlnbpafiamejdnhcphjbkeiagm/dashboard.html 2. Run this code in the dev console: (function download() { let url = URL.createObjectURL(new Blob(['xxx'])); console.log('downloading', url); let linkEl = document.createElement('a'); linkEl.setAttribute('download', 'foo.bar'); linkEl.setAttribute('href', url); linkEl.dispatchEvent(new MouseEvent('click')); })(); What is the expected behavior? It should open a download dialog (as in Chrome 63 or when executed from any regular web context). What went wrong? Link opens in same tab instead. Should work the same way as in regular web context. (e.g. http://jsbin.com/legisaz/edit?html,js,output) Did this work before? Yes 63 (verified), reason to believe that 64 works too Does this work in other browsers? Yes Chrome version: 65.0.3319.0 Channel: stable OS Version: OS X 10.13.2 Flash Version:
,
Jan 12 2018
,
Jan 15 2018
Able to reproduce the issue on Windows 10, mac 10.12.6 and Ubuntu 14.04 using chrome reported version #65.0.3319.0. Bisect Information: ===================== Good build: 65.0.3309.0 Bad Build : 65.0.3310.0 Change Log URL: https://chromium.googlesource.com/chromium/src/+log/cbce1149c9ae08297b816effbf456c02f97df8db..f2d2fe87028de36a489f7db3f5fb28da2e9d9b2b From the above change log suspecting below change Change-Id: I508d7abe1cba9b75d65132b0688984cdebfc6fd4 Reviewed-on: https://chromium-review.googlesource.com/758236 jochen@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Adding stable blocker for M-65 as it seems to be recent regression. Please feel free to remove the same if not appropriate. Thanks...!!
,
Jan 15 2018
Example snipped for filesystem:* URLs (same behaviour):
function downloadUrl(url) {
console.log('downloading', url);
let linkEl = document.createElement('a');
linkEl.setAttribute('download', 'foo.webm');
linkEl.setAttribute('href', url);
linkEl.dispatchEvent(new MouseEvent('click'));
}
async function createFile() {
let fs = await new Promise(r => webkitRequestFileSystem(window.TEMPORARY, 1 * 1024, r));
let fileEntry = await new Promise(r => fs.root.getFile('foo.webm', {create: true}, r));
let fileWriter = await new Promise(r => fileEntry.createWriter(r));
let writeDonePromise = new Promise(r => fileWriter.onwrite = r);
fileWriter.write(new Blob(['some content']));
await writeDonePromise;
console.log('created file');
return fileEntry;
}
async function downloadFromUrl() {
let fileEntry = await createFile();
downloadUrl(fileEntry.toURL());
}
downloadFromUrl();
,
Jan 15 2018
I believe this is a duplicate of issue 798705 - can you verify whether it reproduces on ToT?
,
Jan 15 2018
Does not reproduce on 65.0.3321.0 anymore, so it's duplicate. Sry, did not find that one.
,
Jan 15 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by thembr...@gmail.com
, Jan 12 2018