You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.
In a nutshell, the browser appears to sometimes cache the response and not prompt the user.
I'll try my best to first describe this problematic behavior in non-technical terms...
In Firefox 31 with Open in Browser 1.15, after clicking a link to a file (such as an image) that results in the download prompt and then opening the download in the browser (using the "Open in browser as" option), any subsequent attempts to download the file by clicking the link or refreshing the content loaded in the browser do not cause the download dialog to reappear. This behavior is intermittent (it does not always occur) and does not occur at all in Firefox 28. Also, to avoid any confusion, the "Do this automatically for files like this from now on." checkbox is NOT checked for the content-type.
It seems that newer versions of Firefox must have more aggressive caching that periodically results in the modified HTTP response headers being cached and therefore preventing the download dialog (unknownContentType.xul) from appearing. (Although I have not actually looked at the source, I assume that this extension modifies the Content-Disposition and Content-Type headers.)
What leads me to my conclusion that some sort of caching is to blame is that doing a ctrl+shift+r on the downloaded content always results in the download prompt as expected.
The text was updated successfully, but these errors were encountered:
Thanks for the report. The extension clears the cache when the resource is requested again (in order to change the response headers, https://github.com/spasche/openinbrowser/blob/master/components/OpenInBrowser.js#L68). But it doesn't try to remove the response from the cache after it is received. Maybe it should do that, or modify other headers in the response to prevent it from being cached.
Yep, that did it! Adding channel.setResponseHeader("Cache-Control", "private", false); below line 204 did the trick. Thanks for such a wonderful extension!
In a nutshell, the browser appears to sometimes cache the response and not prompt the user.
I'll try my best to first describe this problematic behavior in non-technical terms...
In Firefox 31 with Open in Browser 1.15, after clicking a link to a file (such as an image) that results in the download prompt and then opening the download in the browser (using the "Open in browser as" option), any subsequent attempts to download the file by clicking the link or refreshing the content loaded in the browser do not cause the download dialog to reappear. This behavior is intermittent (it does not always occur) and does not occur at all in Firefox 28. Also, to avoid any confusion, the "Do this automatically for files like this from now on." checkbox is NOT checked for the content-type.
It seems that newer versions of Firefox must have more aggressive caching that periodically results in the modified HTTP response headers being cached and therefore preventing the download dialog (unknownContentType.xul) from appearing. (Although I have not actually looked at the source, I assume that this extension modifies the Content-Disposition and Content-Type headers.)
What leads me to my conclusion that some sort of caching is to blame is that doing a ctrl+shift+r on the downloaded content always results in the download prompt as expected.
The text was updated successfully, but these errors were encountered: