Open Bug 57342 Opened 24 years ago Updated 7 months ago

Add "View as Text/HTML/..." option for unknown mime content-type

Categories

(Firefox :: File Handling, enhancement, P3)

Product:
Firefox
Component:
File Handling
Type:
enhancement

Tracking

()

People

(Reporter: pohl.longsine, Unassigned)

References

(Depends on 1 open bug, Blocks 5 open bugs,
URL
)

Details

(Keywords: arch, parity-opera)

Attachments

(7 files, 5 obsolete files)

patch v0.1
31.08 KB, patch
Details | Diff | Splinter Review
Text File with 00 chars
4.32 KB, text/plain
Details
ui hack for testing
4.23 KB, patch
Details | Diff | Splinter Review
Toolkit ui hack for testing
3.55 KB, patch
Details | Diff | Splinter Review
backend patch, v4 updated
36.93 KB, patch
Details | Diff | Splinter Review
PoC modal dialog
12.46 KB, patch
Details | Diff | Splinter Review
screenshot of browser file reception dialog that has a grayed out "remember" item
14.33 KB, image/png
Details 
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.
over to XPApps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → shrir
pohl@screaming.org - 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.
pardon the spam: reassigning these remaining xp apps bugs of don's to vishy for
the time being. hope that's okay!
Assignee: don → vishy
Changed summary. Marking as NEW so someone will either mark it as WONTFIX or
INVALID.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: mime and helper settings inadequate → [RFE] Mime and Helper settings
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".
Severity: normal → 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-
Keywords: nsbeta1-
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.
Depends on: 61408
Depends on: 58811
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future
Depends on: 52441
Blocks: 78106
Summary: [RFE] Mime and Helper settings → Allow arbitrary MIME types to be treated as plain text
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!

Another thing:  should this be assigned to bzbarsky@mit.edu (Boris Zbarsky)
since he is working on bug 52441?
No longer depends on: 58811, 61408
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.
Assignee: vishy → mpt
Component: XP Apps → User Interface Design
Keywords: arch, helpwanted, mozilla1.0
OS: Linux → All
QA Contact: shrir → zach
Target Milestone: Future → ---
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
Assignee: mpt → neeti
Component: User Interface Design → Networking
QA Contact: zach → benc
Target Milestone: --- → Future
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...
Blocks: 86640
*** Bug 87301 has been marked as a duplicate of this bug. ***
No longer blocks: 86640
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. 
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 tux@centrum.cz 
(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. ***
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.
Fixing summary or I'll never be able to find this bug again.
Summary: Allow arbitrary MIME types to be treated as plain text → Allow arbitrary MIME content-types to be treated as plain text for viewing
Everyone agrees this would be good.  This at this point requires architecture
changes to the URILoader -- once we determine that we have no content viewer for
the data we seeem to pass it off to the external helper app handler and have no
way of getting it back into core layout again even if the external helper app
handler jumps through hoops.

I'm working on some stuff in there this weekend....  if I fix it, good.  If not,
I would strongly recommend passing on this for 1.0 -- this is the sort of arch
change that should bake on the trunk and in milestones for a while.
OK.  There are actually two separate issues here:

1) Have a way to set user preferences to handle a particular type as plaintext.
   I have the back end of this working in my tree (just reset the type on the
   channel to text/plain and punt the load back to the originating docshell).

2) Have a way for the user to select "view as text" from a helper app dialog
   that comes up for an unknown type. Here the problem is that the data is
   already being sent to dist at this point and the original docshell is no
   longer in the middle of a load -- it thinks it's done.

I have no idea how to solve #2 without completely rearchitecting all the helper
app stuff...


Good points, Boris.  How about designating one app as the external text viewer, 
and giving it a pick-helper-app button of its own?

The analogous thing, for the faraway ideal of input helper apps, would be to 
have an editor specified as the general INPUT TYPE=FILE ACCEPT=(unrecognized) 
situation.  There, you could have different editors depending on the major type 
name.  

This suggests the question for when the external text "viewer" is offered.  In 
the traditional situation, View Source..., there was a time when the OS text 
selection and copy was disabled on windows.  Not a user-centered feature, and a 
not-very-best laid plan that went astray to the point of absurdity.

To add insult to injury, someone came up with the idea of putting "Open Link in 
Composer" next to "Open Link in new Window."  Many of us with control over 
content-sensitive menus might consider a seperator there.

In short, I want to be able to open anything, even binary files, in any editor 
I specify, but I don't want to do so when I am trying to open it in a new 
navigator window.  I suggest a new menu item, at least ten pixels from "open 
link in new window" with "open in ________" where the blank is filled from a 
preference.  Maybe multiple such global viewers.  And, when I click on 
something purporting to be text/x-quadruple-byte-klingon, I want to chose 
between all my global viewers, and navigator, and something else to be 
specified in further dialog.  And if I choose the latter option, I want to be 
able to add the selected application to be the default for the specific type, 
the default for unrecognized major types -- e.g. text/(unrecognized) -- or a 
new global viewer to add to my context-sensitive menu.
*** Bug 21985 has been marked as a duplicate of this bug. ***
Summary: Allow arbitrary MIME content-types to be treated as plain text for viewing → Add "View as Text" option for unknown mime content-type
Summary: Add "View as Text" option for unknown mime content-type → [RFE] Add "View as Text" option for unknown mime content-type
*** Bug 142451 has been marked as a duplicate of this bug. ***
-> file handling
Assignee: neeti → law
Component: Networking → File Handling
QA Contact: benc → sairuh
*** Bug 144219 has been marked as a duplicate of this bug. ***
*** Bug 144960 has been marked as a duplicate of this bug. ***
*** Bug 156487 has been marked as a duplicate of this bug. ***
I'd like to see the "View As Text" option for mime types other than text/*.  For
example, right now I can view C source files but not TCL source files.  I
checked, and .c files are sent with a mime-type of text/plain, while .tcl files
are sent with a mime-type of application/x-tcl.  Don't ask me why...  However,
since both are actually plain text, it'd be nice to be able to view both in Mozilla.

Someone suggested forking an external viewer/editor.  This does work (I tried it
for the TCL files), but it isn't as nice as seamlessly viewing in Mozilla along
with other file types.
Is there another non-RFE bug for being able to view files such as these? If not,
this should be changed to a non-RFE bug. It's basic functionality that's broken.
That's what I was thinking when I reported the bug.  To me it's just broken.  I
marked it RFE because I didn't want someone to just declare the bug 'invalid'
and lose track of it.
See also bug 108313, Mozilla should display text/foo (where foo is unknown) as
text by default instead of trying to download it.
*** Bug 163670 has been marked as a duplicate of this bug. ***
*** Bug 108313 has been marked as a duplicate of this bug. ***
*** Bug 166329 has been marked as a duplicate of this bug. ***
Related: Bug 11521, View as different media type support.
Summary: [RFE] Add "View as Text" option for unknown mime content-type → Add "View as Text" option for unknown mime content-type

*** This bug has been marked as a duplicate of 11521 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Reopening, since this, unlike bug 11521, may actually be fixable in a reasonable
manner...
Blocks: 11521
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Hmmm...
Boris, what's about bug 156788 ? Let's reopen it also...

Nope.  That's precisely an example of the "really hard to solve" case that needs
a full fix to bug 11521.  Note that this bug is talking about types we do _not_
handle internally, for which things are much simpler ("all" we have to do is in
the helper app code reset the type to something we handle and somehow kick the
load back to the browser).  In the case of types we _do_ handle we need to
perform some sort of special reload or something like that... you get a number
of nasty cache-related issues, etc.
QA Contact: sairuh → petersen
Depends on: 176919
Blocks: 191000
*** Bug 197579 has been marked as a duplicate of this bug. ***
*** Bug 213316 has been marked as a duplicate of this bug. ***
*** Bug 214313 has been marked as a duplicate of this bug. ***
*** Bug 215706 has been marked as a duplicate of this bug. ***
Someone has quoted RFC2046.  There is also a suggestion in RFC1341 about what to
do with text/strange-unknown-format and similar MIME types:

>In general, the top-level Content-Type is  used  to  declare
>the  general  type  of  data,  while the subtype specifies a
>specific format for that type of data.  Thus, a Content-Type
>of  "image/xyz" is enough to tell a user agent that the data
>is an image, even if the user agent has no knowledge of  the
>specific  image format "xyz".  Such information can be used,
>for example, to decide whether or not to show a user the raw
>data from an unrecognized subtype -- such an action might be
>reasonable for unrecognized subtypes of text,  but  not  for
>unrecognized  subtypes  of image or audio.

