Need a "Use Mozilla" option on helper apps dialog




File Handling
16 years ago
a year ago


(Reporter: Håkan Waara, Unassigned)


(Depends on: 1 bug, {helpwanted})

Firefox Tracking Flags

(Not tracked)




16 years ago
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

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

Comment 1

16 years ago
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. :-)
Keywords: 4xp, mozilla1.0
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.
Blocks: 21985

Comment 3

16 years ago
->law, but we're not doing the work we'd planned on for this release cycle. 
adding helpwanted keyword.
Assignee: trudelle → law
Keywords: helpwanted

Comment 4

16 years ago
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.
Target Milestone: --- → Future

Comment 5

16 years ago
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.
> 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....
> 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

16 years ago
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

16 years ago
> 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

16 years ago
personally, i'd like to be able to say: (*) use mozilla's [text/html |^] 
... but i have lots of pipe dreams
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
Assignee: law → file-handling
Severity: major → enhancement
Component: XP Apps → File Handling
QA Contact: sairuh → ian
Hardware: PC → All

Comment 12

14 years ago
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
Depends on: 11521

Comment 13

14 years ago
(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 

> 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.
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.
Assignee: file-handling → nobody
QA Contact: ian → file-handling


3 years ago
Duplicate of this bug: 947679


a year ago
Component: File Handling → File Handling
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.