Application name can be blank in Applications pref pane




File Handling
10 years ago
10 years ago


(Reporter: Simon Bünzli, Assigned: jimm)


Windows XP
Bug Flags:
blocking-firefox3 -
wanted-firefox3 +

Firefox Tracking Flags

(Not tracked)



(3 attachments)



10 years ago
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

10 years ago
Created attachment 296635 [details]
screenshot showing the missing Application name
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?
Keywords: qawanted

Comment 3

10 years ago
(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 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?
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.
Created attachment 299145 [details]
Screenshot in Vista
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

10 years ago
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...
Flags: blocking-firefox3?
Keywords: qawanted
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[";1"].getService(Components.interfaces.nsIMIMEService).getFromTypeAndExtension("application/x-bittorrent", null).hasDefaultHandler
the result is false.

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


Components.classes[";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

10 years ago
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

10 years ago
Created attachment 299431 [details] [diff] [review]
wallpaper patch

What's happening at,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.
Flags: blocking-firefox3? → blocking-firefox3+
Priority: -- → P3
nice to fix, not a hard blocker
Assignee: nobody → jmathies
Priority: P3 → P4
Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.
Flags: wanted-firefox3+
Flags: blocking-firefox3-
Flags: blocking-firefox3+

Comment 13

10 years ago
Adjusting tp P3. I've confirmed this and would like to see it get it in.
Priority: P4 → P3

Comment 14

10 years ago
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

10 years ago
if anyone feels this is more general and not specific to the config of uTorrent, pls post a comment or reopen.
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.