I think there is a third 'strand' to this bug that is separate from the two
issues mentioned by Boris Zbarsky.  He mentioned user preferences to handle a
particular type as plain text, and an extra 'view as text' option for a helper
dialogue box.  But for a MIME type that is text/something, shouldn't the browser
just display the document immediately as it does for text/plain?  This should
not require any UI spec - no extra dialogue boxes or prompts are needed, all
that happens is for text/* to be treated the same way as text/plain unless some
more specific handler is set up.

Having a preferences box to treat a particular type as plain text (and not
limited to just text/* MIME types) would be nice; an extra 'view as text' option
in the helper app dialogue box would also be nice.  But neither of these is a
prerequisite for fixing the current default behaviour, so that a text/* document
displays as text rather than being treated as a wholly unknown type.
So the first time we encounter text/rtf we should just dump it out as plaintext
and not give the user a chance to set up a reasonable handler for that
type?  That's not reasonable.

In fact, that whole section of the RFC is incredibly bogus in my mind,
since most text/* types are in fact not human-readable (this includes
text/html and its ilk; people who code HTML for a living by hand notwithstanding).
As Comment #55 states the RFC:

>such an action might be
>reasonable for unrecognized subtypes of text,  but  not  for
>unrecognized  subtypes  of image or audio.

It says _might_ be reasonable, not should. 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 yen...

My suggestion would be to have a back-end pref with a list of types that are
handled as text/plain. (My pet peeve is trying to view dtd files at w3c.org) 
This would save the extra pref in the ui, but still give advanced users an
option to change it through about:config or the .pref file.  This pref should
come preloaded with things like text/css, text/tab-separated-values,
application/xml-dtd, and others that are known human-readable file types.


I think it's a fair point that defaulting to show-as-plain-text would not give
the user the opportunity to set up a custom handler for text/rtf or whatever. 
On the other hand the current behaviour does not give the user the opportunity
to view a document in the browser.  So you could weigh up which of the two is worse.

But perhaps you don't want to do anything on this until it can be done _right_
(which I assume means an extra UI preference and a 'view in browser' option on
the helper app chooser).  That sounds entirely reasonable.
-> me. I have a proof-of-concept.
Assignee: law → cbiesinger
Status: REOPENED → NEW
this unfortunately includes the "part 2" patch from bug 78919 as well as the
patch for bug 120045 :( sorry about that

I hope the concept is still visible, which is mainly passing an nsIDispatchable
to nsIExternalHelperAppService::DoContent. I'm not very good at coming up with
names, so said name might suck; feel free to suggest a different one.

oh, and you _do_not_ want to run a normal mozilla with this exact patch. you
will be sorry if you do. (that's because it forces all externally handled
content to display as text/plain, for testing purposes)

next step: clean this up a bit, allow this to be called from the helper app
dialog, implement ui for it
Attached patch patch v0.1 — — Splinter Review 
ok, better version of the patch.

Comments on this patch are welcome.

Note: UI is not final yet.
I'm thinking of something like this:

  (o) View as [Text    v]
with the dropdown containing:
  +---------------+
  | Text	  |
  | Image	  |
  | HTML	  |
  | XML (maybe)   |
  | Other...	  |
  +---------------+

Where "Other..." allows the user to manually enter a mime type.

oh, btw... this patch removes pre-downloading while the dialog is up. it
doesn't do cleanup that would be allowed by this change, though. guess I'll do
that in another patch.
> oh, btw... this patch removes pre-downloading while the dialog is up. 

Please make that a separate patch, and do it first if needed for this bug.  
That change needs to be done somewhat carefully in the face of how stream 
converters work, and it will be simpler to debug the more localized changes.
> Note: UI is not final yet.
> I'm thinking of something like this:
>
>   (o) View as [Text    v]
> with the dropdown containing:
>   +---------------+
>   | Text	    |
>   | Image	    |
>   | HTML	    |

'Web Page' would probably be more understandable for most users.

>   | XML (maybe)   |

Or maybe not. :-)
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=x-foo%2Fx-bar&disposition=inline&filename=&quote=1&justshow=1
*** Bug 221998 has been marked as a duplicate of this bug. ***
note to self, mReceivedDispositionInfo seems to be sufficient for
mSuspended=TRUE, so the latter variable can maybe be eliminated
*** Bug 226595 has been marked as a duplicate of this bug. ***
URL: http://biesi.damowmow.com/mime.php?do...
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=x-foo%2Fx-bar&disposition=inline&filename=&quote=1&justshow=1
*** Bug 230252 has been marked as a duplicate of this bug. ***
*** Bug 232751 has been marked as a duplicate of this bug. ***
*** Bug 234108 has been marked as a duplicate of this bug. ***
*** Bug 236237 has been marked as a duplicate of this bug. ***
*** Bug 236623 has been marked as a duplicate of this bug. ***
Whiteboard: parity-opera
Were there any big problems with the patch? Biesi, will you be working on it?
Thanks.
(In reply to comment #73)
> Were there any big problems with the patch? Biesi, will you be working on it?
> Thanks.

yes, it breaks saving IMAP attachments, as well as saving files from some http
servers.

I need to find a solution for that... targeting optimistically
Target Milestone: Future → mozilla1.8beta
I might encourage this bug to also include the case of application/<unknown>+xml
(or <anything>+xml?).  Sometimes I'm hitting an XML MIME type that the browser
doesn't explicitly handle, and receive the same type of dialog as the
text/<unknown> case.  In this situation, though, it's an XML document (as
evinced by the +xml suffix), and Mozilla can display XML, at least in tree form.
 See also bug 194351.
*** Bug 210384 has been marked as a duplicate of this bug. ***
*** Bug 242124 has been marked as a duplicate of this bug. ***
comment 18 suggests that adding this enhancement would offer users "more power
than any other browser I've seen" - as if that's a reason not to do it.  The
suggested alternative is "make the user do a bit more work" - so the user is
protected from something "annoyingly incomprehensible" like a Handle As...
option, and instead only has to download the silly file, open a shell window and
rename the file to have a recognized extension, and go back to Moz and type in a
file: url for the new file in order to view it.  And remember to remove the file
after.

That isn't any more comprehensible or less annoying to a novice user, and if I
had a novice user on a support line I'd much rather be able to say "hmm, dialog
asking what to do with application/x-pdf? Yeah, just pick Handle as
application/pdf, it'll be fine."

I actually see things served as application/x-pdf often enough that I have an
entry in MIME types for "Mislabeled Portable Document Format". :(  And then
there's always the occasional html/text or txt/html or other wacky content type
where you see it and you know immediately what it was supposed to be but you
have to go run around the block in order to view it.

For UI, I'd suggest that Handle As... gives you a selection box to pick from any
of the types currently known to the browser, ideally with more common ones and
closest fuzzy matches to the served content type toward the top.  With a tip for
the Handle As button saying something like "Use if you think you know what type
this document really is" I don't think it really has to be incomprehensible.
comment 62 suggests UI already. I'm quite hesitant to add more items to the
list... Maybe there should be an additional one for a type guessed from the file
extension, but that should be all, I think.
I disagree.

This is a common enough problem, and being one where the people causing the
problem, or at least capable of solving it, are generally not the ones suffering
from it, and may not be open to fixing it since the people capable of actually
explaining what the problem is are a very small subset of their audience, or
they may not be directly contactable through the corporate bureaucracy, this
merits very careful thought about how the problem can be mitigated from the
client side.

There are cases where a resource can be opened, will force the "Save As" dialog,
and if saved and double-clicked will immediately open the browser which will
render it fine. This is quite clearly a ridiculous situation! We know why it
happens but the user experience is just stupid.

Certainly there are a few common media types which, for a user who can see what
the resource ought to be handled as, they should be able to easily override the
Save As prompt and cause the resource to be opened by that built-in handler. I'm
thinking here "Plain Text", "HTML", "JPEG image", "GIF image". Plus a few more.
PNG, XML etc. The list isn't huge, will cut out 99.9% of erroneous mimetype
problems, and if a confused user chooses the wrong thing they can always try
again and are in no worse situation than they started off.

Possibly this should be defaulted based on the resource "filename extension" - I
can't see that being a problem (in many cases it just won't work, but is no
worse than not doing so). Defaulting based on the first few bytes of the
resource would be better. Possibly, if we really want to keep that dialog
absolutely as simple as possible then it should be made an expandable dialog
with an "Advanced/More>>>" button - I don't see a problem with that either.

But there *does* need to be an escape route, because the failure mode results in
far more effort than is reasonable to work around, currently. It *should* just
work transparently, yes, but it sometimes doesn't and in those cases it really
doesn't need to fail that badly.

Choosing obvious stuff from a list is an absolute minimum. The real expert user
will also want to be able to type in a literal mimetype. Hide these by default
if you're really worried about scaring some users, but they ought to exist somehow.

(I'd also like to point out that "unknown mimetype" is not the only problem -
there are cases where the mimetype is recognised but mislabelled. In these cases
it would be useful to be able to invoke something similar to the Save As dialog
manually on a link. The example that springs to mind is download sites that
mislabel PKZIP or Windows executable files as text/plain. In fact I'd really
like to see a check for resources starting in PK or MZ and throwing a dialog
saying "Are you sure you want to open this as text or HTML", but that's getting
beyong the scope of this bug.)
> will also want to be able to type in a literal mimetype

see the "other" part of comment 62

> like to see a check for resources starting in PK or MZ 

current mozilla versions check if the first 1000 bytes or so of the data
contains binary content and show the helepr app dialog if so (assuming the type
is text/plain). that is indeed a different bug.
Should the summary be changed from

  Add "View as Text" option for unknown mime content-type

to something like

  "View as [Text|...]" option for unknown/wrong mime content-type

since the discussion seems to be converging that way and not to have Text as the
single, fixed option?
Summary: Add "View as Text" option for unknown mime content-type → Add "View as Text/HTML/..." option for unknown mime content-type
After almost 4 years discussing, shouldn't this bug be fixed somehow?
:-(
(In reply to comment #80)
> Possibly this should be defaulted based on the resource "filename extension"

It's important to note that the whole concept of a "file extension" is OS-
dependent and only meaningful on operating systems that determine a file's 
type from it's file extension.  In the HTTP world and on most non-Windows 
OS's, a file's extension has no meaning and is opaque.

This is part of why server misconfigurations are so annoying: the server-
provided MIME type *should* be the final authority on what the content is.  I 
strongly advise against following IE's behavior here and second-guessing 
things that look too generic.  The problem is with the site, and in this case, 
the site author *is* using IE exclusively to test things (or isn't testing at 
all), which is why we're in this mess to begin with.

We certainly need a way to override MIME types that are incorrect, but we 
should look towards correcting the problem (the server misconfiguration) 
first, and treat this as a temporary workaround until a real fix is 
performed.  For that reason, none of this should be performed automatically or 
without notifying the user.  We should NEVER do the IE thing here and 
*silently* use our own second-guessed MIME type in place of what *appears* to 
be a generic or misconfigured MIME type.

I do like the idea of an "Advanced/More >" thing, and we should be able to 
pull this dialog up even when Mozilla has a good idea of what to do with the 
resource as it's currently labeled.
While I agree with David's comment 85, I note that on unix systems which don't
depend on the file extension, content type-guessing programs such as file(1) are
certainly allowed to use the filename in making a decision about what to report.
 On the other hand, those guessing programs ought to be able to get /dev/stdin
correct most of the time.  The filename should only be used to resolve
ambiguities when it is available, and there is nothing wrong with asking the
user to confirm such ambiguity resolution, except (and this case is probably
rare) when it becomes an encumberance to the user being able to proceed at their
customary pace.

If you wanted to accommodate that, Christian, you might include a "Don't ask me
to confirm such guesses again" checkbox, but I wonder how useful overall that
would be.
*** Bug 246438 has been marked as a duplicate of this bug. ***
Other changes in 1.7 have broken web sites that I used in 1.6 without issues.
The changes reference this as the "fix" for their breaking stuff, so I'd
encourage those involved to fix this as soon as possible.
I believe this is a duplicate of bug 121498.
(In reply to comment #89)
> I believe this is a duplicate of bug 121498.

No; this proposes a more extensive solution.  Solving this would solve that bug, 
but the reverse is not necessarily true.


(In reply to comment #88)
> Other changes in 1.7 have broken web sites that I used in 1.6 without issues.
> The changes reference this as the "fix" for their breaking stuff, so I'd
> encourage those involved to fix this as soon as possible.

Brad Clarke, could you cite those changes/bugs, please?
After some offline discussion it was determined that the problem is with txt 
files with 00 in them (I'll attach one for you).

    
    

    
  
(In reply to comment #88, comment #91, comment #92)
Brad,
please try to use a few more words to explain what you are trying to say.

What about the file attached?
If you look at it from bugzilla, it will (and is) served as text/plain, so
everything should work (works in 1.6 at the moment).

What broke in 1.7. for you?

    
    

    
  
The file here on bugzilla even seems to open fine :/

In 1.6 it opens just fine in the browser. In 1.7 I get the download dialog with 
the content type showing as "text/plain" and the default application 
being "txtfile" (notepad). Since notepad displays the txt file fine with no 
formatting problems or unprintable characters, the content type from the server 
is "text/plain" and the extension for the file is "txt" it's very odd to me 
that 1.7 can't just display it.

Other txt files in the same directory on the web server open in 1.7 just fine. 
It's being served by a very simple servlet from tomcat which you can see here:
http://cvs.sourceforge.net/viewcvs.py/cruisecontrol/cruisecontrol/reporting/jsp/
src/net/sourceforge/cruisecontrol/servlet/FileServlet.java

Please let me know if there is any more information I can provide.

    
    

    
  
please, keep that discussion out of this RFE. it is working as designed, and
pretty unrelated to this bug. bugzilla attachments do not exhibit this
behaviour, because their content-type header is neither "text/plain" nor
"text/plain; charset=iso-8859-1". please discuss further issues with this in a
newsgroup, private mail, or different bug. thank you.

    
    

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

    
    

    
  
I have found that http://www.spamhaus.org/ will frequently bring up the "Save As
..." dialog.

It appears that it doesn't send a Content-Type: at all, and that apparently,
this is interpreted as application/octet-stream

I can't always repro this; don't know if they have multiple servers or if
they're changing their configuration back and forth between something which
works with Mozilla and something which doesn't.

In any event, I would very much like to be able to specify that it's just HTML
and it should be opened in the browser and not Saved As ... anything.

    
    

    
  
Can't finally someone take a look at this? I can't understand why such
simple thing can't be done for 4 (!) years ...


    
    

    
  
(In reply to comment #98)
> Can't finally someone take a look at this? I can't understand why such
> simple thing can't be done for 4 (!) years ...

Then maybe you should try fixing it yourself? See points 1.1 and 1.2 here:
http://bugzilla.mozilla.org/page.cgi?id=etiquette.html

    
    

    
  
Sorry, I didn't mean any offense. I still hope this annoying bug is finally
going to be fixed one day.


    
    

    
  
it is going to be fixed one day, unfortunately bug 227113 is a real problem that
stands in the way of fixing it, and it's somewhat hard to fix. bug 217434 too,
but less of a problem... that's why those bugs are marked as blocking this one.
so this bug now has 4 more useless comments, that nobody will read. thank you
very much.

    
    

    
  
I can't follow the other bugs (I simply do not understand them), however
what I really wonder is why we need this huge discussion in the first place.

Excuse my dumb mind, but why can't it be done some way like this:

  .configfile:
    # treat-these-mimes-as-plain-text
    ttmapt: text/x-sh, text/x-java <empty by default>

  browser mime handler:

    [... handling file with $mime ...]    
    if(contains($ttmapt, $mime)) $mime = text/plain;
    [ ... go on with $mime handling ...]


    
    

    
  
Prompted by the previous comment, I looked into the "depends on" links to bugs
which are not yet fixed.

Not a single one of them makes much sense to me.

Maybe I'm dense, but even if so, it would be useful to document exactly why this
bug depends on bug 69938 (downloaded files are needlessly downloaded to a
temporary location), bug 217434 (IMAP suspend/resume issue [sic]), and bug
227113 (stream converter suspend/resume issue ... what's a stream converter
anyway?), or else remove those dependencies.

In fact, while I doubt it will do much good, I'm taking the liberty to (attempt
to) remove them here and now.
No longer depends on: 69938, 217434, 227113

    
    

    
  
arg, can you stop touching the dependencies of my bugs? summary of the issue is:
we want to offer the "view as ..." option in the helper app dialog (as the
summary of this bug says). this means we want to stop the networking code from
continuing sending us data while the dialog is up, so that we can send it to the
appropriate other component in the mozilla code instead. This means Suspend(),
the function that means "do not send data until Resume() is called", needs to
work reliably. hence the dependencies.

> Excuse my dumb mind, but why can't it be done some way like this:

well, technically that'd be doable. practically, no user would be able to
discover it...
Depends on: 69938, 217434, 227113

    
    

    
  
Woah, woah. This shouldn't require us to break the download streaming. It 
doesn't break it in Opera, why would it break it in Mozilla?

    
    

    
  
(In reply to comment #62)
> patch v0.1

  So about a year ago there was a preliminary patch for this bug that seems
to do everything /I/ want it to do.  I'm a newbie here; can someone please
point me to (preferably) a binary containing that patch, or else instructions
on how to get sources for and build the patched browser?  I know several
other people who would like this, too.

    
    

    
  
(In reply to comment #105)  
> Woah, woah. This shouldn't require us to break the download streaming. It   
> doesn't break it in Opera, why would it break it in Mozilla?  
  
intersting. how does opera do it, especially in case of gzipped content? does  
it read half of the data from the file again?  
  
(In reply to comment #106) 
> on how to get sources for and build the patched browser?  I know several 
> other people who would like this, too. 
 
http://www.mozilla.org/build/ 
 

    
    

    
  
Another example of a very common server type-mislabeling trick that
inconveniences the user happens with Mailman-maintained mailing list archives. 
These archives always have a monthly (or some other period) archive file that is
gzip'd text.  It usually comes labeled as:

  Content-Type: application/x-gzip

instead of the correct:

  Content-Type: text/plain
  Content-Encoding: gzip

and as simple as the problem is, there is no way I've ever found to get Mozilla
to show the text instead of insisting on saving to file.

This example is Mailman bug 905910:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=905910&group_id=103

... but even if it gets fixed in Mailman, lots of Mailman sites out there will
surely be sending mislabeled files for a long time after, so the browser needs
some way for the user to cope.

    
    

    
  
>> Woah, woah. This shouldn't require us to break the download streaming. It   
>> doesn't break it in Opera, why would it break it in Mozilla?  
>   
> intersting. how does opera do it, especially in case of gzipped content? does  
> it read half of the data from the file again?  

Do you have a test case that I can check? I'm not familiar with this corner of 
HTTP enough to reliably create it myself. (Alternatively, explain exactly what I 
should test using HTTP headers and content and I'll try to do it myself.)

I'm not sure exactly how Opera does it, but many possibilities come to mind, 
such as streaming the data into memory instead of disk, streaming the data into 
the cache unchanged until a final location is picked (and then decoding it on 
copy instead of just moving it, if that is necessary), or saving the file data 
gzipped and then uncompressing it if required.

    
    

    
  
Just find a link of .tar.gz file, left click the link.
Mozilla will ask you save it to disk or open it.
1)If select save, you will find the file you saved was gunzipped but still named
as .tar.gz.
2)If select open, you will find it fail to be opened, and find something in your
/tmp.

Really annoy.



    
    

    
  
(In reply to comment #109)
> Do you have a test case that I can check? I'm not familiar with this corner of 
> HTTP enough to reliably create it myself. (Alternatively, explain exactly what I 
> should test using HTTP headers and content and I'll try to do it myself.)

OK... hm... try this:
- name the file foo.html.gz
- send as:
Content-Type: text/html
Content-Encoding: gzip
Content-Disposition: attachment
- content should be gzipped, of course.

Expected behaviour: When I "View as HTML" or "View in Browser" or something, I
want to see the ungzipped HTML, of course. When saving, I want the .html.gz file
contain gzipped content.
When I click "Open using [iexplore.exe    ] [Choose...]" I expect the content to
be decoded before passed to msie.

.tar.gz is probably not such a good example; you won't want a "view in browser"
there. but maybe testing w/ helper apps is a good idea too:
name foo.tar.gz
content-encoding: gzip
content-type: application/x-tar

Saving to a file should absolutely not decode. Opening in an application
probably should decode, with appending .tar...


foo.doc
content-encoding:gzip
content-type:application/msword

that should always decode.

    
    

    
  
Gleep!  I'm not sure I like the sound of having a dozen ad-hoc rules for when to
decode or not and what to do with file extensions--especially because as far as
http is concerned, the Content-Type and Content-Encoding headers are everything
and filename extensions are invisible to the standard.

I would suggest two very simple rules to apply in perfect uniformity, regardless
of the type of data.

1.  If it's to be processed/displayed internally, then of course undo the encoding.

2.  If it's to be saved to a file, and has a non-null Content-Encoding that
Mozilla knows how to undo, give the user radiobuttons on the save dialog:

  This file was sent with the encoding: gzip
  O  save in this encoding
  O  undo encoding and save

Then you can add file extension *heuristics* if you want, say for example if the
encoding is gzip and the suggested name in the Save dialog ends in .gz then
change the suggested name to without the .gz ... that makes these convenience
suggestions that the user sees in the dialog and has the choice to accept, not a
plethora of rules that get applied for various content types and make the user
try to figure out what happened.

As for what to do when invoking a helper: the real answer is probably allow each
helper definition to include an Accept-Encoding list.  If a file comes in an
encoding the helper accepts, Moz passes the file unchanged.  If the helper does
not accept the encoding but Moz knows how to decode it, then Moz decodes. 
Otherwise, need to ask the user what to do.

An alternative to accept-encoding list per helper is for helpers to be a
relation indexed by (content-type, encoding).  That way you could support a
helper that can accept a certain encoding but needs maybe different command line
options to do it, because the entry for that (type,encoding) pair would be able
to have its own command line.  But I'm not sure all of these considerations need
to be handled for THIS bug....

    
  
Blocks: 258012

    
  
Blocks: 266410

    
    

    
  
solution: never offer this option when we decided not to apply encodings. that
allows us to easily do this.
Keywords: helpwanted

    
    

    
  
Comment on attachment 165149 [details] [diff] [review]
backend patch

this does not provide a good solution for the frontend to figure out whether a
certain mime type is supported... do you think I should add such a method to
nsIDispatchable? Or should the frontend figure that out for itself (eg by
querying the Gecko-Content-Viewers category)? I'm not sure currently what I
prefer...

        Attachment #165149 -
        Flags: review?(bzbarsky)

    
    

    
  


  
this is a patch to the UI that I used for testing; it is totally unsuitable for
checkin, but it shows how the backend can be used.

    
    

    
  
I'll try to get to this in the next few days...

    
  
Blocks: majorbugs

    
    

    
  
Comment on attachment 165149 [details] [diff] [review]
backend patch

forgot to change the uuid...

        Attachment #165149 -
        Attachment is obsolete: true

        Attachment #165149 -
        Flags: review?(bzbarsky) → review-

    
    

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

    
    

    
  
Comment on attachment 165908 [details] [diff] [review]
backend patch v2

>Index: uriloader/base/nsURILoader.cpp
>+NS_IMETHODIMP nsDocumentOpenInfo::ReDispatch(const nsACString& aMIMEType,

This wants to NS_PRECONDITION aData and NS_PRECONDITION aRequest, right?

Also, why is it ok to have an aRequest here that's not a channel?  When would
that happen, exactly?  URILoader in general only handles channels, and we
really do want a channel here to be able to do SetContentType...

>+  // Save type and stream listener

"save old type and stream listener in case we fail to redispatch", right?

>+    rv = aData->Available(&count);
>+    // XXX what if that failed?

We cancel aRequest with rv?  That would make the most sense...

>+    rv = m_targetStreamListener->OnDataAvailable(aRequest, nsnull, aData, 0, count);

Hmm... I guess this is an OK context to pass, since there's really no better
one in sight, and we _did_ open this channel ourselves with a null context,
huh?

Could you write a comment to that effect?

>   nsCOMPtr<nsIExternalHelperAppService> helperAppService =
>     do_GetService(NS_EXTERNALHELPERAPPSERVICE_CONTRACTID, &rv);
>-  if (helperAppService) {
>+  if (!aAllowExt) {
>+    rv = NS_ERROR_NOT_AVAILABLE;
>+  } else if (helperAppService) {

I think this would be clearer written as:

nsCOMPtr<nsIExternalHelperAppService> helperAppService;
if (allowExt) {
  helperAppService =
    do_GetService(NS_EXTERNALHELPERAPPSERVICE_CONTRACTID, &rv);
} else {
  rv = NS_ERROR_NOT_AVAILABLE;
}
if (helperAppService) {
...


> nsDocumentOpenInfo::TryContentListener(nsIURIContentListener* aListener,
>-                                       nsIChannel* aChannel)
>+                                       nsIRequest* aRequest)

I'm not so enamored of that change, for the same reasons as apply to the first
comment on this patch...

>-  NS_PRECONDITION(aChannel, "Must have a channel");
>+  NS_PRECONDITION(aRequest, "Must have a channel");

If the change _is_ made, please fix the assert text.

>Index: uriloader/exthandler/nsExternalHelperAppService.cpp

>+NS_IMETHODIMP nsExternalAppHandler::GetCanHandleAs(PRBool* aCanHandleAs)

This would be better named GetCanCallHandleAs, I think...

> NS_IMETHODIMP nsExternalAppHandler::OnStopRequest(nsIRequest *request, nsISupports *aCtxt, 

>-  mRequest = nsnull;

You sure this doesn't introduce any cycles?  Maybe we want to null it out here
only if we've got disposition info or something?

>@@ -2115,12 +2126,15 @@ nsresult nsExternalAppHandler::CreatePro
>   mDialog = nsnull;
>+
>+  mDispatchable = nsnull;
>+

Add a comment explaining that this breaks the cycle?

>+NS_IMETHODIMP nsExternalAppHandler::HandleAs(const nsACString& aMIMEType)

This needs to enforce the constraints of GetCanHandleAs() and throw if that
would return false, I think....

>Index: uriloader/exthandler/nsIExternalHelperAppService.idl

>+interface nsIDispatchable : nsISupports

Could we please put this in a different file?  Especially if we expect to allow
embeddors to implement nsIDispatchable?

Then again, do we expect people to either call nsIExternalHelperAppService
directly or to implement it?  If not, perhaps none of these need be public
apis?  I suppose that's for another bug, huh?  :)

>+   * In no case will this re-enter the original content handler.

This can only be guaranteed if the original content handler is the helper app
service, no?  I think this should be clarified.

>+   * *When this function returns successfully, the current handler WILL NOT
>+   *  get an onStopRequest call!*

Maybe it should?  Would that actually break anything in this case?

>+   * THIS MUST NOT BE CALLED FROM doContent!

This is an internal implementation notes for nsExternalHelperAppService, no?  I
don't see how it would apply in general...  Again, do we expect embeddors to
implement nsIExternalHelperAppService?

>+   * This method may be called event after onStopRequest has been called,

"even", not "event".  Which onStopRequest?  That's non-obvious from looking at
this interface.

>+   * in which case the new listener will receive an onStopRequest call before
>+   * this method returns.

Will or must?  That is, is this documentation for implementors of
nsIDispatchable, or for coders in nsExternalHelperAppService?  The latter
reaslly does not belong here...

>+   * @param aRequest
>+   *        The request to dispatch as. Must be the same as passed to doContent.
>+   *        XXX this sucks.

I rather agree....  I'm not sure what the best way to fix this is,
conceptually.  Perhaps some verbiage indicating the overall interaction of
nsIExternalHelperAppService and nsIDispatchable is in order?

>+   *        No content handler for the registered type was registered; or the
>+   *        current handler is the handler for the requested type.

Do we ever enforce the latter condition?  I don't believe we do, and don't see
a good way to do it without assuming that the current handler is always the
externalhelperappservice.

>+  void handleAs(in ACString aMIMEType);

This should document that it throws anytime canHandleAs is false or something
like that.  At the very least, canHandleAs needs to be mentioned here.

        Attachment #165908 -
        Flags: review?(bzbarsky) → review-

    
    

    
  
(In reply to comment #121)
> This wants to NS_PRECONDITION aData and NS_PRECONDITION aRequest, right?

fine with me to make aRequest a precondition. aData is allowed to be null though
(see the interface docs).

> Also, why is it ok to have an aRequest here that's not a channel?  When would
> that happen, exactly?  URILoader in general only handles channels, and we
> really do want a channel here to be able to do SetContentType...

hm... yeah, that makes sense I guess.

> >+  // Save type and stream listener
> 
> "save old type and stream listener in case we fail to redispatch", right?

indeed. will make that change.

> >+    rv = aData->Available(&count);
> >+    // XXX what if that failed?
> 
> We cancel aRequest with rv?  That would make the most sense...

ok. I guess Cancel will always succeed ;) (it better...)

> Hmm... I guess this is an OK context to pass, since there's really no better
> one in sight, and we _did_ open this channel ourselves with a null context,
> huh?

we always pass a null context currently...

> Could you write a comment to that effect?

sure

> I think this would be clearer written as:

ok

> I'm not so enamored of that change, for the same reasons as apply to the first
> comment on this patch...

I think I had a good reason for that change. wish I remembered it...

> >+NS_IMETHODIMP nsExternalAppHandler::GetCanHandleAs(PRBool* aCanHandleAs)
> 
> This would be better named GetCanCallHandleAs, I think...

hmm... ok... I'd prefer my name, but sure.

> You sure this doesn't introduce any cycles?  Maybe we want to null it out here
> only if we've got disposition info or something?

Ah... I can do that. my thinking was that the only reference was through necko
-> streamlistener (documentopeninfo) -> exthandler.

> Add a comment explaining that this breaks the cycle?

ok...

> This needs to enforce the constraints of GetCanHandleAs() and throw if that
> would return false, I think....

oh yeah, good point.

> Could we please put this in a different file?  Especially if we expect to allow
> embeddors to implement nsIDispatchable?

I dunno, do we? ;) sure, fine with me. in uriloader/base or exthandler? I guess
base is better (I envision possibly passing this to nsIURIContentListener
objects as well, sometime in the future)

> Then again, do we expect people to either call nsIExternalHelperAppService
> directly or to implement it?  If not, perhaps none of these need be public
> apis?  I suppose that's for another bug, huh?  :)

implement it? heh. that's a really good question. personally, I don't expect
anybody to implement it ;)

> >+   * In no case will this re-enter the original content handler.
> 
> This can only be guaranteed if the original content handler is the helper app
> service, no?  I think this should be clarified.

that's the only object currently which gets an nsIDispatchable? the code would
have to be expanded if we ever pass it to other handlers, sure. I am not sure
that I want to give up this precondition, it seems important to let the current
handler rely on this.

> >+   * *When this function returns successfully, the current handler WILL NOT
> >+   *  get an onStopRequest call!*
> 
> Maybe it should?  Would that actually break anything in this case?

I'd have to check. it probably should get onStopRequest... maybe with a special
status code? (NS_BINDING_RETARGETED?) I suspect onstopr currently doesn't deal
with that very well.

> >+   * THIS MUST NOT BE CALLED FROM doContent!
> 
> This is an internal implementation notes for nsExternalHelperAppService, no?  I
> don't see how it would apply in general...  Again, do we expect embeddors to
> implement nsIExternalHelperAppService?

I don't see how that follows... if doContent does call it, we re-enter uriloader
while it's not done with DoContent yet. that seems scary. it would also mean
that the new target listener gets two onstartrequest calls (one from uriloader's
onstartrequest, to which dispatchcontent returns, to which docontent returns;
one from ReDispatch). so this does seem like an nsIDispatchable issue. I can
rephrase it as "Must be called in or after onStartRequest", if you prefer that.

> >+   * This method may be called event after onStopRequest has been called,
> 
> "even", not "event".  Which onStopRequest?  That's non-obvious from looking at
> this interface.

well, the current handler's... I'll mention that.

> >+   * in which case the new listener will receive an onStopRequest call before
> >+   * this method returns.
> 
> Will or must?  That is, is this documentation for implementors of
> nsIDispatchable, or for coders in nsExternalHelperAppService?  The latter
> reaslly does not belong here...

well, both. interface documentation can be read from both sides :-)
(http://weblogs.asp.net/oldnewthing/archive/2003/12/26/45979.aspx may be an
interesting read)

> >+   * @param aRequest
> >+   *        The request to dispatch as. Must be the same as passed to doContent.
> >+   *        XXX this sucks.
> 
> I rather agree....  I'm not sure what the best way to fix this is,
> conceptually.  Perhaps some verbiage indicating the overall interaction of
> nsIExternalHelperAppService and nsIDispatchable is in order?

the real solution may involve storing the request in the DocOpenInfo, but that
increases the risk of cycles...

> Do we ever enforce the latter condition?  I don't believe we do, and don't see
> a good way to do it without assuming that the current handler is always the
> externalhelperappservice.

hmm, guess we never store the uricontentlistener we chose? if we do,
DispatchContent could just compare the new one to the current one and fail if
they are equal (after CanHandleContent/IsPreferred returned true)

> This should document that it throws anytime canHandleAs is false or something
> like that.  At the very least, canHandleAs needs to be mentioned here.

will do

    
    

    
  
(In reply to comment #122)
> fine with me to make aRequest a precondition. aData is allowed to be null though
> (see the interface docs).

Why, though?  What's the use case for a null aData?

> > Could we please put this in a different file?  Especially if we expect to allow
> > embeddors to implement nsIDispatchable?
> I dunno, do we? ;) sure, fine with me. in uriloader/base or exthandler? I guess
> base is better (I envision possibly passing this to nsIURIContentListener
> objects as well, sometime in the future)

Ah, to nsIURIContentListener2?  That would make sense....

If we do plan to just keep this an exthandler-specific hack, it may be better to just expose 
that interface on aContext (basically have the object implementing the nsIDispatchable 
interface be the context, and have it forward to the original context as needed).  Then the 
interface could be in a .h file altogether or something, with all documentation in that file.

> that's the only object currently which gets an nsIDispatchable? the code would
> have to be expanded if we ever pass it to other handlers, sure. I am not sure
> that I want to give up this precondition, it seems important to let the current
> handler rely on this.

It's a good precondition, but again only one that makes sense if we plan to have multiple 
handlers that get an nsIDispatchable. If we do, then a lot of these comments make more 
sense...

> > Maybe it should?  Would that actually break anything in this case?
> I'd have to check. it probably should get onStopRequest... maybe with a special
> status code? (NS_BINDING_RETARGETED?) I suspect onstopr currently doesn't deal
> with that very well.

Special status code and dealing sounds good to me.

> I don't see how that follows... if doContent does call it, we re-enter uriloader
> while it's not done with DoContent yet. that seems scary.

Oh, I agree that it's bad.....

> I can rephrase it as "Must be called in or after onStartRequest", if you prefer that.

I think that's reasonable.  Put an assert in the URILoader code to enforce this, maybe 
(with a debug-only boolean member set across the DoContent call or something)?

> hmm, guess we never store the uricontentlistener we chose? if we do,
> DispatchContent could just compare the new one to the current one and fail if
> they are equal (after CanHandleContent/IsPreferred returned true)

It's almost worse, actually.  We want to prevent oscillatory bouncing between two 
handlers that both want to fob the load off as the type the other one handles...  So 
extending this to allowing all handlers to redispatch would have to be done pretty 
carefully.

    
    

    
  
(In reply to comment #123)
> Why, though?  What's the use case for a null aData?

Well, when the handler has no data... f.ex. when wanting to redispatch in
onStartRequest... (do we expect embeddors to implement nsIExternalHelperAppService?)

> If we do plan to just keep this an exthandler-specific hack, it may be better
to just expose 
> that interface on aContext (basically have the object implementing the
nsIDispatchable 
> interface be the context, and have it forward to the original context as
needed).  Then the 
> interface could be in a .h file altogether or something, with all
documentation in that file.

Hm, yeah, that's also possible. Maybe that's better for now.

> It's a good precondition, but again only one that makes sense if we plan to
have multiple 
> handlers that get an nsIDispatchable. If we do, then a lot of these comments
make more 
> sense...

This is the question... I certainly considered that case; but is it something we
really want to do?

If we want to ever replace nsIExternalHelperAppService::doContent with
nsIURIContentListener2::doContent (not saying that we want that; just a random
thought), then it does need to have some way to get at the nsIDispatchable.

> It's almost worse, actually.  We want to prevent oscillatory bouncing between two 
> handlers that both want to fob the load off as the type the other one
handles...  So 
> extending this to allowing all handlers to redispatch would have to be done
pretty 
> carefully.

ah, hmm... to prevent that, we'd need a stack of handlers (or mime types) and
ensure the new type is not in the list...


So I'll probably just use your suggestion of making nsIDispatchable available
off aContext. putting it in a .h would mean it can't be used from a
JS-implemented exthandler; do we want to support that?

    
    

    
  
> (do we expect embeddors to implement nsIExternalHelperAppService?)

I'm tempted to say "no".  We have hooks already to modify behavior; changing it 
altogether would have too many security implications to be worth supporting, I think.  We 
should just clearly document that this is an interface exposed by gecko and move 
towards freezing it, I think.... (not in the current state, though).

> If we want to ever replace nsIExternalHelperAppService::doContent with
> nsIURIContentListener2::doContent

I think this is a good goal, and when we do this we should revisit nsIDispatchable and its 
implementation with that expanded role in mind...

    
    

    
  
So, contrary to the above comments, I do not really want to expose this
interface on aContext... currently that's just the docshell, but if it should
expose reDispatch, I need to extend that context, probably wrap it somehow. that
doesn't seem worth the code to me. On the other hand, adding it to docshell's
list of interfaces seems wrong - getting this from a docshell is, I think, not
something we want to support.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        backend patch, v3 (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #165908 -
        Attachment is obsolete: true

        Attachment #176645 -
        Flags: review?(bzbarsky)
Status: NEW → ASSIGNED
Target Milestone: mozilla1.8beta1 → mozilla1.8beta2

    
    

    
  
Comment on attachment 176645 [details] [diff] [review]
backend patch, v3

>Index: base/nsURILoader.cpp

> +nsresult nsDocumentOpenInfo::DispatchContent(nsIChannel *aChannel,

>+    aChannel->SetLoadFlags(loadFlags | nsIChannel::LOAD_RETARGETED_DOCUMENT_URI
>                                     | nsIChannel::LOAD_TARGETED);

Fix indent of second line here?

>Index: exthandler/nsIDispatchable.idl
>+   * When this method is successful, the current handler's onStopRequest method
>+   * will be called with a status of NS_BINDING_REDIRECTED.

I don't actually see us doing this anywhere.  Did I miss something?  Should we
be calling OnStopRequest on oldListener when we reDispatch?

r+bzbarsky with these issues addressed.

        Attachment #176645 -
        Flags: review?(bzbarsky) → review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        backend patch, v4 (obsolete)
        — 
          — Splinter Review
      

    


  
transferring r=bz

this includes the following change for onStopRequest/NS_BINDING_REDIRECTED:
(the if for the else is if (!oldListener))
--- base/nsURILoader.cpp	8 Mar 2005 00:21:40 -0000
+++ base/nsURILoader.cpp	9 Mar 2005 21:22:09 -0000
@@ -445,7 +445,11 @@
       status = rv;

     m_targetStreamListener->OnStopRequest(aChannel, nsnull, status);
+  } else {
+    // Otherwise, send the final onStopRequest to the old listener
+    oldListener->OnStopRequest(aChannel, nsnull, NS_BINDING_REDIRECTED);
   }
+
   return NS_OK;
 }

        Attachment #176645 -
        Attachment is obsolete: true

        Attachment #176937 -
        Flags: superreview?(darin)

        Attachment #176937 -
        Flags: review+

    
    

    
  
Comment on attachment 176937 [details] [diff] [review]
backend patch, v4

>Index: exthandler/nsExternalHelperAppService.cpp

>+NS_IMETHODIMP nsExternalAppHandler::GetCanCallHandleAs(PRBool* aCanHandleAs)
>+{
>+  *aCanHandleAs = mDispatchable != nsnull && mApplyingDecoding;
>+  return NS_OK;
>+}

please add a comment explaining why mApplyingDecoding modifies
the value of this attribute.  also, it might read a little
better as:

  *aCanHandleAs = mDispatchable && mApplyingDecoding;


> NS_IMETHODIMP nsExternalAppHandler::OnStopRequest(nsIRequest *request, nsISupports *aCtxt, 
>                                                   nsresult aStatus)
> {
>+  if (aStatus == NS_BINDING_REDIRECTED)
>+    return NS_OK;

NS_BINDING_REDIRECTED is normally not seen by a nsIStreamListener
unless someone refused to allow a HTTP redirect through.  This
status code is seen by a loadgroup observer, however.  Do you 
maybe mean NS_BINDING_RETARGETED?  At the very least this deserves
a comment to explain what's going on.

Also, I don't think we should overload the meaning of
NS_BINDING_REDIRECTED.


>+NS_IMETHODIMP nsExternalAppHandler::HandleAs(const nsACString& aMIMEType)
>+{
>+  // Ensure that this is allowed
>+  PRBool canHandleAs;
>+  nsresult rv = GetCanCallHandleAs(&canHandleAs);
>+  if (NS_FAILED(rv) || !canHandleAs)
>+    return NS_ERROR_UNEXPECTED;

So, it is okay to call HandleAs without checking GetCanCallHandleAs?
I'm asking it because it seems to be the case that I could write code
that doesn't check but rather handles the NS_ERROR_UNEXPECTED error.


>+
>+  NS_PRECONDITION(!aMIMEType.IsEmpty() && IsASCII(aMIMEType),
>+                  "Invalid MIME Type argument");
>+
>+  nsCOMPtr<nsIChannel> channel(do_QueryInterface(mRequest));
>+  if (!channel)
>+    return NS_ERROR_NOT_AVAILABLE;

should this perhaps be checked in canCallHandleAs?


>Index: exthandler/nsIDispatchable.idl

>+/**
>+ * This interface allows re-dispatching a request to a different content
>+ * handler. It is useful to allow a user to choose to view a file as a
>+ * different type than it really is.
>+ */
>+[scriptable, uuid(69314C16-EDAD-4c9d-931C-DE2D438F9CF7)]
>+interface nsIDispatchable : nsISupports

