196078 - Browser should render unrecognized text/* as text/plain

Status: RESOLVED FIXED

(Firefox :: File Handling, defect)

Description

[Braden]

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

[Boris Zbarsky [:bzbarsky]]

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.

Comment 2

[Braden]

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

[Boris Zbarsky [:bzbarsky]]

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

[Matthias Versen [:Matti]]

*** Bug 216935 has been marked as a duplicate of this bug. ***

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 215706 has been marked as a duplicate of this bug. ***

Comment 6

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 108313 has been marked as a duplicate of this bug. ***

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Brandon Hall]

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

[Boris Zbarsky [:bzbarsky]]

Brandon, that's covered by a different bug.

Comment 11

[Hugo van der Sanden]

(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

[David]

I think this should be marked a duplicate of bug 57342.

Comment 13

[Anne (:annevk)]

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

[Ian Jackson]

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

[Christopher Yeleighton]

(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

[Micah Gersten]

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.

Comment 18

[Jesse Ruderman]

We could show the text along with an infobar that allows opening in a helper app.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 21

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.

Comment 23

[divinity76]

@BugBot it is still relevant.

@Boris quote

text/rtf is the only one I can think of

When I get served "Content-Type: Text/x-php; charset=utf-8" or "Content-Type: Text/x-python; charset=utf-8"
Or similar, I don't want to download it, I want to see it. Then I might press Ctrl+S or Ctrl+A if I actually want to download it.
Chrome and Edge understand this. Firefox doesn't. And that is annoying.

Comment 24

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 196078 - Part 1: Remove duplicate gXMLTypes check from nsContentDLF, r=smaug!

This was a typo introduced in bug 1209658. Previously the code would be
checking gXULTypes. Support for XUL documents has since been removed from
Gecko, so the code is no longer necessary.

Depends on D211797

Comment 25

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 196078 - Part 2: Support displaying arbitrary text/* MIME types as plain text, r=smaug!

This patch refactors how we check for text formats when deciding how to handle
resources, such that more text MIME types will be rendered in-browser, rather
than downloaded.

This change requires us to move more away from using the Gecko-Content-Viewers
category in the category manager for this decision, as we need to handle an
unlimited number of MIME types behind the scenes.

Support for Gecko-Content-Viewers was left in for both the in-tree use for
application/http-index-format and dynamically determining whether image/avif
and image/jxl are supported, as well as for the message/rfc822 type used by
Thunderbird.

Depends on D212077

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0582d2fa1401
Part 1: Remove duplicate gXMLTypes check from nsContentDLF, r=smaug
https://hg.mozilla.org/integration/autoland/rev/6a54aa5039e7
Part 2: Support displaying arbitrary text/* MIME types as plain text, r=smaug,necko-reviewers,valentin

Comment 28

[Norisz Fay [:noriszfay]]

Backed out for causing wpt failures on report-frame-ancestors-with-x-frame-options.sub.html

Backout link

Push with failures

Failure log

Comment 29

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 196078 - Part 3: Remove failing test expectations from WPTs, r=smaug!

These tests appear to have been previously failing as we would download
the resources being fetched due to their MIME type, rather than
rendeirng them in-browser, meaning that the reporting would behave
differently.

The change to support arbitrary text/ MIME types appears to have fixed
this, and now the tests pass as expected.

Depends on D212078

Comment 30

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d27cc29306db
Part 1: Remove duplicate gXMLTypes check from nsContentDLF, r=smaug
https://hg.mozilla.org/integration/autoland/rev/bb75ae2ebc94
Part 2: Support displaying arbitrary text/* MIME types as plain text, r=smaug,necko-reviewers,valentin
https://hg.mozilla.org/integration/autoland/rev/b0e051062dfb
Part 3: Remove failing test expectations from WPTs, r=smaug

Comment 31

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/d27cc29306db
https://hg.mozilla.org/mozilla-central/rev/bb75ae2ebc94
https://hg.mozilla.org/mozilla-central/rev/b0e051062dfb

Comment 32

[Ryan VanderMeulen [:RyanVM]]

Is this worth calling out in the Fx128 relnotes?

Comment 33

[Nika Layzell [:nika] (ni? for response)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)

Is this worth calling out in the Fx128 relnotes?

Yeah, this is probably worth calling out in the release notes.

Comment 34

[Nika Layzell [:nika] (ni? for response)]

Release Note Request (optional, but appreciated)
[Why is this notable]: Change to what types of text documents will render within Firefox, rather than being downloaded.
[Affects Firefox for Android]: Yes
[Suggested wording]: Firefox now supports rendering more text/* file types inline, rather than requiring them to be downloaded to be viewed.
[Links (documentation, blog post, etc)]: N/A

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx128 relnotes.