Option to display file in browser, treat as text/plain

Bug #25830 reported by Martin Flack
40
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Unknown
firefox (Ubuntu)
Triaged
Wishlist
Unassigned

Bug Description

A suggestion:

When you click certain files, like .py or .pl files, for example, Firefox brings
up a dialog that offers you the ability to:
1. Open with a certain application
2. Save to disk
What would be nice is a third option:
3. Treat as text/plain

The wording could be altered... "Display as text in browser" or something.

Sometimes you just want to quickly visit a file on the web and look for
something in it, and the fact that you *could* open it in a more customized
application is true but not really easier for you at that moment. If you just
want to look a Python script for a version number at the top it is not necessary
to open it in your IDE or save it to disk; you just want to open it in the
normal viewing window as plain text and quickly find what you need to look at.

Revision history for this message
In , Leger-formerly-netscape (leger-formerly-netscape) wrote :

Updating QA Contact.

Revision history for this message
In , Don-formerly-netscape (don-formerly-netscape) wrote :

Move to M20.

Revision history for this message
In , Paulmac (paulmac) wrote :

updating qa contact

Revision history for this message
In , Don-formerly-netscape (don-formerly-netscape) wrote :

Move to "Future" milestone.

Revision history for this message
In , Asa (asa) wrote :

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

Revision history for this message
In , pohl (pohl-longsine) wrote :

