Asa asked me to scope out the impact of turning off domain guessing
The general design goal of Phoenix is to use the search dialog for searching
(look for a list of sites that relate to search criteria). In URL bar, Internet
Keywords would be used to send all user-input to the best page Google's "I got
lucky" engine returns. This second behavior does involve search of Google's
databse, but is not search in a stricter sense.
From what I've been able to tell with testing and research, there are a couple
cases where Internet Keywords is not used when it should. That is bug 79655.
If you have that fixed, you will get everything you want, and the setting of
domain guessing will not matter.
If you do not fix that, domain guessing only occurs in situations where you type
something that has no spaces -and- a dot, in other words a two label domain
name. That will go to DNS, then to Domain Guessing, and never to IK. Domain
guessing will add "www." to the front of what you type, which will almost never
fix the problem, and certainly give you embarrasing error messages ("news.cnet"
-> "www.news.cnet"), per bug 66183.
Single hostnames go to DNS then IK.
Other strings that are not valid DNS will go to IK, except if there is a period,
where weirdly it decides to treat it as a DNS hostname and then something in URL
parser barfs on the spaces.
So, based on this, I think turning it off is a good idea, because it avoids bug
66183, but it does not give you the behavior you want, which can only be fixed
if you fix bug 79655.
OS -> All
I have also noticed similar problems where googling takes place when it should not:
When i use localhost (for webmin, it's https://localhost:10000/)
i get google's "lucky" result, which is an insidious spam promotion site.
The problem goes away if i have webmin running ahead of time.
One other time a site that worked in konq would google me to some
crazy place, but i can't reproduce it now. I reproduced it many times
earlier, and i could see google in the status bar briefly. It
happened when i would try to login at http://www.attwireless.com/ ,
but i don't think that really helps.
Eric: the problem you describe is related to Internet Keywords, which is a
Your analysis has long since passed its expiration date - now Eric's problem *is* domain guessing. It's also rather flawed, since it doesn't mention the impact on things like cebit.de that are stupid about requiring the www., and would be more appropriately located in bug 133371, anyway, as long as that bug exists.
You should still turn it off in firefox, unless you are certain that the recent changes in how IK works make sure that it is never called. If that is the case, then, why do you need it?
I'm reopening this because I don't understand the reasons why this was invalid.
What expiration date?
And Eric's explanation is clearly the result of the IK code, he says the returned URL comes from google's lucky service.
At the time I originally filed the bug, most people that looked at it understood my concerns.
Here's the full description:
This is the firefox version of bug 133371, which probably should be moved to MAS, now that we are product-based.
What is this bug actually about? "implications of turning it off" isn't something that can be fixed, so I suggest you resummarize to indicate the work that you're suggesting actually needs to be done. I doubt we're going to disable the feature, though.
Gavin: sorry about the confusion. This bug goes back to the days when Firefox was Phoenix, and it was considered a tentative project...
If you are not fully familiar with the feature, I urge you read the document provided above. I might be a bit dated, but I'm sure you will get general picture.
The domain guessing feature is not related to the "control-enter" URL bar features (although they use the same "www." and ".com" pref strings...), which I think is a good alternative implementation.
Also, Safari has a feature, which like our XUL-error pages...
There are lots of better ways than doing blind-autoguessing. And there are lots of problems with it.
I'm familiar with the feature, what I was confused about is what you were actually suggesting we do. I don't really see any valid arguments for why we would turn it off apart from the presence of bug 66183, and that seems minor compared to the feature's benefits.
Typos in hosts (e.g. "," instead of ".") leak to the search engine. Privacy.
(In reply to comment #9)
> I'm familiar with the feature, what I was confused about is what you were
> actually suggesting we do. I don't really see any valid arguments for why we
> would turn it off apart from the presence of bug 66183, and that seems minor
> compared to the feature's benefits.
Which benefits? Letting the keyword.URL provider do the work seems smarter. It could after all just add "www." and ".com" if that made sense in a particular case.
(In reply to comment #10)
> Typos in hosts (e.g. "," instead of ".") leak to the search engine. Privacy.
Yet an error page about www.foo,com.com isn't helpful.
(In reply to comment #11)
> (In reply to comment #10)
> > Typos in hosts (e.g. "," instead of ".") leak to the search engine. Privacy.
> Yet an error page about www.foo,com.com isn't helpful.
And http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=www.foo,com yields the expected result.
> Yet an error page about www.foo,com.com isn't helpful.
You'd get an error page about "foo,com", if the URLbar worked correctly as *URLbar*.
And that would be trivial to notice and correct.
Sure, it could be corrected, but it's probably not trivial since it has been known for ages and is documented on <http://www.mozilla.org/docs/end-user/domain-guessing.html>. Anyway, the perspective of fixing that doesn't explain why you'd expect www.foo,com.com to be checked in the first place.
Is this behavior ever helpful? These days, when you don't click or copy/paste a URL, you rely on search. The address bar is doing a search when the input does not look like a URL.
In 99% of the cases, this feature breaks valid URLs.