User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:126.96.36.199) Gecko/20060909 Firefox/188.8.131.52 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:184.108.40.206) Gecko/20060909 Firefox/220.127.116.11 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
Component: Search → Embedding: Docshell
Product: Firefox → Core
QA Contact: search → docshell
Version: unspecified → 1.8 Branch
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
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?
Status: RESOLVED → UNCONFIRMED
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 http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDocShell.cpp&rev=1.224&cvsroot=/cvsroot#3188
note that hostnames without a dot are fixed up.
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.
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.
I have no opinion on this bug either way and don't plan on doing anything with it.
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.
still see this?
Whiteboard: closeme 2008-10-15
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.
Status: UNCONFIRMED → NEW
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.