Build ID: current CVS build Right now, if you ask Mozilla to show an image that is not inlined into other content, either via 'View Image' or via giving it the URL directly (such as a direct link to a JPEG) the image is always shown by Mozilla inside a browser window. RFE: it should be possible to have Mozilla pass such images to an external application instead of showing it itself. The user may have applications that are better suited for the job than Mozilla itself; on various platforms there are image viewing programs that support, eg, better scrolling, image gamma manipulation, and so on. This is a Netscape 4.x compatability feature on at least Unix: NS 4.x allows you to do this via the Preferences | Navigator | Applications dialog set. This overriding should not stop Mozilla from displaying the images when they have been inlined in other content, eg as an IMG SRC in a HTML web page. There is probably a better component for this than Browser General, but I have no idea what it should be. (I feel so embarassed.)

And this does not work in mozilla? Kinda hard to check as helper apps is not working in recent builds.

over to XPApps.

pam/terri, would this fall into your realm?

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

nav triage team: Would be nice, but not a beta1 stopper, marking nsbeta1-, reassigning to mcafee

Marking nsbeta1- bugs as future to get off the radar

law

This bug is the only thing keeping me on 4.7 on both Windows and Unix.

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

[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.

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

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

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

ok, this bugged me so much that i dug in the sources and found a workaround. This bug is actually annotated in the sources (see http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#287 ff.) and involves routing mozilla through a proxy that adds a "Content-Disposition: attachment" header to the response headers of image/* objects. Then, the "Open Image (...)" popup menu will use the actual configured helper. Any proxy will do, but in case you use privoxy 3.0.0, feel free to apply this trivial patch: diff -r privoxy-3.0.0-stable/parsers.c privoxy-3.0.0-stable.patched/parsers.c 808a809 > 817a819,828 > > /* Add a "Content-Disposition: attachment" header to image response > * headers as a temporary fix for mozilla (which doesn't otherwise > * use external helpers for content that can be handled internally. > * > * See: http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#287 ff. > */ > if (strstr(*header, " image/")) { > enlist(csp->headers, "Content-Disposition: attachment"); > } Enjoy, and hopefully this bug will get resolved soon, -Tobias

minor correction: my workaround involves a proxy, not the bug. sorry for the goof-up.

This bug is the only thing keeping from replacing 4.8 with Moz in all my Unix labs.

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

In case anyone is tracking the status of this bug, here is the situation: What's needed is an efficient method of doing this -- one that does not regress pageload time. Going to user prefs and even worse the OS looking for a helper on every single pageload would be a noticeable performance penalty (_especially_ given the current state of the mailcap code on Linux). Worse yet, we have to deal with cases when the OS _does_ have a way to handle the type (eg text/html) and we have to somehow figure out that it still needs to be handled inline. Simply shipping with all the "internal" types defaulted to "handle internally" is not quite an option, since that would 1) mean not being unable to make use of OS extension associations for those types and 2) not be extensible (eg if the user installs a plug-in). Suggestions welcome (and no, special-casing image/* types is not a good suggestion, imo).

As is my understanding, this shouldn't have anything to do with normal page loads, so shouldn't have any performance effect on them. It's NON-inlined images only. So that basically applies to direct links to images, and when you right click an inlined image and select 'view image'. So this bug shouldn't have anything to do with the loading of an HTML (XML etc) type page. No? So making a helper check for a single image on just those specific occations should be insignificant (as done in Netscape 4.7). Unless I'm missing something, of course.

> right click an inlined image and select 'view image'. Which is just a normal page load. Exactly like clicking on a link that points to an image. It goes through the same exact code as XML and HTML loads until we have to instantiate a parser for it -- at that point the HTML gets an HTML parser and the image load gets treated differently. But that point is a long ways past where we decide whether to handle the load internally or not.

I haven't looked at the code or anything, but the logic that I see Mozilla following now when loading a top-level document is something like this: if a built-in Mozilla handler exists for the MIME type handle using built-in Mozilla handler else if MIME type is listed in "helper application" preferences launch helper application else report an error It seems to me that fixing this bug requires changing this logic to: if MIME type is listed in "helper application" preferences launch helper application else if a built-in Mozilla handler exists for the MIME type handle using built-in Mozilla handler else report an error Comment #18 seems to imply that checking the user's preferences is a time-consuming process, and will therefore affect the time it takes to display standard text/html pages. That sucks. Aren't the user preferences cached in memory? Either way, perhaps a solution to that is to make text/html an exception. I.e., make it not overridable by the user's "helper application" preferences. It's not likely that anybody will want to use a helper application to view HTML pages. That way, the logic would be: if MIME type is text/html (or any other non-overridable MIME type) handle using built-in Mozilla handler else if MIME type is listed in "helper application" preferences launch helper application else if a built-in Mozilla handler exists for the MIME type handle using built-in Mozilla handler else report an error

Maybe I just don't understand, but what exactly is the problem here? The procedure seems totally straightforward to me: if inline internal_handler() else if user_handler exec(user_handler) else if internal internal_handler() else ask_handler() /* maybe offering user or system mailcap handler */ if handler exec(handler) else punt() Actually, it should be trivial, since internal_handler(), exec(), ask_handler(), and punt() exist already. Surely there is also a way of telling whether a returning object is inline, and whether a certain type can be handled internally, is there? So, all that remains is to implement exists_user_handler(type); and even that one has to exist already, since mozilla calls handlers already. At any rate, it can't be less efficient than running everything through a proxy, as I do right now. Netscape 0-4 did it right. Everything else ought to be merely a matter of proper user pref caching, right? I wouldn't even think mailcap parsing/lookup is an issue here unless you want to offer suggestions lifted from various user of system mailcap files when presenting that "what should i do with this object" dialog.

> Aren't the user preferences cached in memory? No, since they include the OS settings. As I said, I refuse to write exceptions for specific MIME types into this code. (eg, I think we can all agree that text/html should probably be rendered inline, but what about, eg, XML? Where do we stop? Either we make the user able to configure this, or not; let's not just sorta hack it in). For comment 22, I'm not clear what your "is inline" test does. All data that this code encounters is "inline" -- being loaded in the main browser window. Netscape 0-4 had a totally different architecture for user helper app prefs than Mozilla does; doing the pref check there was much less expensive. And yes, running a proxy is less efficient, for you. It's more efficient for the 99.9% of people who really do want to view their images in the browser..... And we do indeed offer suggestions lifted from mailcap in the "what should I do with this object" dialog. Yes, this is a matter of caching prefs, then invalidating the cache when things change. Like pretty much rewriting how helper app data is fetched. Code is welcome.

> I'm not clear what your "is inline" test does. Each fetched object has a flag whether some other object (the enclosing page) depends on it, no? If not, it really should. A parent HTML or XML (when handled internally, that is, it is parsed by mozilla) should flag all inline (automatically fetched) objects as inline or required. After all, that's why it initiates their fetch in the first place, right? These would then be blocked from helper handling. > But that point is a long ways past where we decide whether to handle the > load internally or not. > ... > All data that this code encounters is "inline" -- being loaded in the > main browser window. Wouldn't you agree that that's simply wrong? It appears to me that the first decision is whether a particular object to be fetched is _required_ by some other object, not whether it is to be handled internally. Then, when the object comes back, my pseudocode would kick in. > the 99.9% of people who really do want to view their images in the browser Even if that were true, it is still irrelevant IMO. The point is that Mosaic, Netscape 0-4, Opera, Lynx, Emacs, and even IE get it right and Mozilla doesn't. All other browsers get it right, because it simply makes sense to use external applications if you have special needs. > And we do indeed offer suggestions lifted from mailcap in the "what should > I do with this object" dialog. So what? That happens only as a last-ditch effort of handling an object in at least _some_ way, right? Thus, it shouldn't have an effect on ordinary loading. What is the time penalty for parsing helper app prefs on every object? Does it matter?

> Each fetched object has a flag whether some other object (the enclosing > page) depends on it, no? Not relevant here. The code in question already only sees things that are "not inline" by that definition. The decision about whether it was required by something else has already been made; we are already in the toplevel else of your pseudocode. > Thus, it shouldn't have an effect on ordinary loading. In theory. In practice that requires a rewrite of the helper app interfaces and a refactoring of the helper app code to allow asking whether a user pref exists without _also_ asking at the same time whether there is a mailcap setting for it. > What is the time penalty for parsing helper app prefs on every object? Does > it matter? In the tens of milliseconds range, and yes -- any patch that increases pageload time by that much will be backed out, no questions asked. Perhaps I should clarify. I would like this to get fixed. I have outlined the technical issues that need to be solved to fix this, and I am quite willing to point people to the relevant code, discuss ideas, etc. But I have no time to work on the fix myself right now.

Okay. So yes, I don't expect the OS settings to be cached, but obviously it has to be decided at the point that you can decide you have an image (as far as this bug goes.. the solution may be more general) that isn't part of a larger page. You have to check somewhere that there is an external app to call for this. It can't be avoided. Now, it can be limited to those that are in the Mozilla Preferences -> Helper Applications dialog, in which there should be very few other than a couple of defaults and ones the user has added because they want it handled. Maybe cache their mime types. That's a small amount of data. Would be quick to check against? So then you avoid hits for those users (99.9% as said) that don't set one there, and works for those of us that do. (Though personally I suspect it's more than 50% that want it handled exernally, as that's why most other browsers appear to make it the default behavior.) How many non-plugin types are internally handled by Mozilla anyways? HTML, XML, various images.. anything else? So really, even if did resort to checking for types as said didn't want to, only need to check the ones Mozilla has built-in handling for, excluding html and xml at the least. Others already have to spend time looking for plug-ins or OS apps. So as far as I know, only would need to check image types that aren't being loaded by a page. So one of the above should hopefully point in the direction of a way of handling it.

> Now, it can be limited to those that are in the Mozilla Preferences -> Helper > Applications dialog Yep, that seems like the best solution. Just needs someone to do it. ;) The relevant APIs are nsIMIMEService and nsIMIMEInfo; the relevant code mostly lives in nsExternalHelperAppService and the various nsOSHelperAppService impls (the goal here would be to not hit nsOSHelperAppService, though). http://lxr.mozilla.org/seamonkey/source/layout/build/nsContentDLF.cpp#87 gives a lot of the types mozilla handles internally, but any add-on or embeddor can add others; this is why I would like to avoid hacking in a hardcoded list. Which reminds me -- this whole thing needs to somehow play nice with embedded builds. I suspect that it'll do it by default, but once we have a patch we can pick the embedding people.

