58554 - Support using external programs to show non-inlined images and other content

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Chris Siebenmann]

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

Comment 1

[Doron Rosenberg (IBM)]

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

Comment 2

[Asa Dotzler [:asa]]

over to XPApps.

Comment 3

[sairuh (rarely reading bugmail)]

pam/terri, would this fall into your realm?

Comment 4

[Viswanath Ramachandran]

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

Comment 5

[Paul Chen]

nav triage team:

Would be nice, but not a beta1 stopper, marking nsbeta1-, reassigning to mcafee

Comment 6

[Paul Chen]

Marking nsbeta1- bugs as future to get off the radar

Comment 7

[Chris McAfee]

law

Comment 8

[David Richardson]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Brant Gurganus]

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

Comment 11

[Boris Zbarsky [:bzbarsky]]

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

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Tobias Kunze-Briseño]

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

Comment 15

[Tobias Kunze-Briseño]

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

Comment 16

[Jon Martin]

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

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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

Comment 19

[Jamie Wilmoth]

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.

Comment 20

[Boris Zbarsky [:bzbarsky]]

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

Comment 21

[Keith Pomakis]

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

Comment 22

[Tobias Kunze-Briseño]

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.

Comment 23

[Boris Zbarsky [:bzbarsky]]

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

Comment 24

[Tobias Kunze-Briseño]

> 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?

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Jamie Wilmoth]

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.

Comment 27

[Boris Zbarsky [:bzbarsky]]

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

Comment 28

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

taking...

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

Comment 29

[Boris Zbarsky [:bzbarsky]]

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

Comment 30

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

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.

Comment 31

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

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

Comment 32

[Andrew Schultz]

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

Comment 33

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

Attachment: patch (backend)

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

Comment 34

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

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.

Comment 35

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

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

Comment 36

[Grant Haavaldsrud]

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.

Comment 37

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

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

Comment 38

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

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

Comment 39

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

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

Comment 40

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

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

Comment 41

[R.K.Aa.]

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

Comment 42

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

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

Comment 43

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

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

Comment 44

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

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

Comment 45

[Boris Zbarsky [:bzbarsky]]

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