User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615 Firefox/0.9 It would be great if the "Open" dialog listed the current firefox instance as a file viewer. Reproducible: Always Steps to Reproduce: 1. Download a plain text file or image from a webserver or script which does not issue a content-type header Actual Results: When downloading a file from a broken server or script which does not issue content-types correctly (or not at all) Firefox will display the "Open" dialog, giving "Open with" or "Save to disk" as the options. Expected Results: Either as a third option, or within "Open with" it would be nice to specify firefox itself as the viewer. By which I mean the file would open in the current firefox window/tab, or a new tab/window (make that configurable I guess). It is a pain to have to launch an image viewer just to render a jpeg because of a broken web-browser, or to have to save a plain text file to disk merely to read it. In a lot of cases, the downloader is aware that firefox would be fully able to view the file (ie is an image, text or whatever) and such a feature would greatly help alleviate the frustration caused by broken servers and scripts.
Oops, in expected-results - broken *webserver* I mean. This isn't brokeness on the part of the browser, that's why it's a feature-request - not a bug report.
Dup of bug 57342?
Making this an "Add UI for..." bug and making it depend on bug 57342.
Status: UNCONFIRMED → NEW
Depends on: 57342
Ever confirmed: true
Summary: Download dialog should offer browser as an option → Add UI for "View as Text/HTML/..." option for unknown mime content-type
*** Bug 285360 has been marked as a duplicate of this bug. ***
*** Bug 286603 has been marked as a duplicate of this bug. ***
It would also be nice if the Save-dialog would show the MIME-type given by the webserver. That way it is more obvious what type of file Firefox thinks it is and why it thinks that it should not handle it on its own.
*** Bug 304566 has been marked as a duplicate of this bug. ***
In bug 57342, Christian Biesinger comments that someone has to write the UI code for the patch to be complete, and this is a bug about the UI code which depends on 57342? I don't get this.
I have made an extension for opening documents in browser, and I think this can give some ui ideas for this bug: http://www.spasche.net/mozilla/ The "Other..." option is for entering manually a mime type. Selecting it unhides a text field on the right. There are certainly some better options for this. Maybe it is even questionable whether allowing the user to specify the mime type is a good idea. The "view" > "view as" menu may be more related to bug 11521 comment #0 option a)
obAOL. In addition to unspecified types, there are a number of system (bugzilla among them) which allow user-specified file types, including for plain-text files. Again, the option to simply view these in the browser without going through the intermediary steps of savign to disk, locating said file, and opening in another app, would be useful.
*** Bug 349061 has been marked as a duplicate of this bug. ***
in bug #349061, I suggested that this be the default behaviour, and no dialog box be popped up for text/*.
*** Bug 349548 has been marked as a duplicate of this bug. ***
> When downloading a file from a broken server or script which does not issue > content-types correctly (or not at all) Firefox will display the "Open" dialog, > giving "Open with" or "Save to disk" as the options. Even if the server reports the MIME type correctly, Firefox refuses to render many text/something files as text; for example text/x-csrc for C code or text/x-tex for TeX files. Opera provides "Open in Browser" as an option; so should Firefox.
Isn't this a dup of bug 57342?
(In reply to comment #15) > Isn't this a dup of bug 57342? No it isn't. bug 57342 is for the backend part while this bug is the UI/frontend.
I need "open in browser" working ! , I hope this is not another stupid security reason
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
You need to log in before you can comment on or make changes to this bug.