taking... I would rather not make this specific to images, but allow overriding of all types. anyone have a problem with that?

Sounds fine, but watch for infinite loops (and in particular, someone overriding XUL may make the UI not load).

yeah, that xul thought occured to me as well... not sure what the best plan there is; I'd rather not special-case it... well I'll worry about it when I'll implement this.

the current usage of |defaultMimeEntries|/the mimeinfo hashtable conflicts with fixing this bug, marking appropriate dependency

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

wow, this was very simple really There are a few issues with this patch though: - it special-cases the text/html and xul mime type - it doesn't check if the datasource entry has an action != handleInternally (shouldn't matter much I think, as text/html (which was in default mimeTypes.rdf for some time) is special-cased anyway) oh, and it needs a frontend patch. bug 58557 can basically be backed out when this lands. though the frontend should take care of the mentioned special-casing... hm...

oh one more thing... that patch may or may not depend on bug 147679 - I tested in a tree that also had the patch for that bug.

ok. as bz pointed out, this patch has a major problem: if a user loads an image with content-disposition:attachment, he will get the helper app dialog. mozilla will store an entry in the datasource for that mimetype. Which means that with this patch, the user won't be able to view such images normally (except when part of a page)... note to self: so I should make that dialog store handleInternally and check the action in MIMETypeIsInDataSource. problem: this affects old profiles in a possibly rather bad way; that should not land in a beta version; TM -> 1.6alpha

Keith stated that if I wanted him to upgrade from Netscape 4.7 to Mozilla 1.5, I had to come here to vote for this particular bug to be fixed. Personally, I don't see what the big dealio is. So it takes a few extra steps to view the file in an external program. People are just too lazy these days, IMO. How was that, Keith? By the way, it's not totally my fault... although I have to admit that I was TOO LAZY to rename the jpg's after Andy gave them to me.

testcase in url field requires a helper app setup for image/png to be useful.

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

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

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

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

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

-> default owner... when someone wants to fix this, be sure to find a solution for comment 35

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

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