404434 - need icons for default handler in new protocol handling dialog

Status: NEW

(Firefox :: File Handling, defect, P3)

Description

[Dan Mosedale (:dmosedale, :dmose)]

It was pointed out in bug 389705 that we need an icon for the default local handler application for a given protocol.  The first thing we need to figure out is whether we're able to get that from the OS, and, if so, whether it's more-or-less guaranteed to be available anytime a handler application exists.

I've CCed some platform experts for Linux (ventnor), Mac (cbarrett), and Windows XP & Vista (jmathies) in the hopes that they can provide some input about that...

I suspect this at least wanted, possibly blocking Firefox 3.

Comment 1

[Michael Ventnor]

Urrgh, all these new bugs that I'd love to try but I can't because I can't access the references at library.gnome.org... :-(

Comment 2

[Michael Ventnor]

Well, miraculously I managed to load the site, but I don't think I can do this with the API's I am given. Someone who knows GNOME better than me will have to try.

Comment 3

[Jim Mathies [:jimm]]

appPicker has a short routine in it that grabs the icon for apps -  

http://lxr.mozilla.org/mozilla/source/toolkit/components/apppicker/content/appPicker.js#163

I believe this will work on all platforms. 

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

Jim: I guess that platform specific question that I was really trying to ask is "is it possible to get the file path for the default protocol handler on all platforms?".  I was under the impression that for the Windows case, it wasn't, but mfinkle thinks that's incorrect, and I'm hoping that's the case.  For Linux, it seems that we're already getting it but putting it into the description instead of someplace more sane.  For Mac, we don't already have it, but I'm hoping Colin knows if/how we can get it..

The cross-platform piece of this bug is "how do we expose that to the front end?".  Right now, nsMIMEInfoWin exposes this through a property on a property bag for the MIME-handler case.  We could extend this to protocol handlers and other platforms as well, which seems like a reasonable plan to me, and shouldn't be too hard.

Comment 6

[Jim Mathies [:jimm]]

This is easy to fix using the moz-icon solution (for mac and win at least). I've never seen a linux solution but for mac/win it's used in a number of places. The only handler types that won't display 'perfect' on windows are rundll handlers, which will show up as a standard system dll icon. That really isn't such a big deal imho. Fixing that I think is more work than we have time for before 3.0.

I was thinking of rolling this in with 400852 unless somebody has an issue with the solution. I'd handle local handlers the same way the app picker dialog works.

Comment 7

[Jim Mathies [:jimm]]

> The cross-platform piece of this bug is "how do we expose that to the front
> end?".

Sorry I missed this - so rather than doing the little trick with js, create a property someplace that returns the correct icon path?

Comment 8

[Jim Mathies [:jimm]]

Ok, so I think I see where you're headed here. I'm looking at the content dialog, which lists possible app handlers and then adds the default handler to the list. We don't expose the default handler as an nsIHandlerApp, we just provide a text description. Which is causing some trouble in 400852, since the new list of possible proto handlers includes the default, but we have no way of stripping out the default dupe in the list. On top of that, without the nsIHandlerApp of the default, we can't get the icon. So maybe we should just expose that.

Comment 9

[Jim Mathies [:jimm]]

Just a note - as a short term fix for this, rather than implementing the nsIHandlerApp stuff for the default handler (and if we could get mac and linux support on 400852) the little hack I have in place there that matches the default handler with it's corresponding nsIHandlerApp from possibleLocalHandlers could provide the icon.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

jimm: 

possibleLocalHandlers for mac (bug 397699) and linux (bug 397700) are have been given blocking-, so we're probably not going to get those.  

For the short term fix, it still looks to me (for Mac and Linux, anyhow), like the path of least resistance is to use a property bag like we currently do in nsMIMEInfoWin.

michael: we have the executable file path on linux; wouldn't generating an moz-icon: URI from that path do the right thing?

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

OK, my last comment was bogus in a couple of a ways.  For one thing, my comment to Michael was wrong: we don't have the executable path on linux.

I just spent some time talking to cbarrett about the Mac side of the house, and he points out that doing the possibleLocalHandlers work is likely to be about the same amount of work specifically figuring out the default handler.  This seems very likely to be true for Linux as well, assuming it's possible there.

So I'll assume that we can do what Jim suggests on all three platforms, and mark those bugs as blocking this one, and requesting that they block.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

Alex: have we sidestepped this by actually providing an icon?

Someone should renom if they disagree, but I don't think this blocks.

Comment 13

[Alex Faaborg [:faaborg] (Firefox UX)]

Attachment: Mailto handling on OS X

Here is an example of the issue, note that mail.app does not have an icon.  This is a pretty bad polish problem, we should at least ship with a generic application icon if we can't get the actual application icons.

Comment 14

[William Bardwell]

Any progress on this one?  I have an application that has a URL protocol handler on Windows which (like most URL protocol handlers) has an icon listed in HKEY_CLASSES_ROOT\<url stem>\DefaultIcon but that isn't displayed in the dialog box when you first hit one of these URLs, and that makes the dialog box very confusing.  (It looks like the item in the box is a label for an empty list, not the first (and default) choice.)

Comment 15

[Jim Mathies [:jimm]]

(In reply to comment #14)
> Any progress on this one?  I have an application that has a URL protocol
> handler on Windows which (like most URL protocol handlers) has an icon listed
> in HKEY_CLASSES_ROOT\<url stem>\DefaultIcon but that isn't displayed in the
> dialog box when you first hit one of these URLs, and that makes the dialog box
> very confusing.  (It looks like the item in the box is a label for an empty
> list, not the first (and default) choice.)

We need more information on the default handler, specifically the icon or exe location - 

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/handling/content/dialog.js#125

Or we need possibleLocalHandlers on all platforms so we can do a quick compare between the preferred and the possible list to find the local handler for the preferred.

Comment 16

[Dan Mosedale (:dmosedale, :dmose)]

Using an ifdef to do better on platforms with possibleLocalHandlers would have the advantage of preventing the perfect from getting in the way of the good.

Comment 17

[Jim Mathies [:jimm]]

(In reply to comment #16)
> Using an ifdef to do better on platforms with possibleLocalHandlers would have
> the advantage of preventing the perfect from getting in the way of the good.

If everyone is ok with that approach I'll see if I can get this working on windows.