412024 - Application name can be blank in Applications pref pane

Status: RESOLVED WONTFIX

(Firefox :: File Handling, defect, P3)

Description

[Simon Bünzli]

Steps to Reproduce:
1. Download uTorrent (1.6.1, maybe later versions as well) and have it set itself as default .torrent handler
2. Click on a link to a .torrent (any Linux distro should do) and tell Firefox to always open using the system's default handler ("uTorrent (default)")
3. Open the Applications pref pane

Expected result:
Content Type is "TORRENT file" and Application is "uTorrent" (or "Default TORRENT file handler")

Actual result:
Content Type is fine, but the Application field is blank when unselected and displays "Always Ask" when selected (which is just wrong).

Comment 1

[Simon Bünzli]

Attachment: screenshot showing the missing Application name

Comment 2

[Florian Quèze [:florian]]

You said "any linux distro" but I guess you mean Windows as the screenshot seems to come from Vista and uTorrent seems to exist only for Windows.

I tested this on Vista and couldn't reproduce exactly but I saw odd behaviors.
When uTorrent 1.6.1 is set as the system default handler for .torrent files:

 When I download a .torrent file, in the window asking if I want to save the file or open it with an application, uTorrent is listed as the system default. When I check the "Remember" check box, the next time I download a torrent file this window appears again with the checkbox already checked. It should just use the action I selected the previous time.

 When I go to the Applications prefpane and look at the "TORRENT file" row, no system default application appear and "Always ask" is selected. uTorrent is not in the list of applications.

I tried to look at this with venkman and it seems sometimes the "hasDefaultHandler" property is true for torrent files, and sometimes it's not.

Can anyone else reproduce exactly what is on the screenshot from comment 1, or get what I saw?

Comment 3

[Simon Bünzli]

(In reply to comment #2)
> You said "any linux distro" but I guess you mean Windows

Yeah, "any linux distro" meant "any legal torrent" to download.

> When I check the "Remember" check box, the next time I download a torrent file
> this window appears again with the checkbox already checked.

That's a different issue which AFAICT is due to the fact that the sent MIME type is application/octet-stream instead of application/x-bittorrent (don't remember the exact bug number). Try using a torrent from http://cdimage.debian.org/debian-cd/4.0_r2/i386/bt-cd/ for reproducing.


> When I go to the Applications prefpane and look at the "TORRENT file" row, no
> system default application appear and "Always ask" is selected.

What happens when you click onto a different Content Type?

Comment 4

[Florian Quèze [:florian]]

I have just fixed a mac bug (bug 412907) that had the exact same effect.

I wonder if the actual bug here could be the same: the MIME service working fine when given the extension, and broken when given the MIME type.

Comment 5

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot in Vista

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

Simon: I can reproduce, very easily, in a Virtual Machine of Vista Business.  See the screenshot, above, in comment 5.

Florian/Simon: how can I best help to troubleshoot this?

Comment 7

[Simon Bünzli]

I guess somebody will have to step through the code and see where we're not getting the expected info in the pref pane - and then try to figure out where the faulty API goes wrong...

Comment 8

[Florian Quèze [:florian]]

I don't know why I couldn't reproduce exactly the first time I tried, on my second attempt I could reproduce.

We get a blank row in the applications prefpane because the preferredAction is set to "useSystemDefault" but "hasDefaultHandler" is false (should be true).

I suspect the actual bug is in the MIME service.

When in the Error Console I evaluate this:
Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getFromTypeAndExtension("application/x-bittorrent", null).hasDefaultHandler
the result is false.

Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getFromTypeAndExtension("application/x-bittorrent", "torrent").hasDefaultHandler

and

Components.classes["@mozilla.org/mime;1"].getService(Components.interfaces.nsIMIMEService).getFromTypeAndExtension(null, "torrent").hasDefaultHandler

both return true.

I could not debug this further as I couldn't get a windows debug build.

Comment 9

[Simon Bünzli]

So, uTorrent doesn't register itself as the default handler for application/x-bittorrent in the registry. Adding the key
HKCR\MIME\Database\Content Type\application/x-bittorrent and in there a string value Extension = .torrent fixes this issue for me.

So the bug is that nsIMIMEService doesn't take into account the file extensions encountered in association with a given MIME type -- especially when the user has already confirmed that the application registered for the file extension was the one she wanted to use.

Or am I missing any case where you'd want different applications to handle the same MIME type when the files have different extensions?

Comment 10

[Simon Bünzli]

Attachment: wallpaper patch

What's happening at http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.361&mark=2324,2336#2322

(1) We get MIMEInfo from the OS which doesn't specify a default application
(2) HandlerService fills in the fact that the user opted for the default application nonetheless and most probably sets a primary extension
(*) Under those conditions, we don't return to the OS for asking whether there'd be a default application for the primary extension -- i.e. if aFileExt.IsEmpty() and after line 2336 the preferredAction is useSystemDefault but hasDefaultHandler is false, we should check the existence of a primaryExtension and restart from line 2324 (or call GetFromTypeAndExtension again with aFileExt set to the primaryExtension).

The attached patch does the same one level up in the HandlerService, though that's a wallpaper we shouldn't take if the above fix can be done by somebody with a build environment.

Comment 11

[Mike Connor [:mconnor]]

nice to fix, not a hard blocker

Comment 12

[Mike Connor [:mconnor]]

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

Comment 13

[Jim Mathies [:jimm]]

Adjusting tp P3. I've confirmed this and would like to see it get it in.

Comment 14

[Jim Mathies [:jimm]]

I'm not convinced we need to address this as it's application specific. If the folks managing the uTorrent project added a mime database entry for their extension everything would work. Try adding the mime entry type under:

HKEY_CLASSES_ROOT\MIME\Database\Content Type\application/x-bittorrent

with a string attrib "Extension" = ".torrent"

...and everything works. I'm inclined to mark this as WONTFIX.

Comment 15

[Jim Mathies [:jimm]]

if anyone feels this is more general and not specific to the config of uTorrent, pls post a comment or reopen.