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

NEW
Unassigned

Status

()

--
enhancement
19 years ago
3 years ago

People

(Reporter: cks+mozilla, Unassigned)

Tracking

(Blocks: 2 bugs, {helpwanted})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 2

19 years ago
over to XPApps.
Assignee: asa → don
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Ever confirmed: true
QA Contact: doronr → sairuh
pam/terri, would this fall into your realm?
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy

Comment 5

19 years ago
nav triage team:

Would be nice, but not a beta1 stopper, marking nsbeta1-, reassigning to mcafee
Assignee: vishy → mcafee
Keywords: nsbeta1-

Comment 6

18 years ago
Marking nsbeta1- bugs as future to get off the radar
Target Milestone: --- → Future

Comment 7

18 years ago
law
Assignee: mcafee → law

Comment 8

17 years ago
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. ***

Comment 10

17 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

17 years ago
Component: XP Apps → File Handling
Summary: [RFE] Support using external programs to show non-inlined images → Support using external programs to show non-inlined images
*** 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.

Comment 16

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

Comment 19

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

Comment 21

16 years ago
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.
QA Contact: sairuh → petersen
> 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.  

Comment 26

16 years ago
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?
Assignee: law → cbiesinger
OS: Linux → All
Priority: P3 → P2
Hardware: PC → All
Target Milestone: Future → mozilla1.5beta
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
Depends on: 212468

Comment 32

16 years ago
*** 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
Target Milestone: mozilla1.5beta → mozilla1.6alpha
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=image%2Fpng&disposition=inline&filename=&quote=1
Target Milestone: mozilla1.6alpha → mozilla1.7beta

Comment 36

16 years ago
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.
Whiteboard: biesi_testcase:http://192.168.1.1/~chb/testcase/mime2.php?do=1&type=image%2Fpng&disposition=inline&filename=&quote=1
Summary: Support using external programs to show non-inlined images → Support using external programs to show non-inlined images and other content
*** Bug 236195 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.7beta → mozilla1.8beta
*** Bug 239799 has been marked as a duplicate of this bug. ***
*** Bug 240067 has been marked as a duplicate of this bug. ***

Comment 41

15 years ago
*** 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
Assignee: cbiesinger → file-handling
Keywords: helpwanted
Priority: P2 → --
QA Contact: chrispetersen → ian
Target Milestone: mozilla1.8beta → ---
*** Bug 268083 has been marked as a duplicate of this bug. ***
*** Bug 204422 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 297643

Updated

11 years ago
Blocks: 363155
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Duplicate of this bug: 640618
Duplicate of this bug: 890412
Duplicate of this bug: 1100747
Duplicate of this bug: 1100747

Updated

3 years ago
Component: File Handling → File Handling
Product: Core → Firefox
Version: Trunk → unspecified
You need to log in before you can comment on or make changes to this bug.