Ubuntu

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

Reported by Martin Flack on 2005-11-16
38
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mozilla Firefox
In Progress
Wishlist
firefox (Ubuntu)
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.

updating qa contact

Move to "Future" milestone.

In , Asa (asa) wrote :

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

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.

In , Asa (asa) wrote :

over to XPApps

<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

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.

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.

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

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

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

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

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-

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-

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.

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?

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?

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

Marking nsbeta1- bugs as future to get off the radar

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!

In , Jps (jps) wrote :

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

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!

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.

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?

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

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 ...?]

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

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

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

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.

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.

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

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.

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

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

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

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.

In , Jmd (jmd) wrote :

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

Ian Jackson (ijackson) on 2006-09-27
Changed in firefox:
assignee: ijackson → nobody
Changed in firefox:
assignee: nobody → mozillateam
Changed in firefox:
status: Unconfirmed → Needs Info
David Farning (dfarning) on 2007-02-24
Changed in firefox:
assignee: mozillateam → mozilla-bugs
Changed in firefox:
assignee: mozilla-bugs → asac
175 comments hidden view all 255 comments
era (era) wrote :

For the record, the "Open in Browser" extension does this, and gets it exactly right. Why this cannot be implemented natively in Firefox is beyond me, but a workaround and model implementation exists.

http://www.spasche.net/mozilla/

The canonical related upstream bug is https://bugzilla.mozilla.org/show_bug.cgi?id=57342 and I think there is one in the Debian BTS about this too.

Alexander Sack (asac) wrote :

going to in progress, as upstream is more or less on it.

Changed in firefox:
status: Needs Info → In Progress
Changed in firefox:
status: Unknown → In Progress
Alexander Sack (asac) on 2007-04-04
Changed in firefox:
assignee: asac → mozilla-bugs

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

era (era) wrote :

See also bug #39136

Any news on this bug? It's been some time since the last post.

This is a very useful and common-sense option, which I'd like to see fixed inside the browser. I'm annoyed with trying to view text files that have alternative MIME types (e.g. LaTeX) by launching the editor.

The "Open in browser" extension doesn't work all the time, and this is something so simple that it should just be a care part of the browser.

We should really find someone to drive this in... I can try to do it, but then I need to find someone else to review the whole thing.

Alexander Sack (asac) on 2008-10-31
Changed in firefox:
assignee: mozilla-bugs → nobody
status: In Progress → Triaged
Changed in firefox-3.0:
importance: Undecided → Wishlist
status: New → Triaged

I was a little shocked when I reported bug 463361 to discover it had been around in one form or another since 2000.

Why is it that it cannot be as simple logic as "if open url triggers download code && firefox.exe is the application associated, dump as text to screen". Something this simple could also be expanded later to handle some of these other related bugs. "If mime type x == associated to firefox.exe do-> some method else dump as text". Inserting call to extension or internal code set at "some method"

This would prevent the infinite loop problem and allow for extendability.

Assigning to myself, the hapless new necko maintainer. This does look like a good bug to finally fix, so it looks like it will be high on my list.

Now when you read my comments, I want you to take them on board, because I speak for the whole firefox users community. And if you decide to take offence, then thats tough, but I am writing it like I feel it because I am ANGRY AND ANNOYED.

Bugs like these should have been resolved a long time ago and I complained about this way back when firefox was still in it's infancy and some stupid sod deleted the bug entry and back then I was as polite as hell and even offered some advice.

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.

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

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

Can't you people see how you are just turning people away from firefox.

I personally am testing Opera and once I get to grips with it's ins and outs, I will be switching over to that because I am so fed up of all the lousy bugs that have never been fixed in firefox and the way your company is just becoming a smaller version of microcrap.

Most of these dammed files can be and eventually are viewed in firefox, so why can't someone just program the damned program to just open them in firefox without having to put us all through the nonsense of the save as dialog box.

Personally, i think you lot should be ashamed of yourselves, especially since there are many more bugs that have been around for ages.

But, if you bunch of lazy sods want firefox to die, then on your own heads be it.

And when I say LAZY I damn well mean lazy.

ANd yes I am bloody angry that this and the many other bugs STILL HAVEN'T BEEN RESOLVED.

To comment 183, I think I speak for the "whole firefox users community" when I say "Goodbye, and good riddance."

To everyone else, sorry for bugspam, I couldn't resist...

Indeed - if you were so upset you should have taken those nine years to patch it yourself! This is a community of volunteers after all.

Thank you to everyone who has contributed to this.

With due respect to commenters 184 and 185:

Users are certainly justified in being upset about relatively simple high-visibility bugs like this one not being fixed. Commenter 183 may have gone overboard, but he has been bottling it up for 9 years after all... So, no, it's not "Goodbye and good riddance".

Also, Firefox is not now the product of a community of volunteers, but rather mostly of a group of salaried programmers, with much financial backing from Google (if not as much as one would expect given the circumstances). That group can be expected to satisfy certain user needs, such as having this bug resolved. Even Google itself can be expected to have them satisfied. And, finally, why do some people assume everyone can code at all, not to mention get a handle on a huge project like Firefox enough to be able to fix such a bug? A tiny tiny minority of users have the skills and the time to do so.

Sorry for the bugspam.

Ill apologize in advance for morebug spam on this.

I do definitely think this bug should be fixed, and that it is way overdue. I do not discredit someone who gets pissed over being mad at the status either. However I would like to point out that there is a workaround for this bug.

1) copy the link (right-click --> "copy link location")
2) clear the address bar (ctrl-l)
3) type "view-source:" and then paste in the url (ctrl-v)
3) enter

However IMHO this is inadequate, and the bug should still be fixed as described.

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.

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

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

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.

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.

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

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.

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.

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.

Micah Gersten (micahg) wrote :

There will not be any more fixes for Firefox 2.

Changed in firefox (Ubuntu):
status: Triaged → Won't Fix

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

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

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.

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

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

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

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.

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

(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

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

the solution should work on those, too.

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

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)

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

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.

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

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

Displaying first 40 and last 40 comments. View all 255 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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