File not download in firefox

[mehulkamani]

ctrl + shift + r (refresh ) then download file at that time file not download but after simple refresh it work

https://jimmywarting.github.io/StreamSaver.js/localhost/247583/archive.zip get 404

[Rahul-kalsha]

Browser Hard Refresh: (Failed)

Browser Simple Refresh: (Success)

[jimmywarting]

Aa, have had some similar issue before in a other package, have something to do with claiming the window

[jimmywarting]

hmm, wait... it looks like i'm claiming already

https://github.com/jimmywarting/StreamSaver.js/blob/e00b4a7282a8381a6f72325d6ea93ee1171795da/sw.js#L8

[Rahul-kalsha]

Yes @jimmywarting it's already there in sw.js but what's the solution for them because still getting the same issue.

[jimmywarting]

Previously i have had grate success using this technique: https://stackoverflow.com/a/60133005/1008999 when it came to hard refreshes. This didn't really work for me everytime:

self.addEventListener('activate', event => {
  event.waitUntil(self.clients.claim())
})

[jimmywarting]

I can try out the solution from SO, need to change mitm.html + sw.js

[jimmywarting]

Ok, i tested the old claimMe hack. it did only work for chrome. But it wasn't needed as i did it in the service worker anyway in installation.

However there are a other solution... changing https://github.com/jimmywarting/StreamSaver.js/blob/3955638d238cfca132e2a3d7c3427424cda930f5/StreamSaver.js#L22-L24

to:

const downloadStrategy = isSecureContext && !('MozAppearance' in document.documentElement.style)
   ? 'iframe' 
   : 'navigate' 

This will cause a navigation instead of making a iframe to trigger the download. the affect of it is that it will trigger a unload event. It might not always be what you want...

Another historical problem (if i remember correctly) with a navigation is that it can potentially freeze the javascript runtime and prevent chunks from being transfered to the service worker. and if you open a download url that have not received any bytes yet then it can create a infinity "waiting for response" before the save dialog shows up and then unfreeze the javascript runtime.

if you can test this out and manage to spot any other side affects in other browsers that would be grate.

A other possible solution could be to open the download url in another popup with window.open or <a href="downloadurl" download="filename" target="_blank"> but that isn't as appealing (i do not remember why i ditched this idea - could be that it can trigger a popup-block) opening a link without target="_blank" is the same as navigating

[mehulkamani]

const downloadStrategy = isSecureContext && !('MozAppearance' in document.documentElement.style) ? 'iframe' : 'navigate'

Yes this code starts the download but after a while an error occurs.

[Rahul-kalsha]

Hey @jimmywarting Can you please suggest me any other solution, I am also stuck in the same situation here. I tried above all solutions but not working well. Also, your other solution window.open, which has to allow popups on a manual basis. So it is not user friendly.

I am appreciated your help but also waiting for your right quick solution. :)

[jimmywarting]

window.open are often allowed on user interaction... so if you trigger the download durning eg a mouse click (even doe you don't have the data ready at hand) but it often requires you to know what the filename is beforehand.

Another solution I often have to recommend is to use the server whenever possible instead of emulating it with service worker. But it requires you to respond with content-disposition attachment header and you can't use ajax to download it... the alternative is opening a new url with iframes/popup/tabs/links/<form>- if you need to post data and use other http method

Another possible solution is to try out the new https://github.com/jimmywarting/native-file-system-adapter i have built also. you can save data with streams with or without service worker (service worker are merely a enhancement) + that you have grater control over the service worker so you can pre-install the service worker earlier before you even create a writable download stream

[Rahul-kalsha]

Hey @jimmywarting, I try everything given by you but not getting any conclusion. I hope the above issue you will be fix your upcoming release. :)

[WebSpider]

I would also be really interested in a solution that works with firefox, which is no small browser at all :)

[jimmywarting]

I haven't found a solution to it yet... if you find something that dose i would like to hear about it

[diafygi]

So I've found there's two things going on:

1. In Firefox private browsing mode (i.e. incognito mode), navigator.serviceWorker is current disabled (see Firefox Bug #1320796), so StreamSaver.js will fallback to the normal blob saver functionality (i.e. load everything, then show a file save prompt).
2. In Firefox normal mode, when the "Delete cookies and site data when Firefox is closed" setting is checked, navigator.serviceWorker.register(...) will throw an exception (see Firefox Bug #1755167), which causes the mitm.html to silently fail (i.e. says it's downloading, but you never see a download prompt).

Situation 2 is probably what this issue is referring to.

Possible solution:

• Try to detect if calling navigator.serviceWorker.register(...) will throw an exception in StreamSaver.js, and set useBlobFallback = true if it does.

[WebSpider]

Thanks for that investigation, and will test if useBlobFallback does the trick for me!

[SilverSeva]

Hi, any solution to this issue?

[diafygi]

An update from my previous comment:

1. In Firefox private browsing mode (i.e. incognito mode), navigator.serviceWorker is current disabled (see Firefox Bug #1320796), so StreamSaver.js will fallback to the normal blob saver functionality (i.e. load everything, then show a file save prompt).

This bug is still outstanding, so StreamSaver.js does not work as intended in Firefox Private Mode (it has to load the full download into memory, then create the download prompt).

Additionally, using window.showSaveFilePicker() from the File System API is not yet supported in Firefox, so that's not an option either.

Current status: Dynamic stream saving without loading everything into memory is impossible on Firefox Private Browsing mode.

2. In Firefox normal mode, when the "Delete cookies and site data when Firefox is closed" setting is checked, navigator.serviceWorker.register(...) will throw an exception (see Firefox Bug #1755167), which causes the mitm.html to silently fail (i.e. says it's downloading, but you never see a download prompt).

This bug is now fixed, so StreamSaver.js works as intended (hooray!).