I'm not crazy about the name of this interface.  The name suggests
that this would have a method named dispatch or something.  How
about coming up with a name that is more specific.

nsIDocumentOpenInfo is not great of course.

What it seems like to me is that you are retargeting the channel.
Maybe that is because I am necko-centric, but nsIChannel does have
a LOAD_TARGETED flag that corresponds to when a channel has a final
consumer.

Part of the problem here I think is that you are forced into exposing
this as a callback interface because of nsIExternalHelperAppService::
DoContent.  But, in reality, no one but nsURILoader.cpp should ever
care to pass a nsIDispatchable to that DoContent.  It seems to me that
consumers outside this module will instead focus on the HandleAs API.
So, it seems to me that we might be unnecessarily introducing a XPCOM
interface for communication between nsDocumentOpenInfo and 
nsExternalAppHandler.  Why not deCOMtaminate this relationship?

I'm also not fond of canCallHandleAs.  That just doesn't read well.
allowsHandleAs, permitsHandleAs, or supportsHandleAs might be better.

        Attachment #176937 -
        Flags: superreview?(darin) → superreview-

    
    

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

    
    

    
  
(In reply to comment #28)
> 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.

I'm just quoting this because it's basically what I was going to say.

Google is serving up files with text/rfc822-headers in error mails, and I would
like to have read that in the browser.

    
    

    
  
Errors that this will solve are very rare and non for
ordinary users either, long fixing is proof ;-).

