Skip to content
This repository has been archived by the owner on Jun 26, 2023. It is now read-only.

Browser sometimes remembers the previous download action. #9

Closed
alex-rosenberg35 opened this issue Oct 29, 2014 · 3 comments
Closed

Comments

@alex-rosenberg35
Copy link

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.

@spasche
Copy link
Owner

spasche commented Nov 17, 2014

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.

@alex-rosenberg35
Copy link
Author

Yep, that did it! Adding channel.setResponseHeader("Cache-Control", "private", false); below line 204 did the trick. Thanks for such a wonderful extension!

@spasche
Copy link
Owner

spasche commented Aug 18, 2015

Thanks for the fix. I'll publish a new version with it.

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

No branches or pull requests

2 participants