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




12 years ago
8 years ago


(Reporter: elharo, Unassigned)



Firefox Tracking Flags

(Not tracked)




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

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
 instead of

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

    *   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
Component: Search → Embedding: Docshell
Product: Firefox → Core
QA Contact: search → docshell
Version: unspecified → 1.8 Branch

Comment 1

12 years ago
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
we have to allow protocols to be defined simply by <scheme>:<scheme-specific-part>

Marking as invalid
Last Resolved: 12 years ago
Resolution: --- → INVALID

Comment 2

12 years ago
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? 
Resolution: INVALID → ---
is keyword.enabled true or false in about:config?
ah. so, the code intentionally doesn't fix this up it seems, although there's no hint to why. I tracked it down to
note that hostnames without a dot are fixed up.

Comment 6

12 years ago
The current URI spec is RFC 3986. 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

12 years ago
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) 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.
I have no opinion on this bug either way and don't plan on doing anything with it.

Comment 9

12 years ago
I just tried searching for "" at Google and guess what I saw?

Did you mean:  

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.


12 years ago
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
still see this?
Whiteboard: closeme 2008-10-15

Comment 11

10 years ago
It's certainly present in the latest Firefox 2.0.0.whatever. I'll check Firefox 3 when I get to work.
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....
Whiteboard: closeme 2008-10-15
Version: 1.8 Branch → Trunk
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.)
Summary: Firefox does not use keyword search for strings that look like domain names but aren't → Firefox should use keyword search for strings that look like domain names but aren't (and not found by DNS)
Oh, the unco was just an oversight. Fixed.
Ever confirmed: true
duplicate of Bug 273155 ?

also i filed  Bug 550458 -  Firefox should use keyword search for strings enclosed in quotation marks
You need to log in before you can comment on or make changes to this bug.