121498 - Need a "Use Mozilla" option on helper apps dialog

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Håkan Waara]

Very often when I visit FTP sites with unknown filetypes, I want to open them in
Mozilla. But in order to do this I need to click "Choose Application..." and
find mozilla.exe.

I think a "Use this browser" or "Use Mozilla" radiobutton (as in NS4.x) would be
great.

Boris wanted me to include this cryptic note: "nsIMIMEInfo::handleInternally is
broken".

Comment 1

[Håkan Waara]

I was thinking of fixing this myself, but bz told me it involves architecture
changes and such ... so I'll leave it to someone else.

Nominating for mozilla1.0; pretty please fix this before 1.0. :-)

Comment 2

[Boris Zbarsky [:bzbarsky]]

ccing mscott and law.  The cryptic note is the heart of this bug.  :) 
Basically, at some point in all the uriloader/exthandler rewrites the ability to
set handleInternally on a mime info in DoContent(), set the type to something we
have a viewer for, and let things load in the browser went away.

This whole situation is compounded by the fact that by the time we put up the
helper app dialog the stream is already being written to a temp file!  So
showing the data at that point requires jumping through some hoops...

Granted, killing off that "pre-downloading" behavior would help here.

Comment 3

[Peter Trudelle]

->law, but we're not doing the work we'd planned on for this release cycle. 
adding helpwanted keyword.

Comment 4

[Bill Law]

Does "use Mozilla" imply "treat as text/plain?"  Or do we need more?

Setting target milestone to Future.  I think a simplistic "open as text/plain"
option wouldn't be too hard to do.

Comment 5

[Håkan Waara]

I think it means we should fall back onto the unknown decoder, and 'guess' the
filetype, and as a last case if everything else fails, display the data as raw text.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> I think a simplistic "open as text/plain" option wouldn't be too hard to do.

I tried that.  Reset the mimeinfo to handleInternally, reset the type to
text/plain in DoContent.  You get a dialog asking what to do with it. 
Basically, once we're in that code I don't see how we can feed the data back to
the browser....

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I think it means we should fall back onto the unknown decoder, and 'guess' the
> filetype

You mean ignore the server-provided type completely, right?

Comment 8

[Bill Law]

re: comment #6

Maybe the trick is to (re)call some function that we've already gone through?
That is, call the function that called nsExternalHelperAppService::DoContent (or
even further back).  Theoretically, it would do something different since the
content type is different.

Comment 9

[Håkan Waara]

> You mean ignore the server-provided type completely, right?

I mean, if the "Use Mozilla" option is chosen, and the server provides a type we
know how to handle - do it, otherwise use the unknown content decoder and guess,
and as a last resort, open as plain text.

Comment 10

[timeless]

personally, i'd like to be able to say: (*) use mozilla's [text/html |^] 
engine
... but i have lots of pipe dreams

Comment 11

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

ah! here it is! I knew I had seen this bug.

I'd say this is a dupe of one of the following bugs:
bug 185618
bug 57342
bug 11521

Comment 12

[Aaron Kaluszka]

I guess this is slightly different since a) the content-disposition header
doesn't apply b) we're talking about more than text/* handling, c) we're talking
about automatic detection of mimetype.  -> adding depends on bug 11521

Comment 13

[Mike Cowperthwaite]

(In reply to comment #11)
> ah! here it is! I knew I had seen this bug.
> 
> I'd say this is a dupe of one of the following bugs:
> bug 185618

Very similar, altho that seems to be focusing on the somewhat arcane problem of 
a document that, because it's been typed with "content-disposition:attachment",
triggers the "How to handle this..." dialog.  Solving this bug would solve that 
one.

> bug 57342

Also very similar; that proposes a more extensive solution to this problem, by 
allowing specification of exactly *how* Mozilla will handle the document 
(specifying the MIME type to use).  If that patch is ever implemented, this bug 
will be solved -- it's a subset.  If we had to dupe this bug, I'd pick 57342 as 
the earlier one.


> bug 11521

That describes both the issue of 57342 and the related issue of redisplaying a 
document already in the browser per a different filetype.

In terms of scope:
  11521 > 57342 > 121498 > 185618


I think Aaron's change to dependency is not only unnecessary but incorrect.

Comment 14

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081105 SeaMonkey/2.0a2pre - Build ID: 20081105000450

Trying to understand how relevant this bug is now, 4 years after the latest comment. In my "Helper Applications" prefs, for some types I see "use seamonkey" among the choices, for others "Preview in SeaMonkey", for others "use <plugin name> (in SeaMonkey)", for others none of them. The only always available options are "Always ask", "Save to disk" and "Use other...". I suppose this means I still see the problem.