It appears that there is no way to tell mozilla to display documents of type
text/* (other than text/plain) to display right in the browser window. I would
like to browse source code files (text/x-java, for example) right in the browser,
but instead I am presented with an open-using/save panel. Neither of these two
options is the desired choice. I could not find a way to tell mozilla to treat
text/x-java the same way it treats text/plain.

Revision history for this message
In , Asa (asa) wrote :

over to XPApps

Revision history for this message
In , Gervase Markham (gerv-mozilla) wrote :

<email address hidden> - you couldn't point us at a URL served as text/x-java or
similar, could you?

Which bits of UI have you looked in to find how to set this, and where would you
expect such a function to be?

Gerv

Revision history for this message
In , pohl (pohl-longsine) wrote :

http://screaming.org/~pohl/ServletWithCache.java

The above link should be a suitable example. As for where the function should
be, my instincts led me to the
Edit-->Preferences-->Navigator-->HelperApplications where I attempted to add a
mapping for ".java" of type text/x-java. In the panel where you "add" or "edit"
the mapping, I would imagine that there would be a checkbox (for text/* types)
that says "display within browser window", and perhaps checking this checkbox
would also disable the widgets for selecting the helper application.

Revision history for this message
In , pohl (pohl-longsine) wrote :

In addition to a checkbox in the edit/add panel, perhaps there should be a
settable default in the HelperApplications panel itself that says something to
the effect of "by default, documents of type text/* should be (*) displayed
within the browser (*) saved to disk" with radio-buttons to select. them.

Revision history for this message
In , Vishy (vishy) wrote :

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
 Vishy

Revision history for this message
In , Bugzilla-iwaruna (bugzilla-iwaruna) wrote :

pardon the spam: reassigning these remaining xp apps bugs of don's to vishy for
the time being. hope that's okay!

Revision history for this message
In , Verbal-myrealbox (verbal-myrealbox) wrote :

Changed summary. Marking as NEW so someone will either mark it as WONTFIX or
INVALID.

Revision history for this message
In , pohl (pohl-longsine) wrote :

Keyser Sosez!? He's comming for me! Ok, levity aside, is there a reason this
shouldn't be addressed? WONTFIX and INVALID seem premature.

Changed severity to "enhancement".

Revision history for this message
In , Paulkchen (paulkchen) wrote :

nav triage team:

Yes, WONTFIX and INVALID seem a bit much. We'll just keep it in the database for
eons. ;-) Very nice to have, but don't think we'll have time to get to this for
beta1, marking nsbeta1-

Revision history for this message
In , Paulkchen (paulkchen) wrote :

nav triage team:

Too much work to support translation between media types and do it well, not
going to get to this for beta1, marking nsbeta1-

Revision history for this message
In , Jps (jps) wrote :

I believe the logic that controls this kind of thing is presently
in: uriloader/exthandler/nsExternalHelperAppService.cpp

I also believe that profile/defaults/mimeTypes.rdf has fields that
may or may not allow for this already, but I don't know because even
after asking for several months that database has not yet been
documented. Sigh.

Revision history for this message
In , Sfraser-bugs (sfraser-bugs) wrote :

Does the underlying functionality exist? Editor needs to be able to tell .js
files to be loaded as text, for example, so that we edit them like text files
(since they are UTF-8 and many text editor can't deal with that).

How hard would it be to override the document's MIME type some time early in the
loading process?

Revision history for this message
In , Matty-is-a-geek (matty-is-a-geek) wrote :

Can someone in the know say if there is anything here that requires API changes
that should be nominated as needing to be in before Mozilla 1.0?

Revision history for this message
In , Benc-frame (benc-frame) wrote :

This would be a very useful feature, because (shamefully), it would make it
easier for http server administrators to verify they selected the right MIME
type w/o repeatedly reconfiguring their server...

Revision history for this message
In , Paulkchen (paulkchen) wrote :

Marking nsbeta1- bugs as future to get off the radar

Revision history for this message
In , Jps (jps) wrote :

This is longstading default behavior, to map text/[unknown type]
to text/plain -- this is NOT a feature request! Please put it
back on the radar. Thank you!

Revision history for this message
In , Jps (jps) wrote :

Another thing: should this be assigned to <email address hidden> (Boris Zbarsky)
since he is working on bug 52441?

Revision history for this message
In , Jps (jps) wrote :

Boris: please read this one. Thank you!

Saruh: I am unable to change the "enhancement" and "future"
fields (that might be a good thing ;-) but not in this case.)
Would you please? Also please change the summary to
"default unrecognized text/* types as text/plain" from
"Allow arbitrary MIME types to be treated as plain text"
Thank you!

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

jps: This bug doesn't seem to relate to that bug. So no, unless bz wants this
bug it shouldn't be forced on him.

Since vishy isn't interested, i'll try an alternative tact: Ask for suggestions
about a UI. Once we get a UI spec we can ask someone to implement it.

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

There's a comment in bug 52441 about giving the helper app dialog a "show in
browser" option. I feel that that would be the best thing to do with this as
well. I agree with timeless -- we should decide on a UI for this before
implementing anything.

I may poke around a bit at the back end to see what's feasible (I don't know
whether the external handler service can call back into the browser to display
stuff in the browser window....)

mpt? Thoughts?

Revision history for this message
In , Matthew Paul Thomas (mpt) wrote :

Yes -- once we replace the current Unknown Type alert with one that uses
buttons for commands (avoiding the unfortunate use of radiobuttons as
commands), those buttons could be:

(Save As ...) (View as Text) ( Cancel ) ((Open With...))

Revision history for this message
In , Timeless-bemail (timeless-bemail) wrote :

And what if someone wants to view a document as html or xml? [this is actually
a real need since many webservers manage to mess up user's mime types]

I suppose (View as ...) would work. (Treat as ...) might also [but someone
will say they don't know what treat means, well... you don't view sound so ...
Handle as ...?]

Revision history for this message
In , Matthew Paul Thomas (mpt) wrote :

There's a certain point where you have to just give up and make the user do a
bit more work (in this case, save the file with .html extension and open it
locally), rather than trying to handle everything in the alert. Having `Handle
As ...' would be annoyingly incomprehensible for the majority of users who saw
this alert regularly. Already, with `View as Text', we'd be offering them more
power than any other browser I've seen.

--> Networking

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

mpt, what's the bug for the new "Unknown Type" dialog?

I've poked a bit and all that needs to happen to "view as text" is the following:

1) reset the mime type to text/plain in the MIMEInfo
2) reset the preferred handler to nsIMIMEInfo::handleInternally

both can be done from Javascript (it's a scriptable interface) so this can be
done in the dialog without too much trouble in my opinion...

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

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

Revision history for this message
In , Robbe (robbe) wrote :

I one-shot solution (via the unknown type dialog) would be fine, but I'm more
interested in a permanent solution, i.e. an option in the preferences to always
show type "foo/bar" raw (as text).

I think mozilla should ship with an entry for text/* that has this option
enabled. Treating any text subtype that is not known as text/plain is actually
MIME standard behaviour. I don't consider that part an enhancement.

Example: http://people.debian.org/~jaqque/debian-issue.sh returns text/x-sh,
which mozilla should display as text.

Revision history for this message
In , Benc-meer (benc-meer) wrote :

If there is a snippet of MIME specs that shows that, please add it here.
It's futured, so we need a contributor if this is going to happen.

Revision history for this message
In , Jps (jps) wrote :

The "MIME specs" suggest that "Text" without a subtype should be
analyzed to determine if a multibyte set is in use. I don't know
whether there is a Unicode-aware version of file(1) aroud to peruse
the logic yet, but that is one place to start looking. Boris is also
correct that type specification should be requested when an unknown
type is encountered. So, I like this suggestion from <email address hidden>
(Martin Petricek) from duplicate bug 87301, quoted below --

When mozilla encounter unknow content-typ a dialog will appear:

[ ] use default action
[ ] use different action
   [ ] save to disk
   [ ] open with application _______

-It might be very useful to add something like-
   [ ] view as text/plain
  -- or --
   [ ] treat as [text/plain ]
 to the dialog (so i can force this to be either text/plain or text/html, etc
...)

and maybe add it also to preferences so this could be settable also as default
action
This will help to wiew content-types like netscape/proxy-autoconfig, etc ...
like plain text

Revision history for this message
In , Robbe (robbe) wrote :

I don't know what "specs" James is talking about. I was alluding to RFC2046.
Specifically, section 4.1. of that says:

   Beyond plain text, there are many formats for representing what might
   be known as "rich text". An interesting characteristic of many such
   representations is that they are to some extent readable even without
   the software that interprets them. It is useful, then, to
   distinguish them, at the highest level, from such unreadable data as
   images, audio, or text represented in an unreadable form. 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. Such formatted textual data should be
   represented using subtypes of "text".

Later, in 4.1.4:

   Unrecognized subtypes of "text" should be treated as subtype "plain"
   as long as the MIME implementation knows how to handle the charset.
   Unrecognized subtypes which also specify an unrecognized charset
   should be treated as "application/octet-stream".

My take is that, when encountering "text/my-doc-format; charset=us-ascii", to be
compliant, Mozilla must allow display of this as if it were text/plain. It
should (IMHO) treat text/xyz with a missing charset as if charset were UTF-8
(this makes most cases work), and it should allow MIME types other than text/*
to be displayed raw, if that isn't much work.

Revision history for this message
In , Tpowellmoz (tpowellmoz) wrote :

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

Revision history for this message
In , Matthew Paul Thomas (mpt) wrote :

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

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

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

Revision history for this message
In , Jmd (jmd) wrote :

I can't view any of the text files on:

http://www.samba.org/ftp/unpacked/netfilter/userspace/extensions/

This is quite bad.

Doesn't it make sense to display text/<unknown> as text/plain? The files on that
page are all served as text/x-csrc. I had to save a bunch to disk and use a
console to view them.

Revision history for this message
In , Jmd (jmd) wrote :

Fixing summary or I'll never be able to find this bug again.

Ian Jackson (ijackson)
Changed in firefox:
assignee: ijackson → nobody
Changed in firefox:
assignee: nobody → mozillateam
Changed in firefox:
status: Unconfirmed → Needs Info
David Farning (dfarning)
Changed in firefox:
assignee: mozillateam → mozilla-bugs
Changed in firefox:
assignee: mozilla-bugs → asac
Alexander Sack (asac)
Changed in firefox:
status: Needs Info → In Progress
Changed in firefox:
status: Unknown → In Progress
Alexander Sack (asac)
Changed in firefox:
assignee: asac → mozilla-bugs
Alexander Sack (asac)
Changed in firefox:
assignee: mozilla-bugs → nobody
status: In Progress → Triaged
Changed in firefox-3.0:
importance: Undecided → Wishlist
status: New → Triaged
189 comments hidden view all 269 comments
Revision history for this message
In , Joekjunction-forums (joekjunction-forums) wrote :

With regards to Marks comments (Comment #185) I am not a software programmer. I design web sites and if ever I have encountered problems similar to this, I have always taken the time to resolve them, both to the customers satisfaction and because I take pride in my work. If you are a firefox programmer Mark, then you are one of those people who are to blame for the eventual demise of firefox and I hope that one day this realisation will hit you fully and that it may do so in a way which will force you to see how crass and childish your comments are.

As mentioned above (Comment #186 From Eyal Rozenberg) Firefox is owned by a huge corporation with so much money that it can afford to fix such annoying problems and the fact that even after complaining about this bug and having my original complaint, first dismissed as stupid (and said to be my fault, because apparently I didn't understand how web browsers work) and secondly when it was deleted with no reasons given for the deletion, simply shows how such huge corporations disrespect their users and prioritise their own aims before those of the people who actually use their products.

I would also like to add that I supported firefox from the day I discovered it, this after being an avid fan of IE for many years. Then I started web design, after which I discovered the shortcomings of IE and from that day, through my various web sites and through word of mouth, I have convinced many people to switch to firefox in the belief that here was a web browser being developed by ordinary people for ordinary people.

Marks comments above illustrate exactly the kind of attitude which puts users off badly programmed software and this is just an additional reason for my looking to switch over to Opera.

Additionally, I dislike the fact that over the years I have seen many good ideas and suggestions for improvements to Firefox dismissed as unecessary, or too time consuming and I do not think that I want to be a part of a project which does not accept new ideas, or innovations as seriously as it should.

I still have to use firefox for development purposes and I will admit that I think it has a lot of great functions which are missing from most of the other browsers and that I will miss it and the firefox community.

I wish you all the very best for the future and hope that someone who takes pride in their work eventually resolves this problem, but sadly, I do not think that I will be a firefox user long enough to see that day.

Revision history for this message
In , Robert (robrwo) wrote :

Apologies in advance for more bugspam, but I have some additional points to make:

(In reply to comment #183)
> Now when you read my comments, I want you to take them on board, because I
> speak for the whole firefox users community....

Actually, you don't.

> Bugs like these should have been resolved a long time ago ...

Why should the bug have been resolved a long time ago? It's not affecting most users, not causing systems to crash, deleting data, etc.? At most it's an annoyance with a workaround (and perhaps a plugin).

Indeed, if you read the history of the bug, it wasn't initially clear *how* to fix it. The Add "View as..." option came about after some discussion.

And while it seems simple to fix for a non-programmer, web browsers are complex. There are still a couple of bugs that this bug depends on.

> My complaint is that jpeg files won't just open in firefox, even though they
> can and are opened in firefox when I tell the stupid dialog box to just open
> the damned thing in firefox. And yes I have set firefox as the default handler
> for jpeg files and no the file isn't cymk.

Whoa! That's a different bug altogether. So file a different bug. And give useful details, like what operating system, and links to or attachments of example jpeg files that are problematic.

> I can't believe how lazy you people can be.

No, just busy with more important things.

> A bug that has been around for 9 years and not one can fix it. Says a lot for
> your programming skills eh. ...

"You catch more flies with honey than vinegar."

Revision history for this message
In , Timwi (timwi) wrote :

> Additionally, I dislike the fact that over the years I have seen many good
> ideas and suggestions for improvements to Firefox dismissed as unecessary, or
> too time consuming and I do not think that I want to be a part of a project
> which does not accept new ideas, or innovations as seriously as it should.

Yes, but this is nothing new. This is a general property of the open-source development model which is not going to improve soon. (http://mpt.net.nz/archive/2008/08/01/free-software-usability, see point #3)

Revision history for this message
In , Joekjunction-forums (joekjunction-forums) wrote :

Robert Rothenberg, you and small minded people like you, must enjoy picking apart peoples comments as opposed to fixing bugs.

When i say I speak for the majority of firefox users, I actually because as mentioned in my previous post I have lots of customers and friends and family to whom I recommended firefox and they too encounter the same problem and the only reason they do not complain is because they are not technically minded, or do not feel confident enough discussing such matters, as do most ordinary firefox users.

Bugs like these should have been resolved a long time ago because as mentioned, I reported this very same problem over 7 years ago and again as mentioned in my previous post, it was deleted and another egotistal programmer simply dismissed it and deleted the bug I reported.

With regard to this bug not being the same bug, it might not be, but no one else has protested about it and it is a mime type bug which has the same kind of problem as the other file types mentioned here.

It is affecting users and whilst it does not crash tthe browser, we users don't want to waste our time clicking on silly dialog boxes because of faulty functionality which LAZY programmers like you cannot be bothered to fix because you want to go watch porn or whatever you call important.

I too have done some programming and I know that problems like these arise from bad coding practices which haven't been corrected. BTW this features works fine in every other web browser that I have used and I don't need to click on a single dialog box to view a jpeg file (as opposed to a jpg file). Now if you consider that unimportant then obviously you don't have the intellectual capacity to grasp what I am saying.

Using stupid qutoes doesn't alter the fact that this BUG has been around for as long as firefox has been in existence and well, if you cannot be bothered to fix such problems, then obviously you can't be all that good a programmer, so what the hell are you doing being involved in such a project if its beyond your capabilities.

People with attitudes like yours should not be involved in projects like these because your incompetance causes mroe problems in the long run and the manifestation of that is a long list of faults which we users have had to endure, but no more thanks to opera. And I think that the 100's of thousands of readers of my web sites will agree with me, especially when I post your comments on my web sites, so they can see exactly how some firefox programmers instead of accepting constructive criticism, cry like a little baby and try to bad mouth their users.

One final word. If you cannot tolerate constructive criticims by a firefox user of long standing then I suggest you go back and hide under your mummys apron because all I have done is to express my anger and frustration at a bug which as mentioned I reported long ago and which nothing has as yet been done about.

Revision history for this message
In , Robert (robrwo) wrote :

Again, apologies for the bugspam....

(In reply to comment #191)
> Robert Rothenberg, you and small minded people like you, must enjoy picking
> apart peoples comments as opposed to fixing bugs.

Insulting people who do not agree with you will get you nowhere.

> When i say I speak for the majority of firefox users, I actually because as
> mentioned in my previous post I have lots of customers and friends and family
> to whom I recommended firefox and they too encounter the same problem ...
> ...
> With regard to this bug not being the same bug, it might not be, but no one
> else has protested about it and it is a mime type bug which has the same kind
> of problem as the other file types mentioned here....

Again, provide technical details about the bug (URLs, browser versions, operating system versions, etc.), so that it can be diagnosed, rather than ranting about how there is a problem that no one is fixing.

It doesn't seem to affect that many users. From your description, it seems to affect YOUR clients, so perhaps it is something YOU are doing: is the webserver returning the appropriate MIME type for the JPEG files?

> BTW this features works fine
> in every other web browser that I have used and I don't need to click on a
> single dialog box to view a jpeg file (as opposed to a jpg file). Now if you
> consider that unimportant then obviously you don't have the intellectual
> capacity to grasp what I am saying.

That could also mean that Firefox is behaving correctly and the other browsers are poorly implemented and ignoring an error.

> One final word. If you cannot tolerate constructive criticims ...

Your criticisms have not been constructive at all. They have been insults.

If you want to be constructive, provide some useful information about the specific problem you are having.

Revision history for this message
In , Simetrical+ff (simetrical+ff) wrote :

Could the people who should know better please stop saying "Sorry for the bugspam, but . . ." and then spamming everyone? If your sense of indignation at this user is such that you can't stand letting his claims go un-rebutted, try replying by e-mail.

(And yes, I'm not practicing what I preach, but several different people have been doing this here so far and probably more will even if I privately e-mail everyone who's done it so far.)

Revision history for this message
In , Reed Loden (reed) wrote :

I'd like to take this chance to remind everybody commenting lately of the Bugzilla Etiquette (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html) that governs this Bugzilla instance. Most of the recent comments in this bug have been in violation of one or more points in the Etiquette, and recent activity has started to generate a lot of complaints.

Please do not comment in this bug unless you're discussing how best to fix this bug, attaching a patch to fix it, or are doing sometime actually useful rather than making pointless bugspam that doesn't help anything. This is your *only* warning. Any future violations of the Bugzilla Etiquette will result in the disabling of the violating Bugzilla accounts. Bugzilla is not a forum for such comments. If you wish to rant, the newsgroups are the appropriate place for such comments, not Bugzilla. Again, this is your *last* and *only* warning.

Thank you for your time.

Revision history for this message
In , Torisugari (torisugari) wrote :

Basic designs are not solid, yet.

The problem is that users can close the original window (or tab) before
choosing some option in external-app dialog. This could causes multiple
bad results. It's okay to open it in a new tab, please think about such
a link:

<a href="unknown_mime.txt" target="my_target"> See the target. </a>

In this case, user may close "my_target" window before loading any
content into it. Gecko should force to open a new window nonetheless,
on user chosing "Handle inside Gecko"?

In summary, I think external-app window should be a modal dialog. Or
it needs a way to protect original DOM window, such as overlapping
bar or something like that.

Revision history for this message
In , Torisugari (torisugari) wrote :

Created an attachment (id=374753)
PoC modal dialog

Proof of concept.

You can see how simple the patch will be, if external-app dialog were modal.
And probably less buggy.

I don't think simpleness beats usability, as I get annoyed even with
HTTP password prompt. But, in my opinion, keeping it modeless is difficult,
for very the same reason why we don't have modeless password prompt.

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

There will not be any more fixes for Firefox 2.

Changed in firefox (Ubuntu):
status: Triaged → Won't Fix
Revision history for this message
In , Matti-mversen (matti-mversen) wrote :

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

Revision history for this message
In , Zug-treno (zug-treno) wrote :

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

Revision history for this message
In , Bryan-w-taylor (bryan-w-taylor) wrote :

Jason Duell, this has been assigned to you for almost six months. What is it about this bug? Why does it never get solved? I'm not asking to bitch, I just don't understand why it takes nine years to display files. The techncial solution has existed for three years as an addon:

https://addons.mozilla.org/en-US/firefox/addon/8207

While this bug is clearly not a data loss or security issue. I'm sure there are a few bugs out there that deserve higher priority. But as a user of firefox, my impression of 95% of the things that do get worked is that they should not have been chosen over this one. The addon above has demonstrated a viable technical solution, and has existed for three years. How about implementing it as is? If there are criticisms of it, how about implementing it anyway and dealing with improving it later?

It's fascinating how certain bugs like this one can have some kind of "group think" where a zombie like mental paralysis seems to descend and prevent common sense from prevailing. I'm not interested in denials, rebuttals, excuses, explanations. I just want to open files in my browser without having to install the "don't suck" addon.

Revision history for this message
In , Jruderman (jruderman) wrote :

I'm curious how the extension avoids the security issues that a naive implementation would have.

Revision history for this message
In , Jruderman (jruderman) wrote :

I filed bug 504441 for the security parts, which will probably want to be a separate patch anyway.

Revision history for this message
In , Sylvain Pasche (sylvain-pasche) wrote :

(In reply to comment #199)
> I'm curious how the extension avoids the security issues that a naive
> implementation would have.

Just to clarify, the extension doesn't protect users from malicious scripts when viewing documents as html. I'll see if I can do something like bug 504441 inside the extension, or maybe show a warning when viewing a mime type that runs scripts.

By the way, I noticed that Opera 10 doesn't protect the user from these kinds of security issues.

Revision history for this message
In , Abwillis1 (abwillis1) wrote :

I am not sure if this is still an issue but initially it seemed the technical issues involved were that there was no way to get back to the browser from the helper application. How about a different approach? I propose no UI but rather only have an option in about:config.
I am not sure of the correct section but something like:
browser.display_alltext_as_plain
default would be FALSE and exhibit current behavior but if changed to TRUE the browser just treats it as text/plain and never takes the external handler path.

Revision history for this message
In , Jsfbbz (jsfbbz) wrote :

(In reply to comment #202)
> issues involved were that there was no way to get back to the browser from the
> helper application. How about a different approach? I propose no UI but

Presumably the bit of code *within* firefox that deals with external helpers, since before the user has dismissed the unknown type dialog, the actual external helper can't possibly exist.

> rather only have an option in about:config.
> I am not sure of the correct section but something like:
> browser.display_alltext_as_plain

1) Even for types that look like plain text, I might not want this all the time. Sometimes I really want to view source code with an oddly specific mimetype in firefox with minimal fuss. Sometimes I happen to know the server is going to spew 50MB of ASCII machine logs out and really want it to go directly to the helper rather than wedge the layout engine for a minute.

2) This isn't a text-only issue. Only today I had firefox pop the dialog for a PNG image that was presumably incorrectly tagged. As I've pointed out before, the truly crazy thing is you can select firefox as the external helper and it will dutifully write it out to disk, launch firefox externally on the file, presumably it then uses dbus/DDE/some other equivalent method to pass the file back to the original firefox instance which then displays it just fine. However you've lost the original HTTP session context there: refreshing won't reload and certain other things look/behave differently. The final solution (ignoring any necessity of a dialog for user choice in the matter) should end up behaving exactly as if firefox had known what to do from the beginning.

Revision history for this message
In , Vincent+moz (vincent+moz) wrote :

(In reply to comment #203)
> 1) Even for types that look like plain text, I might not want this all the
> time. Sometimes I really want to view source code with an oddly specific
> mimetype in firefox with minimal fuss. Sometimes I happen to know the server is
> going to spew 50MB of ASCII machine logs out and really want it to go directly
> to the helper rather than wedge the layout engine for a minute.

This can also happen with text declared as text/plain, or even HTML.

Changed in firefox:
importance: Unknown → Wishlist
Revision history for this message
In , flying sheep (flying-sheep) wrote :

the extension „open in browser“ doesn’t work on local files (offering only „view source“)

the solution should work on those, too.

Revision history for this message
In , Michal Suchanek (hramrach) wrote :

(In reply to comment #201)
> (In reply to comment #199)
> > I'm curious how the extension avoids the security issues that a naive
> > implementation would have.
>
> Just to clarify, the extension doesn't protect users from malicious scripts
> when viewing documents as html. I'll see if I can do something like bug
> 504441 inside the extension, or maybe show a warning when viewing a mime
> type that runs scripts.
>
> By the way, I noticed that Opera 10 doesn't protect the user from these
> kinds of security issues.

Nor does Firefox, on any content that is HTML from the start or relabeled as such by the extension.

Revision history for this message
In , Me-shadsterling (me-shadsterling) wrote :

I suggested a more general solution in bug 185618 comment 61 (about adding an option to render content in Firefox whenever "Save As" comes up immediately).

I suggest using an error/info page for content of a type for which there is no handler or for content for which the handler fails, so anytime Save As comes up there is some content behind it. In the case of an unknown type, the error/info page would appear as a placeholder, which would prevent unknown types from cutting off user activity, and make room for a separate "Reinterpret Content" sheet with which the user could override the provided content-type to one which Firefox can render.

Changed in firefox (Ubuntu):
status: Won't Fix → Triaged
no longer affects: firefox-3.0 (Ubuntu)
Revision history for this message
In , sergiomb (sergio-sergiomb) wrote :

I need "open in browser" working ! , I hope this is not another stupid security reason

Revision history for this message
In , Alexander-stohr-5 (alexander-stohr-5) wrote :

i am using Waterfox 24.0 (64 bit build version of firefox) on Windows 7 x86 64 bits.

when visiting this page: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/tirtos/1_10_00_23/index_FDS.html
(might require a free account to view or download)
and downloading the windows version (*.exe) of the file set
then i can select any option for opening or saving including the "remember my decision" option.

but when going for the linux version i only get offered two options: open with an application (default here is VLC) or download but the "remember" button is grayed out.

for my impression the browser should be able to remember decisions for explicitly html/mime tagged file formats as already realized. but for for non-tagged or "wildcard"-tagged files and it shall be check for the file name extension (or absence of such an extension - this happens more often than you would think) and decide based upon that extension. so the browser needs not only a mime type default action configuration database/listing but an extension based handling if mime type is not that useable. maybe even the user can pass down certain mime types to the extension based treatment. thus the mime type layer should see a new option: "handle by file extension".

@Sergio - thats a nice proposal in that area. i can support that. its all about options.

BTW i think the dialog does not mention the mime type so i am a bit lost in diagnostics for that my faulty cases using purely the browser. the dialog should mention the mime-type he asks me about.

Revision history for this message
In , Alexander-stohr-5 (alexander-stohr-5) wrote :

Created attachment 8338461
screenshot of browser file reception dialog that has a grayed out "remember" item

Revision history for this message
In , Mozilla3 (mozilla3) wrote :

@Alexander: This bug is about adding a "View as text/HTML" option, not about the "do this automatically" checkbox. Try looking at bug 453455 or bug 561392 instead.

Revision history for this message
In , Ashundi (ashundi) wrote :

I see parity-opera tag -- you can add chrome as well. Content-Type: text/x-java-source are displayed there automatically as text whereas in FF I can only open with another app or save.

Revision history for this message
In , Stewart (smjg) wrote :

But can Chrome view arbitrary unknown MIME types as text, or just text/* types, or does it just know about some specific MIME types such as this?

Revision history for this message
In , Vincent-moz (vincent-moz) wrote :

Even if Firefox was improved to support unknown text/* types (viewed as text/plain), this would be a great improvement. Almost all files that I can't view directly in Firefox due to this bug have a text/* type.

Revision history for this message
In , Francis-uy (francis-uy) wrote :

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

Revision history for this message
In , Jonathan Watt (jwatt) wrote :

Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)

Revision history for this message
In , Michael Lippert (mlippert255) wrote :

Addressing this issue would help a lot of power users. I think all that's needed is the capability to set somewhere (even about:config) that all unknown text/* types should be handled as internally as text/plain.

Currently I have to use Chrome w/ an extension to render a markdown file from my local filesystem. It is loaded w/ the appropriate mime type: text/markdown which according to this stackoverflow (https://stackoverflow.com/questions/10701983/what-is-the-mime-type-for-markdown) was registered as RFC7763 in March of 2016.

There is at least one firefox extension which will render a markdown file. but it never gets that far, firefox only gives the options to download or to specify an external application for the file.

There are other text/* types that it would be really nice if they were just viewable in the browser rendered as text/plain, such as those for source files (text/x-c, text/x-java-source, ...). On my system the mime type is also associated w/ the list of applications I select from in the file manager to open those files, so I want to be able to distinguish them from one another (I want to open markdown files with different applications than js source files or script files for example). I mention this because one workaround suggested was just to tag markdown files as text/plain, but I'd rather continue to use Chrome than lose the ability to distinguish the files in the file manager.

Changed in firefox:
importance: Wishlist → Medium
status: In Progress → Confirmed
1 comments hidden view all 269 comments
Revision history for this message
In , Stewart (smjg) wrote :

(In reply to Michael Lippert from comment #217)
> Addressing this issue would help a lot of power users. I think all that's needed is the capability to set somewhere (even about:config) that all unknown text/* types should be handled as internally as text/plain.

I disagree. It's only natural that sometimes the user will want to save the file to disk, sometimes the user will want to open the file in an external application, and sometimes the user will want to view the file in the browser. Why should we force the user to choose on an all-or-nothing basis, and moreover restrict it to text/* types?

> There are other text/* types that it would be really nice if they were just viewable in the browser rendered as text/plain, such as those for source files (text/x-c, text/x-java-source, ...).

Indeed, Moreover, there are many text-based file formats out there - not just those that have text/* MIME types (e.g. application/xml, and apparently application/javascript and application/json exist as well).

> On my system the mime type is also associated w/ the list of applications I select from in the file manager to open those files, so I want to be able to distinguish them from one another (I want to open markdown files with different applications than js source files or script files for example). I mention this because one workaround suggested was just to tag markdown files as text/plain, but I'd rather continue to use Chrome than lose the ability to distinguish the files in the file manager.

What kind of "system" is this - an operating system, or a website with an associated file manager?

The MIME type is for specifying what kind of file it is, not what the user agent is to do with it. We shouldn't force anybody to misdeclare MIME types in order to work around browser restrictions. We should fix the restrictions.

Revision history for this message
era (era) wrote :

@jwatt What's this about a mass bug change? The link is to an uninformative routine comment on an unrelated bug report, and googling for similar comments only brings up this single bug report. Was this a failed test for an upcoming actual mass bug change? Or can you explain what it means with a correct link, or more information about what the link means?

1 comments hidden view all 269 comments
Revision history for this message
In , Michael Lippert (mlippert255) wrote :

(In reply to Stewart Gordon from [comment #218](https://bugzilla.mozilla.org/show_bug.cgi?id=57342#c218))

I think you completely misunderstood what I was getting at, because your final statement is what I was saying (well attempting to as it obviously wasn't as clear as I hoped).

All I was saying is that if a file is identified with a mime type of `text/*` that it is text, and firefox displays text just fine as it currently does with `text/plain`. So firefox can handle any text file it doesn't explicitly have another process for as `text/plain` to display it **in Firefox**, and that should be an option in addition to _save_, and _specifying an external application_ for handling that file.

I was not requesting that the user choose on an all-or-nothing basis at all, I wanted to add an option that doesn't exist at this time, but should for text/* types because the support is already baked in.

Revision history for this message
In , Kalin (kalin) wrote :

Just a restate for my [comment #57 from 16 years ago](https://bugzilla.mozilla.org/show_bug.cgi?id=57342#c57) with a slight update... it is still valid

If I try to download a text/almost-binary-whatever (such as /etc/sendmail.cf), I expect a dialog asking
what to do:

You are trying to view text/almost-binary-whatever content...
( ) Save to disk...
( ) Show in browser as text/plain
( ) Open with program...
 [x] Always do the same for this type
      [OK] [Cancel]

Just my 2 EUR cent...

Revision history for this message
In , Stewart (smjg) wrote :

(In reply to Michael Lippert from comment #219)
> (In reply to Stewart Gordon from [comment #218](https://bugzilla.mozilla.org/show_bug.cgi?id=57342#c218))
>
> I think you completely misunderstood what I was getting at, because your final statement is what I was saying (well attempting to as it obviously wasn't as clear as I hoped).

That final comment wasn't aimed at you personally. Sorry if it sounded like it was. Really, I was commenting on the suggested workaround you made reference to, rather than on your comment itself.

> All I was saying is that if a file is identified with a mime type of `text/*` that it is text, and firefox displays text just fine as it currently does with `text/plain`. So firefox can handle any text file it doesn't explicitly have another process for as `text/plain` to display it **in Firefox**, and that should be an option in addition to _save_, and _specifying an external application_ for handling that file.
>
> I was not requesting that the user choose on an all-or-nothing basis at all, I wanted to add an option that doesn't exist at this time, but should for text/* types because the support is already baked in.

Which is basically what this bug ticket is asking for all along. I was saying that it shouldn't be restricted to text/* types, because other types may also be text-based formats. Another very good example of this is PGN (which seems to be represented by various application/* types).

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

Backlog grooming: bugs without an assignee cannot be P1.

Revision history for this message
In , N-mozilla (n-mozilla) wrote :

In December 2000, just shy of 21 years ago, comment number 6:
"Marking as NEW so someone will either mark it as WONTFIX or INVALID."

Status today, 25 Aug 2021 (30th birthday of Linus announcing his OS in Usenet):

"Status: NEW"

And I see multiple patches attached to this ticket from various points over the years. This is so disheartening.

Revision history for this message
In , Z-sam-i (z-sam-i) wrote :

Encountered this bug today trying to get a plaintext format (with the mime type `application/<something>`) to display as plaintext in the browser rather than Open With > Firefox (and opening a new window.)

Is there still no workaround for enabling this type of functionality, even by modifying config files in the profile? I tried messing around with `handlers.json` (the file that holds the mime type preferences set in `about:preferences` under the "Files and Applications" header) but had no luck.

Some content types in `about:preferences` permit users to select "Open in Firefox" while others don't. Where is the safelist of permitted content types for this behavior? Could a simple solution to this bug be to add an `about:config` flag that would allow power users to select "Open in Firefox" for any content type?

Changed in firefox:
importance: Medium → Unknown
Displaying first 40 and last 40 comments. View all 269 comments or add a comment.
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.