Fix for Firefox not displaying contents directly in the browser
Have you ever encountered situations in Firefox where supported file types like text files were not displayed directly in the browser but only offered to be saved to the local system? While that makes sense for file types the browser does not support, like executable files, there is no real reason to display a save dialog for text files or images by default.
The web browser decides whether to display files right away or display a save option instead usually. This can be partially customized by the user, for instance to automatically save files of a certain type to the system whenever they are requested.
Web servers can however use the Content-Disposition header to override this behavior of the browser. This is sometimes used to force the browser to ignore that it is capable of displaying the file contents right away so that a save or open dialog is shown instead.
As you can imagine, this can be irritating if you select the "do this automatically for files like this from now on" option only to get the same open or save dialog again the next time.
The user of the browser has no say in the matter and there is no option to ignore the header on the user's side, at least not when it comes to the default options the browser makes available.
Firefox users can install the InlineDisposition add-on for the browser to ignore the header so that supported file types can be viewed directly in the browser.
The extension works automatically once you have installed it in Firefox. A good way to find out if it is working is to open the following link in Firefox or another web browser. When you do that, you will notice that a text file is offered for download or downloaded directly to the computer.
With InlineDisposition installed, the text file is displayed in Firefox so that you can read it right away. You can still save it then by right-clicking the page and selected to save it to the device.
The extension works well for all file types that the browser supports internally. This includes text files, pdf documents, image formats and other media types.
Please note that servers can still prevent the inline viewing of file types if they specify a content-type that the browser does not support.
Other extensions of use in the situation:
- Open in Browser adds an option to Firefox's save window that enables you to open the selected file type directly in the browser.
- Force Content Type enables you to change the content-type of urls in Firefox. Useful if the server is mis-configured or using the wrong content type on purpose.
- Web Page Fixer fixes a number of annoyances including fixing the "do this automatically from now on" checkboxes in Firefox.
- ReDisposition allows you to switch between overriding the Content-Disposition header or accepting it.
Super useful. Thank you!
I do hope there are no side-effects, as some have stated on the add-on’s AOM page.
Also, if “altering the disposition type of Content-Disposition response headers from attachment to inline” seems so obvious as it restores the user’s choice, why hasn’t this been done from the beginning? What were/are the reasons leading to an opposite choice, be it Firefox or, as I read here, Chrome browser?
I’m always a bit suspicious when it comes to a bright solution for an everlasting behavior.
Any similar add on for chrome?
Ty
Not that I’m aware of, sorry.
Now this is quite strange, I mean the way my Firefox here handles .txt files, and this article brings my attention on an oddity :
If the url contains explicitly the .txt format, then Firefox displays the content on its screen. Ex. : https://adversity.googlecode.com/hg/Antisocial.txt
Now, if I call the above url, Firefox indeed asks we what to do but there is no option to have the content displayed within Firefox : http://code.kliu.org/misc/inlinedisposition/attachtest.pl
From here, looks like Firefox relies on the format when explicit, but .pl not being a .txt explicitly though it is implicitly, Firefox does not display it. Strangest thing is that,the Open dialog recognizes the .txt format since it proposes me to open with my dedicated .txt reader …
Am I missing something?
This is caused by the header the server is sending: Content-Disposition: attachment; filename=”test.txt”
It is basically forcing the browser to handle the text file as an attachment that you can only download or open externally.