There're 2 issues: transfer encoding and MIME type of content.
So my proposal for GUI is here, click GUI but not use code (-:
<http://flower.upol.cz/~olecom/bugs/m-57342/nsHelperAppDlg.xul>
Note that i propose to use list of internal MIME handlers.
Also if link will be downloaded, navigators's tab or window must
not be opened at all.

Menu from that link maybe only useful if there's info about errors:
<https://bugzilla.mozilla.org/show_bug.cgi?id=11521#c25>


    
    

    
  
that UI seems a bit complex...

    
    

    
  
I actually think it's a pretty nice UI, the only problem is options 4 and 5
being a bit confusing.  I think it could say 
"View in Firefox as v|a web page|"
                     |plain text|"

That would be nice and easy

    
    

    
  
(In reply to comment #80)
> But there *does* need to be an escape route, because the failure mode results in
> far more effort than is reasonable to work around, currently. It *should* just
> work transparently, yes, but it sometimes doesn't and in those cases it really
> doesn't need to fail that badly.

John is absolutely right.  We should be mortified that this bug is still open
after 5 years.  The user needs to be able to cope with misconfigured servers by
<a href="http://forcecontenttype.mozdev.org/screenshots.html">changing the
content type</a>.

The last 9 months of comments on this bug are an impenetrable morass of patch
discussion.  Can someone please summarize the current state of affairs?

    
    

    
  
> Can someone please summarize the current state of affairs?

someone needs to update the patch per comment 130; something which I haven't yet
found the time for.

    
    

    
  
(In reply to comment #137)
> someone needs to update the patch per comment 130; something which I haven't yet
> found the time for.

Thanks for the info.  Can anyone expand on that a bit?  From a user's
perspective, what will this patch accomplish?

    
    

    
  
> From a user's perspective, what will this patch accomplish?

nothing. someone will also have to write UI code.

    
    

    
  
(In reply to comment #139)
> > From a user's perspective, what will this patch accomplish?
> 
> nothing. someone will also have to write UI code.

Can that be done in javascript?  I'm willing to work on it, but I don't know any
internal APIs.

    
    

    
  
(In reply to comment #136)
> (In reply to comment #80)
> > But there *does* need to be an escape route, because the failure mode results in
> > far more effort than is reasonable to work around, currently. It *should* just
> > work transparently, yes, but it sometimes doesn't and in those cases it really
> > doesn't need to fail that badly.
> 
> John is absolutely right.  We should be mortified that this bug is still open
> after 5 years.  The user needs to be able to cope with misconfigured servers by
> <a href="http://forcecontenttype.mozdev.org/screenshots.html">changing the
> content type</a>.
> 
> The last 9 months of comments on this bug are an impenetrable morass of patch
> discussion.  Can someone please summarize the current state of affairs?

I will _not_ install jslib on my box for it.
JS in mozilla has many bugs with linux i want to fix.
IMHO jslib is another _easy lame way_ !
External extensions maybe used only if mozilla can't handle it by itself,
so it will no forest of menus and options.

GUI ? I may do GUI in way i proposed, and it is useful but not complex.


    
    

    
  
can that discussion be moved elsewhere, please...

    
    

    
  
(In reply to comment #134)
> that UI seems a bit complex...

For firefox user yes ;-)
Issue with options 4 and 5 is that they propose conversion prior
to problems.

My new proposal is to move dialog with this options in "View/Show As"
menu, while adding only "new as text/plain" option in open dialog,
thus solving problems like this:
  - try to view any image from <http://www.elf.org/pnglets/>
  - <http://flower.upol.cz/~olecom/bugs/m-57342/eindex>



    
  
No longer blocks: majorbugs

    
    

    
  
SUBJECT: Another user situation description.

AGENT: Mozilla 1.7.8
Mozilla/5.0 (X11; U; Linux i686; pt-PT; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

1) A "proper behavior" example.
This seems to be a problem not only of Mozilla but also of malformed server
configs. I've tryied opening directly C/C++ source code files by typing the URL
on the address bar, and the file is rendered (as expected) as text/plain. By
right-clicking the rendered text window and selecting Page Info, it reports it
is MIME type "text/plain" (not "text/x-csrc" or similar? weird...), with "Quirks
mode" rendering mode. For the time-being I have an example at
http://fisica.fc.ul.pt/~jbatista/tstamp.c

2) A "improper behavior" example.
On other examples I've seen (regretably, it's behind a firewall so it's no point
[and I've tried!] putting the URL here, sorry), even though I've explicitly
edited the HTML anchor to assign type="text/x-csrc" and even type="text/plain",
this is what happens. The browser complains it DOES NOT recognize the MIME type
text/x-csrc (i.e., it correclty identifies the MIME type...) and asks how the
file should be opened. The specific link points to a *.c file linked to by a
Tikiwiki page ( http://www.tikiwiki.org/ ), this page being generated by a PHP
script. Now, IMHO it is likely that the Tikiwiki somehow screws up the Content
Type string (if indeed one is sent).

So, IMHO it seems that if some server-side application (Tikiwiki most certainly,
some Apache configurations likely) attempts to interpret the file's contents and
send the Content Type string. However, Mozilla does not know what to do with
text/x-csrc MIMEs. On the other hand, it appears in example 1) that there was no
inclusion of a "Content Type" string in the data stream, and the stream is
identified by Mozilla as text (hence the text/plain). But I'm just theorizing
since I haven't looked into the Mozilla code...

I suppose there are ways to have a look at the data stream's content, right? How
is it done (pardon the newbie question)? If someone tells me I'm likely to try
it and post here the results, if there's interest on them.  :-)



    
    

    
  
João,

the MIME-type is set by the webserver, not the browser. So it's the webserver
that chooses text/plain for a *.c file. Apache uses  the file-extension for it,
it doesn't look in the contents.

Note that Gecko gives priority to the HTTP-header 'Content-Type', not to a
META-tag. So your webpage can't override it inside the page (example 2), unless
there's a way to specify the header (user the header-function in PHP for
example, but that has to be done before the first line is printed).



    
    

    
  
(In reply to comment #144)
> right-clicking the rendered text window and selecting Page Info, it reports it
> is MIME type "text/plain" (not "text/x-csrc" or similar? weird...),

That is because the server sending the file said it was text/plain.

> I suppose there are ways to have a look at the data stream's content, right?
> How is it done (pardon the newbie question)?

For this example the interesting question is simply "what type is the server
labeling this file as?"  You can check like this:

$ telnet fisica.fc.ul.pt 80
HEAD http://fisica.fc.ul.pt/~jbatista/tstamp.c HTTP/1.1
Host: fisica.fc.ul.pt

HTTP/1.1 200 OK
...
Content-Type: text/plain; charset=ISO-8859-1

    
    

    
  
(In reply to comment #146)
> (In reply to comment #144)
> > I suppose there are ways to have a look at the data stream's content, right?
> > How is it done (pardon the newbie question)?
> 
> For this example the interesting question is simply "what type is the server
> labeling this file as?"  You can check like this:
> 
> $ telnet fisica.fc.ul.pt 80
> HEAD http://fisica.fc.ul.pt/~jbatista/tstamp.c HTTP/1.1
> Host: fisica.fc.ul.pt
> 
> HTTP/1.1 200 OK
> ...
> Content-Type: text/plain; charset=ISO-8859-1

Hi Chapman,

FYI my results are below. As you can see in both cases, for which I obtain
different results, the Content-Type is the same, namely text/x-csrc. It's even
more confusing because the PHP generated the (apparently) correct HTML: I got
"<a
href="temp/4587d12e416c8ab1e8ba9b11d9d47f7c/4587d12e416c8ab1e8ba9b11d9d47f7c.C"
target="_blank" type="text/x-c++src"><p align=center>Click here to view this
ROOT C++ script's source code</p></a>" as I would expect, but the problem persists.

HOWEVER, if I change the file's name to have an extension .txt instead of .C,
then it opens with no problem...  :-o

For the first ("good") link:
--------------8<--------------8<--------------8<--------------8<--------------
$ telnet fisica 80
Trying 194.117.43.10...
Connected to fisica.fc.ul.pt.
Escape character is '^]'.
HEAD
/tikiwiki/temp/4587d12e416c8ab1e8ba9b11d9d47f7c/4587d12e416c8ab1e8ba9b11d9d47f7c.C
HTTP/0.9

HTTP/1.1 200 OK
Date: Thu, 08 Sep 2005 16:28:43 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d
Last-Modified: Thu, 08 Sep 2005 07:51:20 GMT
ETag: "7c008-22-431fed78"
Accept-Ranges: bytes
Content-Length: 34
Connection: close
Content-Type: text/x-csrc

Connection closed by foreign host.
--------------8<--------------8<--------------8<--------------8<--------------


For the second ("bad") link:
--------------8<--------------8<--------------8<--------------8<--------------
$ telnet fisica 80
Trying 194.117.43.10...
Connected to fisica.fc.ul.pt.
Escape character is '^]'.
HEAD /~jbatista/tstamp.c HTTP/0.9

HTTP/1.1 200 OK
Date: Thu, 08 Sep 2005 16:29:03 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d
Last-Modified: Thu, 08 Sep 2005 07:36:19 GMT
ETag: "1ec007-9f-431fe9f3"
Accept-Ranges: bytes
Content-Length: 159
Connection: close
Content-Type: text/x-csrc

Connection closed by foreign host.
$

--------------8<--------------8<--------------8<--------------8<--------------


    
    

    
  
(In reply to comment #147)
I'll keep this comment brief as this issue seems to be veering OT for this bug:

> For the second ("bad") link:
> $ telnet fisica 80
> Trying 194.117.43.10...
> HEAD /~jbatista/tstamp.c HTTP/0.9
> 
> HTTP/1.1 200 OK
> Server: Apache/1.3.33 (Debian GNU/Linux) PHP/4.3.10-15 mod_ssl/2.8.22
OpenSSL/0.9.7d
> Content-Type: text/x-csrc

The curious thing here is that you've queried the same server for the same
file I queried in comment #146 and the server gave you a different content
type than it gave me.  Even more curious, a couple of lines I clipped from
comment #146 to keep it brief, but still have in my xterm:

Trying 194.117.43.10...
...
Server: Apache/2.0.54 (Gentoo/Linux) PHP/4.3.11 mod_ssl/2.0.54 OpenSSL/0.9.7e

So, we've both connected to the same IP address, but got distinctly different
servers on different machines.  I would guess fisica is doing some load sharing
among different machines behind the same outside IP, and they are configured
differently. Getting different content types for the same file on different
occasions could cause some puzzling symptoms.  But probably beyond the scope of
this bug (except as another illustration of why it would be really useful to
be able to override the declared content type when needed).


    
    

    
  
(In reply to comment #148)
> Getting different content types for the same file on different
> occasions could cause some puzzling symptoms.  But probably beyond the scope of
> this bug (except as another illustration of why it would be really useful to
> be able to override the declared content type when needed).
> 

My feelings exactly. IMHO it would be sensible to allow the user to circumvent
badly configured Web servers, by allowing the user to select an appropriate
action -- at least on those occasions that Mozilla finds out it does not know
what to do with a given MIME type.


On this note, I would vote for the UI look on comment #62 , perhaps clarifying
on those entries with the MIME type in parethesis, eg:
  (o) View as [Text    v]
              +------------------+
              | Text (plain/text)|
              | Image (image/*)  |
              | HTML (text/html) |
              | XML (text/xml)   |
              | Other...         |
              +------------------+
I'm hesitant to suggest that selected MIME types with "Other..." would show up
after being selected. E.g., if the user chose to open an URL using a MIME type
application/x-pdf, then the appropriate entry would also show up on subsequent
calls of the drop-down menu.



    
    

    
  
(In reply to comment #149)
> (o) View as [Text    v]
>               +------------------+
>               | Text (plain/text)|
>               | Image (image/*)  |
>               | HTML (text/html) |
>               | XML (text/xml)   |
>               | Other...         |
>               +------------------+
> 
> I'm hesitant to suggest that selected MIME types with "Other..." 
> would show up after being selected.  E.g., if the user chose to 
> open an URL using a MIME type application/x-pdf, then the 
> appropriate entry would also show up on subsequent calls of the 
> drop-down menu.

I'm hesitant to think we should go this far.  A reasonable start 
would be to list the formats that the browser has built in.  Listing 
plugins here might clutter it up, especially as more are added, so it 
might make sense to separate them off somehow.  And if we put the 
plugins in a separate list, how sensible would it be to have all 
installed plugins in one list?


    
    

    
  
I agree. I think we should start with the basic menu, without "Other...", and go
from there.

    
    

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

    
    

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

    
    

    
  
Apologies, I can't figure out the status of this bug from the last few posts on it. I like the sound of comment #102.  This feature seems to be being held up by implementation problems for on-the-spot user decision of what to do.  Comment #102 suggests an approach whereby a user can specify in advance what MIME types he wants to view inline always. Why can't *THAT* be implemented first (and seperately), and then when *this* finally gets done, there can be a tick box "always do this", which is the equivalent of the configuration gizmo?

In other words, why isn't there a seperate bug for what I outline above so that there is actually a way to handle the problem, for now, and stop people whining on this bug?

    
    

    
  
Why don't we just implement "View as text" first, then worry about other formats later?

    
    

    
  
(In reply to comment #155)
> Why don't we just implement "View as text" first, then worry about other
> formats later?

? that doesn't make any difference in terms of development effort.

    
    

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

    
    

    
  
I've found that creating a MIME handler of:

mozilla -remote 'openFile(%s)'

does pretty much exactly what I want. Surely it can't be that hard for someone who knows the codebase to implement that internally?

    
    

    
  
Security consideration: Gmail appears to use content-disposition: attachment to prevent HTML attachments from being used in XSS attacks.  We should avoid breaking that if we add this feature.

    
    

    
  
(In reply to comment #159)
> Security consideration: Gmail appears to use content-disposition: attachment to
> prevent HTML attachments from being used in XSS attacks.  We should avoid
> breaking that if we add this feature.

Concerning content-disposition, see bug 185618. But not taking content-disposition into account is the right way, as it is a non-standard header, which should thus be ignored (though a different behavior could also be chosen as an option). If Gmail is based on such a non-standard feature for security consideration, then it is highly broken.

    
    

    
  
Content-disposition is described in http://www.faqs.org/rfcs/rfc2183.  It is also mentioned in the "Security considerations" section of the HTTP spec (http://www.faqs.org/rfcs/rfc2616), although it's not clear what security considerations it's talking about.

Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong".

    
    

    
  
(In reply to comment #161)
> Content-disposition is described in http://www.faqs.org/rfcs/rfc2183.  It is
> also mentioned in the "Security considerations" section of the HTTP spec
> (http://www.faqs.org/rfcs/rfc2616), although it's not clear what security
> considerations it's talking about.

The security considerations concern the directory path information. I've mentioned it in bug 185618 comment 45.

Concerning this bug 57342, whose goal is to be able to view the contents for unsupported media types, there's nothing to save, therefore no security problems.

> Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong".

When a non-standard feature modifies the normal behavior documented in standards (in a non-optional way), this is a bug.

    
    

    
  
> Btw, I'm not sure I agree with the way you equate "non-standard" with "wrong".

I'm not sure I agree with the hidden implication that something is "right" just because Gmail does it.

    
    

    
  
For those who can't wait for this to be implemented, I've made an extension to open documents in browser. It is a kind of hack, but it can make life easier for some people:

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


    
    

    
  
The extension is great. Just what I was looking for !!

Thanks !

    
    

    
  
Great extension. Do you think you could add application/pdf to its known MIME-types?

    
    

    
  
(In reply to comment #166)
> Great extension. Do you think you could add application/pdf to its known
> MIME-types?

That could be added to the feature list.

Please use the mozillazine forum (http://forums.mozillazine.org/viewtopic.php?t=430010) for such requests, as this is outside of the topic of this bug. Thanks



    
    

    
  
I have been using the extension of Sylvain (http://www.spasche.net/mozilla/) for a while now, and indeed, it is great.

However, this is basic browser functionality and should NOT be a custom extension. All it does is make the browser behave as it always should have, and as Opera has done since at least version 3.5 (!).

Please incorporate this extension or it's functionality into the standard browser code!

    
    

    
  
(In reply to comment #168)
> Please incorporate this extension or it's functionality into the standard
> browser code!

I agree. I think this is important, not just for Firefox users, but for the web in general. Indeed an extension is not sufficient, otherwise many users won't be able to see text/* files by default, meaning that web authors will give an incorrect media type to source files, just to be compatible with Firefox.

Could this block the next Firefox version?

    
    

    
  
(In reply to comment #169)
> Could this block the next Firefox version?

Maybe if there's an unrejected patch against the trunk... either based on the extension or the previous patch. Otherwise, not really. Unfortunately.



    
    

    
  
Did it ever dawn on you that this is a Gecko bug? A lot of other applications benefit from Gecko too, not just Firefox.

    
    

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

    
    

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

    
    

    
  


  
This is an update of the latest patch against trunk. It does not address Darin's comments yet. As one could expect, it did not apply cleanly, so I had to manually merge some stuff.

I had not much success with this new patch applied: If I select for instance text/html for the mime to redispatch, I'm getting assertion:

###!!! ASSERTION: nsExpatDriver didn't get an nsIExpatSink: 'Error', file /[...]/mozilla/parser/htmlparser/src/nsExpatDriver.cpp, line 1180

Then the originating window is staying in loading state (the spinner is running), and if I click on the window, I can see the assertions:

WARNING: NS_ENSURE_TRUE(aPresContext->Document()->GetWindow()) failed: file /[...]/mozilla/content/events/src/nsIMEStateManager.cpp, line 174

When stepping inside the nsDocumentOpenInfo::ReDispatch function, I can see that the 
m_targetStreamListener->OnDataAvailable() call is failing and is in the callstack when the nsIExpatSink assertion is thrown.

If you have any hints about this, they are welcome.

        Attachment #176937 -
        Attachment is obsolete: true

    
    

    
  
The issue comes when nsDocumentOpenInfo::ReDispatch is called after the initial request is finished (OnStopRequest called).

In that case, the call to aChannel->SetContentType(aMIMEType) in nsDocumentOpenInfo::ReDispatch does not change the content type, as the channel has no listener any more. Because the content type did not change, the parser thinks it is XML, that's why we saw expat exceptions.

I tried to hack nsHttpChannel::SetContentType to force setting the content type, even when it has no listeners. That fixes the expat assertion and the page displays, but the spinner keeps running and there's some assertions appearing:

-1610559552[2307150]: WARNING: NS_ENSURE_TRUE(aPresContext->Document()->GetWindow()) failed: file /[...]/mozilla/content/events/src/nsIMEStateManager.cpp, line 174
-1610559552[2307150]: ###!!! ASSERTION: win is null.  this happens [often on xlib builds].  see bug #79213: 'Error', file /[...]/mozilla/content/events/src/nsEventStateManager.cpp, line 957

If Redispatch is called while the request is not finished, things seem to be working better (spinner stop running after page is finished). I used the following useful URL for testing:
http://www.hixie.ch/tests/evil/page-loading/incremental/001.cgi

    
  
Depends on: 369787

    
    

    
  
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.

    
    

    
  
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.
Assignee: cbiesinger → jduell

    
    

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

    
  
QA Contact: chrispetersen → file-handling
Target Milestone: mozilla1.8beta2 → ---

    
    

    
  
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.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        PoC modal dialog
        — 
          — Splinter Review
      

    


  
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.

    
    

    
  
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.

    
  
Depends on: 504441

    
    

    
  
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.

    
  
See Also:  → https://launchpad.net/bugs/25830

    
    

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

    
    

    
  
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.

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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.
See Also:  → 196078

    
  
Product: Core → Firefox
Version: Trunk → unspecified

    
    

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

    
  
Assignee: jduell.mcbugs → nobody
Status: ASSIGNED → NEW

    
    

    
  
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.



    
    

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



    
    

    
  
(In reply to Stewart Gordon from comment #218)


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.



    
    

    
  
Just a restate for my comment #57 from 16 years ago 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...



    
    

    
  
(In reply to Michael Lippert from comment #219)




(In reply to Stewart Gordon from comment #218)


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



    
    

    
  
Backlog grooming: bugs without an assignee cannot be P1.


Priority: P1 → P3

    
    

    
  
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.



    
    

    
  
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?



    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: