Last Comment Bug 185922 - Domain Guessing: turn off by default (Firefox-only)
: Domain Guessing: turn off by default (Firefox-only)
Status: NEW
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: unspecified
: x86 All
: -- normal with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
Depends on: 133371 503171
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-17 19:28 PST by benc
Modified: 2015-01-21 01:39 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description benc 2002-12-17 19:28:45 PST
Asa asked me to scope out the impact of turning off domain guessing
(browser.fixup.alternate.enabled==false).

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.
Comment 1 Sébastien Delahaye 2002-12-20 09:36:33 PST
OS -> All
Comment 2 eric 2003-10-21 23:01:56 PDT
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.
Comment 3 benc 2003-12-28 23:09:25 PST
Eric: the problem you describe is related to Internet Keywords, which is a
different feature.
Comment 4 Phil Ringnalda (:philor) 2007-03-18 21:30:21 PDT
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.
Comment 5 benc 2007-07-19 22:12:31 PDT
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?
Comment 6 benc 2008-07-24 12:25:36 PDT
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:

http://www.mozilla.org/docs/end-user/domain-guessing.html

This is the firefox version of bug 133371, which probably should be moved to MAS, now that we are product-based.
Comment 7 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-07-24 12:49:44 PDT
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.
Comment 8 benc 2008-07-28 13:39:00 PDT
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.
Comment 9 :Gavin Sharp [email: gavin@gavinsharp.com] 2008-07-29 16:10:56 PDT
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.
Comment 10 Ben Bucksch (:BenB) 2010-05-05 08:17:45 PDT
Typos in hosts (e.g. "," instead of ".") leak to the search engine. Privacy.
Comment 11 Dão Gottwald [:dao] 2010-05-05 08:21:13 PDT
(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.
Comment 12 Dão Gottwald [:dao] 2010-05-05 08:23:16 PDT
(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.
Comment 13 Ben Bucksch (:BenB) 2010-05-05 09:21:21 PDT
> 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.
Comment 14 Dão Gottwald [:dao] 2010-05-05 11:49:24 PDT
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.
Comment 15 Noam Tamim 2015-01-21 01:39:31 PST
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.

Note You need to log in before you can comment on or make changes to this bug.