Open
Bug 196078
Opened 21 years ago
Updated 8 months ago
Browser should render unrecognized text/* as text/plain
Categories
(Firefox :: File Handling, defect)
Firefox
File Handling
Tracking
()
NEW
People
(Reporter: braden, Unassigned)
References
Details
User-Agent: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20030131 RFC 2046, 4.1 says of the "text" type: In the absence of appropriate interpretation software, it is reasonable to show subtypes of "text" to the user, while it is not reasonable to do so with most nontextual data. Unless the user has associated it with an application, or elected to save it to disc by default, the browser should display arbitrary text/* types as text/plain. Reproducible: Always Steps to Reproduce:
![]() |
||
Comment 1•21 years ago
|
||
The problem with this is that the user then has no good way to associate the content to an application. It would make more sense, imo, to implement "view in browser as text" as a way to handle an arbitrary MIME type and then let users set it as needed.
That would be better than the current situation, but suboptimal in that it would present the user with a dialog in a number of cases where a dialog should be avoided (that is, cases where it is overwhelmingly likely that the user would prefer to see the content in the browser by default). Isn't browser handling of a type already overridden by the presence of a helper app entry for that type?
![]() |
||
Comment 3•21 years ago
|
||
All the common text/* types that we don't already render as text/plain are not something the user wants to see by default (text/rtf is the only one I can think of). And no, a helper app does not currently override internal handling. Furthermore, the architecture to do it is not in place and putting it in place would also allow the "view in browser" option. Note that once a user selects to open a type in the browser, the decision would get remembered, so the only difference is that the user gets explicit UI once to decide on a course of action.
Comment 4•20 years ago
|
||
*** Bug 216935 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: asa → file-handling
Component: Browser-General → File Handling
QA Contact: asa → ian
Comment 5•20 years ago
|
||
*** Bug 215706 has been marked as a duplicate of this bug. ***
Comment 6•20 years ago
|
||
*** Bug 108313 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 7•20 years ago
|
||
Note that if we _really_ decided to do this it would be doable with a stream converter (and a little magic in URILoader to look for stream converters by major/*, which I think we may want anyway).
Comment 8•20 years ago
|
||
of course stream converters have the issue that they cause a "wrong" type to be reported on the channel, so document.contentType and page info will have a wrong type. maybe nsIChannel needs an "readonly attribute ACString originalContentType" attribute? (well, a new nsIChannel2 of course)
Comment 9•20 years ago
|
||
Two extremely frustrating examples of this bug for me are text/x-chdr and text/x-csrc. I have a directory tree full of source code that was intended to be web browsable; however, whenever I try to open links to individual source files, an dialog box pops up that wants to open a freaking terminal window so it can page the files through less!! The dialog box (which ideally wouldn't pop up by default) should at least have an option saying "please render this internally".
![]() |
||
Comment 10•19 years ago
|
||
Brandon, that's covered by a different bug.
Comment 11•19 years ago
|
||
(In reply to comment #1) > It would make more sense, imo, to implement "view in browser as text" as a way > to handle an arbitrary MIME type and then let users set it as needed. I'd certainly like to see that option. I had assumed such a thing would already exist, and spent quite a while looking for it. An alternative approach would be "treat this MIME type exactly as you would this other type", which would be (marginally) more generally useful. It would probably be unreasonable to attempt to refine it further, to restrict such mappings to particular domains to cope with (say) a particular JPEG being presented as an application/octet-stream. Hugo
Comment 12•19 years ago
|
||
I think this should be marked a duplicate of bug 57342.
Comment 13•19 years ago
|
||
No, it should not. This bug is specifically aimed at all 'text/*' MIME types, which should be treated as described in comment 0 and not different from that.
Comment 14•17 years ago
|
||
This bug has been reported by Ubuntu users, at https://launchpad.net/distros/ubuntu/+source/firefox/+bug/39136 I investigated the code and the fundamental problem seems to be the use of mCategoryManager->GetCategoryEntry("Gecko-Content-Viewers",aContentType, ) throughout the code whenever we want to use the Gecko renderer for a type, or check that Gecko can handle it. It's tempting to replace all of these calls with a new function which would do the special handling of unknown text/* types. But I'm not sure that that's correct; in particular, it might make known external text/<something> types malfunction. So, I'm not sure what needs to be done. For the avoidance of doubt, I agree 100% with the reporters statement in comment 0, and with Brandon Hall's in comment 9. Boris Zbarsky's comments that "All the common text/* types that we don't already render as text/plain are not something the user wants to see by default" is missng the point. Sites and applications are free to invent new text/x-* types and RFC2046 says that we should treat those as text/plain if we don't recognise them. Mozilla is never going to be able to have a complete list of these text/* types and it is futile to try. Instead, the logic as required by RFC2046 should be implemented.
Comment 15•16 years ago
|
||
(In reply to comment #9) > be web browsable; however, whenever I try to open links to individual source > files, an dialog box pops up that wants to open a freaking terminal window so it > can page the files through less!! Not really; after I accept, the script text gets appended to .xsession-errors. Quite funny.
Comment 17•14 years ago
|
||
In both Firefox 3.5 and Firefox 3.0, I get prompted to open text/* unknowns in my default text editor. I got the same result in a 3.6 build from a few days ago. Just wanted to poke the bug to see if anyone would like to work on this as it's been over a year since the last comment.
Updated•14 years ago
|
Assignee: file-handling → nobody
QA Contact: ian → file-handling
See Also: → https://launchpad.net/bugs/39136
Comment 18•9 years ago
|
||
We could show the text along with an infobar that allows opening in a helper app.
Updated•7 years ago
|
Product: Core → Firefox
Version: Trunk → unspecified
Updated•8 months ago
|
Severity: normal → S3
Comment 20•8 months ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates and 16 votes.
:Gijs, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 21•8 months ago
|
||
The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.
Flags: needinfo?(gijskruitbosch+bugs)
You need to log in
before you can comment on or make changes to this bug.
Description
•