Nw.js: <a> "download" attribute doesn't seem to work
Read the following before submitting your issue, thank you.
- Please use English so all users can read, or the issue will be closed directly.
- Use our mailing list to ask questions which don't imply bug or feature request: https://groups.google.com/forum/#!forum/nwjs-general
- State which version are you using
- State which OS version are you running with
- Provide a reproducible case if possible
- Attach the crash dump file if it's a crash: http://docs.nwjs.io/en/latest/For%20Developers/Understanding%20Crash%20Dump/#find-minidump-file
Issues meet the checklist above will be processed before those don't.
josh83abc
All 9 comments
Hi guys,
On Chrome, when you click on the link, the downloaded file is called "greatname.mp3", which is correct!
On NW.JS 0.24, when you click on the link, the downloaded file is called "crappyname.mp3", behaving like the download attribute is ignored, which is incorrect :/. I tried everything, the only way is to use the NW.JS SDK version and to right click on the link and choose "Download link". Which is not possible for production.
Would be great to see this fixed :)
If some people wondering why I need this, well on my app the "crappyname.mp3" is actually a temporary url generated from a blob (with window.URL.createObjectURL(blob)) and the generated filename is very crappy, it looks like somethings like : blob:d3958f5c-0777-0845-9dcf-2cb28783acaf (without even a file extension).
Thanks for your help! :)
Josh
josh83abc
on 11 Aug 2017
I can reproduce this issue on Linux/Windows with nwjs-sdk-v0.24.2.
Christywl
on 14 Aug 2017
I'm glad to see activity on the thread and you have been able to reproduce the problem :).
For now, I still didn't find a way to download a blob/arraybuffer with a predefined filename inside my app.
Thanks for your amazing work guys!
josh83abc
on 14 Aug 2017
@Christywl I can't reproduce this with latest 0.25 nightly build. Please try again.
rogerwang
on 4 Sep 2017
@rogerwang , it still doesn't work for me with https://dl.nwjs.io/live-build/09-04-2017/nw25-38856f7-dcf9601-90dc2ed-c48782d/v0.25.0/nwjs-sdk-v0.25.0-win-x64.zip. My codes:
<!DOCTYPE html>
<html>
<body>
<p>Click to download:<p>
<a href="https://www.w3schools.com/jsref/horse.mp3" download="test">horse.mp3 download</a>
</body>
</html>
Is there something wrong in my test?
Christywl
on 4 Sep 2017
Maybe it's because I was trying with Linux ... Thanks.
On Mon, Sep 4, 2017 at 3:32 PM Christywl notifications@github.com wrote:
It still doesn't work for me with
https://dl.nwjs.io/live-build/09-04-2017/nw25-38856f7-dcf9601-90dc2ed-c48782d/v0.25.0/nwjs-sdk-v0.25.0-win-x64.zip.
My codes:
Click to download:
[image: image]
https://user-images.githubusercontent.com/20039821/30016089-33a1a7be-9186-11e7-8678-69c6cfbab830.pngIs there something wrong in my test?
—
You are receiving this because you were assigned.Reply to this email directly, view it on GitHub
https://github.com/nwjs/nw.js/issues/6094#issuecomment-326887129, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKGGaZcPzk-KEegGxDdXnSkiGMiLRiQks5se6eJgaJpZM4O1LTu
.
rogerwang
on 4 Sep 2017
I got the same result on Linux with v0.25.0, the file name didn't change.
Christywl
on 4 Sep 2017
This is because I was testing with a http URL as the start page, and it's in the spec that the attribute should be dropped when requesting cross-origin downloads: https://bugs.chromium.org/p/chromium/issues/detail?id=714373
So this is expected and not a bug. However, the cross-origin limit should be lifted in NW.js app as we are not using W3C security model in NW.js frames.
rogerwang
on 5 Sep 2017
This is fixed in git and will be available in the next nightly build.
rogerwang
on 5 Sep 2017
Related issues
loretoparisi
·
3Comments
jportoles
·
3Comments
hooker99
·
4Comments
niutech
·
4Comments
rumax
·
4Comments