firefox should render unrecognized text/* as text/plain

Bug #39136 reported by Euan MacGregor
22
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Unknown
firefox (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

The current program suggested to view certain filetypes (e.g. text/x-debian-source-package as send when visiting http://librarian.launchpad.net/1788684/usplash_0.1-33.dsc) is less. Perhaps gedit would be a more sensible choice?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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.

Revision history for this message
In , Braden (braden) wrote :

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?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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.

Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Revision history for this message
In , Christian Biesinger (cbiesinger) wrote :

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

Revision history for this message
In , Christian Biesinger (cbiesinger) wrote :

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

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

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).

Revision history for this message
In , Christian Biesinger (cbiesinger) wrote :

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)

Revision history for this message
In , Mozilla-org-milkbadger (mozilla-org-milkbadger) wrote :

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".

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

Brandon, that's covered by a different bug.

Revision history for this message
In , Hugo van der Sanden (hugovds) wrote :

(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

Revision history for this message
In , David Reiss (davidn) wrote :

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

Revision history for this message
In , Annevankesteren+mozilla (annevankesteren+mozilla) wrote :

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.

Revision history for this message
Euan MacGregor (e-r-macgregor) wrote : "less" is not a sensible default for viewing things

The current program suggested to view certain filetypes (e.g. text/x-debian-source-package as send when visiting http://librarian.launchpad.net/1788684/usplash_0.1-33.dsc) is less. Perhaps gedit would be a more sensible choice?

Revision history for this message
Matt Zimmerman (mdz) wrote :

Surely any unrecognized text/* types can simply be viewed internally in firefox? Ian?

Revision history for this message
In , Ian Jackson (iwj) wrote :

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.

Revision history for this message
Ian Jackson (ijackson) wrote : Re: "less" is not a sensible default for viewing things

I agree completely with the report. The current behaviour is absurd. However, I've looked at the code and this is not at all easy to fix.

See my comments in the upstream bug, https://bugzilla.mozilla.org/show_bug.cgi?id=196078

Changed in firefox:
status: Unconfirmed → Confirmed
Revision history for this message
Andrew Ash (ash211) wrote :

Can confirm still exists in Edgy Final, Firefox 2.0

Revision history for this message
Alexander Sack (asac) wrote :

its confirmed upstream. Marking as 'In Progress'

Changed in firefox:
assignee: nobody → mozillateam
status: Confirmed → In Progress
David Farning (dfarning)
Changed in firefox:
assignee: mozillateam → mozilla-bugs
Revision history for this message
era (era) wrote :

Just a quick note that bug #25830 is very similar. I don't think they should be merged, but half the time, I end up picking the wrong one from my subscribed bugs, so having a link here that one can click to be taken to the other one seems useful.

Revision history for this message
In , Christopher Yeleighton (giecrilj) wrote :

(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.

Revision history for this message
In , Kevin Brosnan (kbrosnan) wrote :

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

Alexander Sack (asac)
Changed in firefox:
assignee: mozilla-bugs → nobody
status: In Progress → Triaged
Revision history for this message
In , Mozilla-bugs-micahscomputing (mozilla-bugs-micahscomputing) wrote :

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.

Revision history for this message
Micah Gersten (micahg) wrote :

Firefox 2 is EOL. Moving tracking to FF3 and FF3.5

Changed in firefox (Ubuntu):
status: Triaged → Won't Fix
Changed in firefox-3.5 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
Micah Gersten (micahg) wrote :

Confirmed behavior in FF3.0, FF3.5, and FF3.6 daily. Updated upstream.

Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
era (era) wrote :

Perhaps as an intermediate partial workaround Ubuntu could ship with Open In Browser as a standard extension? http://www.spasche.net/openinbrowser/

Revision history for this message
Micah Gersten (micahg) wrote : Re: [Bug 39136] Re: firefox should render unrecognized text/* as text/plain

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You could file a packaging request for that extension if you wish. We
do not generally ship extensions as standard with Firefox, but provide
them as an option in the repositories.

era wrote:
> Perhaps as an intermediate partial workaround Ubuntu could ship with
> Open In Browser as a standard extension?
> http://www.spasche.net/openinbrowser/
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqLjtwACgkQTniv4aqX/VnOKACeJsgr+SWOZoM7+SWi8lxQ53G3
aAAAn2hwBWNNE6o9z/r3jZsIHk4JJhOV
=RAQ0
-----END PGP SIGNATURE-----

Revision history for this message
era (era) wrote :

@Micah Gersten: While having the extension packaged would be a good start, that would fail to fix the problem that the usability of Firefox out of the box is broken on Ubuntu in this respect.

Do you think ubufox could be set up to depend on this extension if it were available in the repositories? Or is there some other way to fix the problem for all users in an unintrusive way?

Revision history for this message
Micah Gersten (micahg) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

@era

The best way is to get it fixed upstream. If we can't do that, and
this extension solves a known problem that the team feels affects
enough users, we could suggest installation of the extension. The
first thing though would be to get it packaged. If you'd like to
discuss this further, please join us in #ubuntu-mozillateam on
Freenode IRC.
Thanks.

era wrote:
> @Micah Gersten: While having the extension packaged would be a good
> start, that would fail to fix the problem that the usability of Firefox
> out of the box is broken on Ubuntu in this respect.
>
> Do you think ubufox could be set up to depend on this extension if it
> were available in the repositories? Or is there some other way to fix
> the problem for all users in an unintrusive way?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkqNb0oACgkQTniv4aqX/VmMdACePB1Jlq7mjF1b3wBBm90PjU0j
ukYAnRG9GbM2Utu02mAYJzjOeuLuDPA2
=+w70
-----END PGP SIGNATURE-----

Revision history for this message
John Vivirito (gnomefreak) wrote :

Sorry but Firefox-3.0 has reached EOL and will not receive anymore updates. Can you please confirm if this happens on Firefox-3.5 still.
Upstream has been unable to confirm this bug.
Changing package to be Firefox-3.5 until it is confirmed either way

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
John Vivirito (gnomefreak) wrote :

Sorry but Firefox-3.0 has reached EOL and will not receive anymore updates. Can you please confirm if this happens on Firefox-3.5 still.
Upstream has been unable to confirm this bug.

Revision history for this message
John Vivirito (gnomefreak) wrote :

It has been decided to release 3.0.18

Changed in firefox-3.0 (Ubuntu):
status: Won't Fix → Triaged
Revision history for this message
era (era) wrote :

> Upstream has been unable to confirm this bug.

What do you mean by that? The upstream status is NEW and Launchpad displays it as Confirmed in the upstream bug tracker, as I believe it should.

Revision history for this message
John Vivirito (gnomefreak) wrote :

Era, When i posted the above it was set as new not confirmed (upstream bug)

Revision history for this message
era (era) wrote :

It is indeed still "NEW" upstream. According to https://bugzilla.mozilla.org/page.cgi?id=fields.html#status this means it's confirmed (it's UNCONFIRMED until somebody changes it to NEW).

I'm just wondering if I'm missing something here; there has been no recent change to the upstream bug's status as far as I can tell, or else Launchpad is not showing the full transcript of changes at https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/39136/+activity

Changed in firefox:
importance: Unknown → Medium
no longer affects: firefox-3.0 (Ubuntu)
no longer affects: firefox-3.5 (Ubuntu)
Changed in firefox (Ubuntu):
status: Won't Fix → Triaged
importance: Medium → Wishlist
Revision history for this message
In , Jruderman (jruderman) wrote :

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

Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
Revision history for this message
In , Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote :

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

Changed in firefox:
importance: Medium → Unknown
Revision history for this message
In , Release-mgmt-account-bot (release-mgmt-account-bot) wrote :

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](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

Revision history for this message
In , Autonag-nomail-bot (autonag-nomail-bot) wrote :

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.

Revision history for this message
In , Gijskruitbosch+bugs (gijskruitbosch+bugs) wrote :

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

Revision history for this message
In , hanshenrik (hanshenrik) wrote :

@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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.