357320 - Firefox should use keyword search for strings that look like domain names but aren't (and not found by DNS)

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Elliotte Rusty Harold]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

I don't appear to have an option to reopen bug 79655, but it's not fully fixed
yet. In the latest Firefox beta a search for "Java 1.5" works. However a search
for "javax.usb" fails with a "Server not found". Similarly a search for
"java:test is a sample" fails with "Firefox doesn't know how to open this
address, because the protocol (java) isn't associated with any program." On the
other hand "sample java:test is a sample" succeeds. 

I think that is it isn't obviously a bad URL, then Firefox should default to a
search for the term (at least if keyword seacrh is enabled)

Reproducible: Always

Steps to Reproduce:
1. Enable keyword search
2. Type javax.usb in the location bar
3. Hit return

Actual Results:  
Server not found

      

      
      
      

      
        
        

          

Firefox can't find the server at www.javax.usb.

        


        
        


    *   Check the address for typing errors such as
          ww.example.com instead of
          www.example.com

    *   If you are unable to load any pages, check your computer's network
          connection.

    *   If your computer or network is protected by a firewall or proxy, make sure
          that Firefox is permitted to access the Web.

Expected Results:  
Google search results for javax.usb

Related to 79655

Comment 1

[Anders Conbere]

this is expected behaviour and necessary to preserve compatibility with the web.  For instance on my intranet there is not reason for me to use ICANN certified top level domains.  I could hypotheticaly create a new top level domain at my DNS Server called "usb" and and an address named "java.usb" would be a perfectly valid and well formed domain name.

As for the second case in order to be compliant with the url specification
http://www.faqs.org/rfcs/rfc1738.html
we have to allow protocols to be defined simply by <scheme>:<scheme-specific-part>

Marking as invalid

Comment 2

[Elliotte Rusty Harold]

This is not invalid or in conflict with the web. I am not suggesting that Firefox try the keyword search first; only that it fall back to it if it DNS resolution fails. Thus your LAN with a weird top level domain would still work. In fact, a much more likely scenario is that someone is using default domain names so that names like gandalf, frodo, bigmac etc. are legal DNS names locally, but we allow those as keywords.

RFC 1738 is years out of date. I'm not sure anything relevant has changed in later RFCs though. Nonetheless, I see no obligation on Firefox to support all possible schemes. It seems perfectly reasonable that if Firefox doesn't recognize a scheme, it can do a Google search for the data.

If this really bothers anyone, it could be made an additional configuration option. However, implementing this would seem to solve vastly more problems than it causes. Does it really bother anyone that *when Firefox can't resolve a URL* that it do a Google search on that string? 

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

is keyword.enabled true or false in about:config?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

ah. so, the code intentionally doesn't fix this up it seems, although there's no hint to why. I tracked it down to http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp&rev=1.224&cvsroot=/cvsroot#3188

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

note that hostnames without a dot are fixed up.

Comment 6

[Elliotte Rusty Harold]

The current URI spec is RFC 3986. http://www.ietf.org/rfc/rfc3986.txt If I'm reading the BNF grammar in the spec write, then a string that contains a space character is *never* a valid URI. That is, the scheme specific part cannot contain a space.  Thus a string such as "java:test is a sample" can be unambiguously determined to not be a URI,, and therefore should be passed to keyword search. 

Comment 7

[Anders Conbere]

I suppose that depends on what order we process url's in. As we url encode spaces at some point.  makeing "java:test is a sample" => "java:test%20is%20a%20sample".  So clearly we think that people mistakenly create urls with spaces in them often enough to modify those urlbar entries to be url complient.

As for checking if the domain is is valid and doing a keyword search on that leads us to a couple of problems.  The main issue I think is that we would have two choices... regex much more carefully for what might be a valid url, or not give developers or users the error codes they need to function on the web.

For instance.  (well pretending that this would be an invalid domain name and google hadn't bought all the domain names that look like google) www.gogole.com might be an invalid domain name, but certainly the user didn't expect it to do a keyword search on that. The question becomes: Is it more usefull useful to a user to have an error page explaining that the domain name the entered does not exist or to do a keyword search.

Really what it comes down to is whether we take a narrow view of keywords or a narrow view of domains/urls.  I personally think that keywords aren't really that important in comparrison to a flexible protocol/url schema.  But I'll leave this bug up to you guys... my suggestion is that this bug is itself invalid.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

I have no opinion on this bug either way and don't plan on doing anything with it.

Comment 9

[Elliotte Rusty Harold]

I just tried searching for "www.gogole.com" at Google and guess what I saw?

Did you mean: www.google.com  

I think that's quite helpful to an end user, far more so than a simple there's no such domain error. At least now they can click through to the site they really did want.

I also experimented with a misspelling of a much less popular site URL and Google found that too. 

Bottom line seems to be that in both cases: typo in domain name and something that looks like a domain name but isn't, the most helpful thing we can do is redirect the user to Google. It's a win-win.

Comment 10

[Wayne Mery (:wsmwk)]

still see this?

Comment 11

[Elliotte Rusty Harold]

It's certainly present in the latest Firefox 2.0.0.whatever. I'll check Firefox 3 when I get to work.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Wayne, none of this code has changed since biesi's comments, as you could verify by trivial code inspection.

Elliotte, in practice we've had looser keyword stuff before and it turned out to break people's expectations badly, hence the restrictions....

Comment 13

[Wayne Mery (:wsmwk)]

my bad, not a code jockey but I should have read the full bug. I just thought it odd the bug was unconfirmed over two years, but now I understand.  

So it's unconfirmed as there's not a solution agreeable to all. (Seems to be this should be ENH, but whatever you all feel best is best.)

Comment 14

[Boris Zbarsky [:bzbarsky]]

Oh, the unco was just an oversight. Fixed.

Comment 15

[eyal gruss]

duplicate of Bug 273155 ?

also i filed  Bug 550458 -  Firefox should use keyword search for strings enclosed in quotation marks