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".
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. :-)
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.
->law, but we're not doing the work we'd planned on for this release cycle. adding helpwanted keyword.
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.
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?
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.
> 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.
personally, i'd like to be able to say: (*) use mozilla's [text/html |^] engine ... 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
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
(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.
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.