425971 - nsIContentDispatchChooser isn't consulted when there is no OS-level handler registered

Status: NEW

(Firefox :: File Handling, defect)

Description

[Stuart Morgan]

In bug 389687, Camino added an implementation of nsIContentDispatchChooser for protocol handling. I would expect that clicking a link like foo://bar would cause a call to Ask, with aHandler->GetHasDefaultHandler returning false. Instead, it's never called at all, and it just shows the core "foo is not a registered protocol".

Presumably clients might want to handle that case intelligently (e.g., allowing the choice of a website handler), but they don't appear to have an opportunity to do so.

Comment 1

[Shawn Wilsher :sdwilsh]

This might actually be an easy fix, but I probably can't look at it until tuesday (probably too late by then).

Comment 2

[Shawn Wilsher :sdwilsh]

This is the reason why:
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp&rev=1.368#893

I can't quite recall the reasoning for this off the top of my head though.

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

Part of what's going on here has to do with the fact that nsOSHelperAppService::GetProtocolInfoFromOS has this odd architecture where it's supposed to create and return an nsIHandlerInfo-implementing object regardless of whether the OS itself knows about any handlers.  One of the cleanup bugs on file talks about how we should make an nsOSHandlerInfo be its own object that's an attribute on the nsIHandlerInfo-implementing object, which seems significantly more straightforward.

Comment 4

[Stuart Morgan]

From bug 389687 comment 25:
> I disagree.  The way it's supposed to work, I think, is that Ask shouldn't be
> called in the case where there are neither OS-level handlers nor web-handlers
> registered.

I don't understand why that would be desirable. If the assumption is that the OS is the ultimate authority on handlers, then Ask is pointless, because we should just do what the OS says. If that's not the assumption, then it shouldn't be treated as such, so the fact that the OS doesn't know what do shouldn't prevent us from giving the user options if we think we can do better than the OS.

Put another way: under the current model, if a user has already set up a feed handler on their system, then Camino can provide them whatever UI we want for configuring feed handlers the first time a feed: link is clicked. If the user has not set up a feed handler, then we have no opportunity to do anything. That means that our code can only run when it's least useful, and not when we actually need it.