This bug is to track another regression of bug 389969. Bringing in the original Comment 0 of that bug: repro: Open FF go to ttp://google.com (see Bug 389705) result: javascript Alertbox: Firefox doesn't know how to open this address, because the protocol isn't associated with any program. expected: the new "protocol handling dialog" == Regression Range of this new regression == works in 20070809_1507_firefox-3.0a8pre.en-US.win32.zip fails in 20070809_1524_firefox-3.0a8pre.en-US.win32.zip http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1186697220&maxdate=1186698239 == Regression Found with Webcal == Regression found by attempting to use the webcal: protocol on Windows XP: There is no default webcal handler on WinXP, so Firefox displays an alert "Firefox doesn't know how to open this address, because the protocol (webcal) isn't associated with any program". Tested on http://people.mozilla.org/~ctalbert/test-webcal-protocol.html

I think the right way to fix this is to figure out exactly what the semantics of nsIExternalProtocolService.externalProtocolHandlerExists should look like. Given that we pretty much always a dialog these days (except in the case of blacklisted protocols), one could imagine it always returning true, which would be a bit silly. At some level, there's too much front-end / back-end entrainment here, and the right way to solve this might be by having this backend code not really dealing with the persistence of the default app at all. In the shorter term, we probably need to go through the callers of externalProtocolHandlerExists in the tree and figure out what makes the most sense. The biggest question has to do with what the callers really care about: do they want to be asking "are there any known handlers for this protocol?" or "should I pop up a dialog?". Note that as of this writing, at least, neither Mac or Linux nsIHandlerInfo impls know about any possible handlers besides the default one. Windows will soon know about another set, thanks to the patch in bug 348808. Also worth keeping in mind is that non-browser apps (e.g. Thunderbird) are likely to behave differently. nsIExternalProtocolService::IsExposedProtocol may need to be kept in mind while thinking about this stuff too.

So, there are two different issues in this bug... This first is what should happen when Firefox encounters an unknown protocol. [Meaning, Firefox doesn't handle it internally, there are no web handlers, and the OS doesn't' know anything about it.] The first regression from comment #0 is an example of this ("ttp://google.com"). In this case, we should *not* prompt the user to find an application to use. Most folks are not going have any idea what to do if a page suddenly asks them what to do with mms://foo.bar/12345. It's even more confusing if the unknown protocol is simply a typo (as in this particular example). The second issue is when a web protocol handler is installed, like with the webcal testcase given, clicking a webcal: link results in an error claiming that we don't handle it. That should be fixed, since we obviously do handle it. [If you haven't installed the web protocol handler yet, though, then it's just another flavor of the first issue] Patch for the second issue upcoming. If the first issue needs more thought/discussion, that should probably be a different bug asking for UX feedback.

Comment on attachment 280091 [details] [diff] [review] patch, v1 This seems to me like the right fix for the second issue.

Comment on attachment 280091 [details] [diff] [review] patch, v1 The reason to take this for M8 is so that we get test data from our Webcal Test Handler on windows XP, which, without this patch, won't work. Tested on Mac and Windows; low risk.

Comment on attachment 280091 [details] [diff] [review] patch, v1 Yeah, this seems like something we need ASAP

Checking in uriloader/exthandler/nsExternalHelperAppService.cpp; /cvsroot/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,v <-- nsExternalHelperAppService.cpp new revision: 1.343; previous revision: 1.342 done Checking in uriloader/exthandler/nsIExternalProtocolService.idl; /cvsroot/mozilla/uriloader/exthandler/nsIExternalProtocolService.idl,v <-- nsIExternalProtocolService.idl new revision: 1.14; previous revision: 1.13 done

Cleaning out whiteboard comments.