Currently, if Firefox can parse URL bar input as a web address, it sends users to that URL. If it can't but the input looks like a search string, Firefox sends the string to search. There's a third category of input that Firefox doesn't recognize, which redirect to error pages such as "Server not found," "The address isn't valid," ""Unable to connect," and "The address wasn't understood." The help then given on this page advises users to try installing software, check for typos, etc. These redirects to error pages are missed opportunities. They are very unlikely to be helpful, as the advice on them rarely has enough context to be helpful (eg "you may need to install other software.") However, if we send these searches to the default search engine, we're dramatically increasing the chance that the user gets useful information back or ends up where they wanted to go. For instance, if Google is the set search provider, the input of "define:bacon" would give them the definition of bacon rather than "The address wasn't understood." The input "60/15" would give 4 rather than "Unable to connect." Of course, we'd still need to let users connect to local servers - maybe by detecting them if the URL input string matches one and sending the query to search if not.

The "define:bacon" thing we could in fact handle easily: we can just end up doing a search if the url scheme is not recognized. 60/15 is a weird edge case that would be addressed by the existing bugs on not accepting notation other than A.B.C.D for IPv4 addresses, at which point we wouldn't think that "60" is an IP address. It might be good to write down a list of possible failure modes here so we can consider them individually, because the right behavior really depends on the failure mode, I think.

We can also treat URL bar entries differently from content links -- most users are not going to be typing in obscure but technically-valid URL/IP formats. EG, if a user types "define:bacon" we should do a search, but clicking an <a href="define:bacon"> link should not.

(In reply to Boris Zbarsky (:bz) from comment #1) > It might be good to write down a list of possible failure modes here so we > can consider them individually, because the right behavior really depends on > the failure mode, I think. None of the entries I've tested have gone to useful failstates, but would if there was a match to, say, an IPv4 address. Frankly, I think it may be best to search whenever there isn't a match. As Dolske says in Comment 2, this should only relate to URL bar inputs, not content links.

> We can also treat URL bar entries differently from content links We already do, for what it's worth, for cases that don't look like a url. So yes, we definitely can.

Yowza. I've never traced through all this code before, and found myself very sad to find myself wading through docshell -- again :( -- which is where all this stuff happens. It's... intricate. I can't help but wonder if it would be worthwhile to ripout all the ALLOW_THIRD_PARTY_FIXUP-related code, and replace it with purely front-end logic. EG: var url = urlBarInput.value; if (!isLikelyURL(url)) url = treatAsKeywordOrSearch(url); loadURI(url);

It's pretty tempting, yes. Esp. if we give non-Firefox Gecko consumers an easy way to opt in.

UX team: How about displaying a link [Search "define:bacon" with Google (or whatsoever)] within the error page, instead of (or in addition to) [Try Again] button? Maybe the default engine should be "www.archive.org" when the error code were "Server Not Found".