Open Bug 133371 Opened 22 years ago Updated 2 years ago

Domain Guessing: Disable by default

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

People

(Reporter: jonasj, Unassigned)

References

Details

Attachments

(1 file)

patch
435 bytes, patch
asa
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
Turn off domain guessing by default. See bug 115539.
Attached patch patch — — Splinter Review 

    
    

    
  
My DSL connection at home died, trapping a long list of reasons why this should
be off by default. I'll add them later. Here's some reasons:

1- Mozilla users should be experienced users. They can turn this feature on if
they want.

2- this feature should be re-written to be user-configurable and extensible. For
example, .org and .net support should be given. Why does typing "mozilla" not go
to "mozilla.org" or "www.mozilla.org"? (I've looked for this bug, but cannot
find it).

3- Mozilla testing needs to focus on DNS, and turning off these higher level
features helps get to the basic behavior (this is the same logic that applied to
turning off Internet Keywords by default).

    
    

    
  
> this feature should be re-written to be user-configurable and extensible. For
> example, .org and .net support should be given. Why does typing "mozilla" not go
> to "mozilla.org" or "www.mozilla.org"? (I've looked for this bug, but cannot
> find it).

Isn't that bug 37867?

    
    

    
  
*sigh* again:
Don't guess hostnames by default. Evil thing to do, restricts to a single TLD
and has potential security problems (local hostnames and their URLs exposed to
net, if local server or DNS down).

> 1- Mozilla users should be experienced users. They can turn this feature on if
> they want.

<insert usual Mozilla has no end-users statement>
A better consideration for Mozilla defaults is, which default the distributions
other than Netscape (and Beonex) should use, because in many cases, they just
take Mozilla and repackage it, not knowing all the little details we are
discussion about. IMO, it's our job to set reasonable defaults for them, and
reasonable for mozilla.org includes being net-friendly. A dot-com bias is IMO
not net-friendly. And potential security problems are even less user-friendly
(the users of the other distributions). If Netscape wants to do the wrong thing,
we can't stop them, but we can help the other distros and distro users.

I think that this is actually a dup of bug 37867, oir am I missing something.
And in that bug, the (very controversial) outcome was, I think, wontfix, i.e.
the default here should consequently be "off".



    
    

    
  
> And in that bug, the (very controversial) outcome was, I think, wontfix

Forget that. There was no "offical" outcome (what would that be?), and I
shouldn't be speaking for others. Read all the details yourself :).

    
    

    
  
> I think that this is actually a dup of bug 37867

It's not. That bug is about expanding domain guessing behavior. This bug is
about turning it off. This bug is a dup of bug 115539.

    
    

    
  
If Mozilla users are as experienced as you say, why can't they turn the feature
OFF if they find it so annoying? This feature is primarily for novices who are
notoriously shy of preference dialogs. The default should be made with due
consideration of the kind of errors that novices make. Novices don't type well
formed URLs, or valid addresses so fixup has to occur or Mozilla will constantly
be throwing errors in their face.

If a novice types "foo" into the location bar, Mozilla should do it's best to
figure out what they mean. Link click fixup will be fixed by bug 34943 so we're
only talking about the location bar.

And the fix for bug 115539 makes it convenient to disable the feature for people
unafraid of pref dialogs.


    
    

    
  
> If Mozilla users are as experienced as you say, why can't they turn the feature
> OFF if they find it so annoying? This feature is primarily for novices

If Mozilla users are experienced, then a feature which is primarily for novices
is, by definition, not for mozilla users. Why can't you just turn it here but
leave it on in Netscape 6? (Note that I am personally against *any* browser
having this on by default, as I consider it Bad For The Net(tm).)

> If a novice types "foo" into the location bar, Mozilla should do it's best to
> figure out what they mean.

Try typing "whitehouse" in the location bar with domain guessing turned on and
see where that takes you.


    
    

    
  
ben:

If someone is going to repackage mozilla, I think it would be in their best
interests to understand *what* they package and *how* it works. 

adam:

Here's some more reasons why it should be off:

In my mind, this feature has numerous problems:

Bug 40082: domain guessing follows DNS search query list.
Bug 68407: CUAP recommends this be off.
Bug 66183: The error messages are incorrect.

I understand you want to make this browser easy to use, but the mozilla browser
is for testing, not for consumer use. This makes life hard sometimes for
netscape employees, who typically "eat their own dogfood" by using only
mozilla-based products. 

But there are a lot of benefits to having people get a very basic, literal
feature, and having them find out how things work, turn on prefs, think about
how features SHOULD be implemented. 

Also, mozilla builds exist for the purposes of testing, which does include
experimentation. For example, at times QuickLaunch has been installed on or off
to reflect various attempts to gather feedback.



    
    

    
  
Some points:

1. Mozilla isn't for testing purposes only. It already ships with various
   Linux distributions as the default browser. With version 1.0 it is more 
   likely than ever to get into the hands of end-users.  Lots of
   novices & non-programmers are going to use it.

2. Turn off the feature if you don't want bug 40082 to happen. I'm confused
   why this is even considered a bug in its own right though. If you have
   keyword lookup or www. & .com appending enabled then of course
   you'll have multiple DNS lookups.

3. Bug 68406 asks for a way for the user to override the guessing behaviour. 
   You already have such a way at least with regard to this feature.
   And the patch on bug 34943 makes it a checkbox in the prefs dialog.

4. Bug 66183 is minor issue with the dialog error message for unresolved hosts.
   I don't believe the issue is insurmountable though it won't be fixed for 1.0.



    
    

    
  
> Mozilla isn't for testing purposes only.

<q cite="http://mozilla.org/releases/">
We make binary versions of of Mozilla available for testing purposes only.
</q>
:)

> It already ships with various
> Linux distributions as the default browser.

If someone makes a Linux distribution targeted at home users which includes
Mozilla, they should configure it for home users.

> With version 1.0 it is more 
> likely than ever to get into the hands of end-users.  Lots of
> novices & non-programmers are going to use it.

Lots of novices & non-programmers who'll end up at whitehouse.com instead of
whitehouse.gov. :)


    
  
Blocks: 68407

    
    

    
  
> The default should be made with due
> consideration of the kind of errors that novices make.

Right. Namely, typing in a word into the urlbar to search for it. "Travel" ->
<http://www.travel.com> is no good, but harmful to the web.

> Lots of novices & non-programmers are going to use it.

Their fault. Your argumentation is one reason why I'm always saying that Mozilla
is not for end-users. If they want to use it, fine, but let's not adjust Mozilla
or mozilla.org for that.
Either do it right (make a really polished end-user product) or not at all
(targetted at developers and testers only). Everything in the middle serves noone.



    
    

    
  
adam: There are various solutions to these problems, but my point is, these are
all real problems, which make a case for having this thing off by default. 

As for bug 40082 it is valid, if you turned "travel" into "www.travel.com",
wouldn't you want DNS to look for that explicitly? That is not what happens.
Turbogeek's DNS traces show this quite clearly.



    
    

    
  
If fixup is enabled and travel is turned into www.travel.com then only two URI
load operations max are initiated. I have no idea what these .search1 & .search2
things are in the bug (some DNS terminology?), but the URI fixup certainly isn't
responsible.

    
    

    
  
(dunno why this was in security:general...)

adam: lets talk about that in bug 40082. (read bug 124565 as well...)
Component: Security: General → Embedding: Docshell

    
    

    
  
This bug is a usability/security issue, nothing to do with docshell since it
supports either behaviour. It should belong to the appropriate component.

    
    

    
  
Sending back to Security and CC'ing Usability. Any comments, mpt?
Component: Embedding: Docshell → Security: General

    
    

    
  
(just not understanding how this is a securty concern)

    
    

    
  
mpt: Any usability comments?


Keywords: patch, 
          
            review

    
    

    
  
This bug is just sitting here. Will *somebody* please make a call regarding
whether this should be fixed or not?

    
    

    
  
Is the pref side working yet?
Depends on: 115539

    
    

    
  
Yes the pref works, but there is no UI for it. The smart browsing UI needs some
work to fit the new pref in.

    
    

    
  
This bug concerns URL Bar behavior, it belongs in that component, reassigning.

BTW, the idea that companies like AOL, IBM and RedHat are spending hundreds of
millions of dollars on mozilla development for the sake of testing by a few
thousand contributors is utter nonsense.  Mozilla is built for, and intended for
end users, it is just not hosted as such on mozilla.org, or distributed by them
to end users because they do not support it as a product, which end users
expect. It would be absurd to pretend that 400,000 people who download the
mozilla browser are all 'testers', since only a tiny fraction of them are set up
to file bugs. Redhat redistributes mozilla intact, and Netscape includes almost
all of it, between them it goes to millions of non-technical users. They might
not do so if it were geared towards contributors at the expense of their target
users. Get used to it, we are building this for the masses, so we have to design
it for them to use by default, not us.
Assignee: mstoltz → hewitt
Component: Security: General → URL Bar
QA Contact: bsharma → claudius

    
    

    
  
peter: are you saying this should be on by default? Not sure from your comments.

The case for implementing 115539 and setting it off by default is scattered
among various bugs but very solid.

Additionally, we received very little negative feedback when we default==off
another URL feature, internet keywords. 



    
    

    
  
Pardon me, my rant was in response to comment #12.  I'm saying that we don't
make such decisions based on a few contributors in a bug report; we have module
owners and a large group of target end users to consider.  We can't just disable
shipping features because a few people don't like them.

    
    

    
  
(doesn't think this will be turned off just because benb wants it off...)

Who is the module owner? Adam? (looked at module owner page, but not sure which
module this feature is in).

I'd be glad to sit down with a module owner and discuss various aspects of this
problem.

    
    

    
  
trudelle, just strike my comment 12. I don't know what I was thinking.

    
    

    
  
Who is the module owner for anything anymore?  The official list is years out of
date, and no longer useful.  IMO, Joe Hewitt is the person with top technical
responsibility for any type of 'auto-complete' behavior in the location bar,
including this.  We don't have a single clear design owner, but PixelJockeys has
been allowed to make UI decisions if the usual suspects don't agree.

    
    

    
  
I'll talk to joe about this.

    
    

    
  
A recent newsgroup thread shows that domain guessing causes an attempt to open
Address Book from the Window menu to result in the browser attempting to load
www.find.com!

http://groups.google.com/groups?th=ef73a90d44f0216e&seekm=af9pnq%24cjtim%241%40ID-106624.news.dfncis.de#link4

    
    

    
  
Let's get a new bug on that. I also saw that my history sidebar would go to find
for every non-URL item (day or domain), but I could ot reproduce it on other
systems.


    
    

    
  
I think searching on enter would be a better default behavior.  This bug has
plenty of arguments against automatically adding www. and .com, so here are some
arguments for searching:

- 6 people have filed "typing something containing a space into the address bar
should search": 58867,114892,123968,131648,138163,139609.  (Half are duped to
bug 79655, which seems wrong, and half are duped to bug 58867, which is marked
as WFM because so many users have Internet Keywords enabled.)

- It would be strange if typing something with a space searched but typing
something without a space went to www.something.com.

- In bug 53171 comment 29, a user thought the presence of "Search Google for
'foo'" directly under the address bar meant that hitting Enter would search.

- 21 dups of bug 135363, "location bar search fails after accidentally hitting
enter (which tries to use search terms as url)".  A regression with
steps-to-reproduce this long should be obscure.  The fact that it isn't obscure
suggests that there's something wrong with the UI.

- 11 dups of bug 53171, "Pressing enter in location/search field should search
using selected search engine instead of netscape search".

- Internet Explorer 6 for Windows does it.


    
    

    
  
I think that those types of features should be covered in the "IK==ON default
behavior" debate. The case for fixing Internet Keywords so it reflects most
users desire to search first is getting stronger, but does not belong here.

There should be a simple, go to resolver, go directly to resolver (do not get
Domain Guessed, do not go to search via IK, do not collect $200).

I think if you turn domain guessing -AND- IK off, then this is what you should get.



    
    

    
  
Oh <em>observe</em> how our <em>merry</em> users enjoy this <em>wonderful</em>
feature:

<blockquote>
Newsgroups: netscape.public.mozilla.general
Subject: Mozilla makes from http://mamaloe:8080 => http://www.mamaloe.com AARGHH
Date: 19 Sep 2002 01:24:15 -0700

I've installed Mozilla 1.1 today, and I want to browse to a NT server
with IIS with the name 'mamaloe' but when I enter http://mamaloe:8080/
in the browser, Mozilla enters http://www.mamaloe.com/.

And this is NOT what I want.
Please help

Regards,
[name]
</blockquote>

    
    

    
  
Jonas, well, domain guessing only happens if the host could not be found.

if it happens anyway, that's a bug in the implementation, it does not show that
the feature is bad.

    
    

    
  
Joe: 

I'd like to check in this patch, which would turn domain guessing off by
default, and leave it that way for some indefinite period of time. I think the
negative impact would be minimal because we could always flip the default back
if this turned out to be a big mistake. (We used the same approach with QuickLaunch)

I think this will produce some limited ammount of complaining, but I think there
would be some concrete benefits:

1- People who miss it would either learn to modify their prefs.js (which they
should be able to do as mozilla testers).

2- Others who did not want to do this would basically make a case for bug 115539.

3- Discussion of how this feature should work would let us mentally start over.
There are too many bugs with the current implementation, this feature is really
poorly implemented. This feature has problems in just about every area we care
about (design quality, security, performance, privacy, viewing pornography,
incompatability with established interent standards).

4- We might simply discover that life without domain guessing is not so bad.

5- We might find that domain guessing was hiding other bugs with DNS or URL bar.
Turning off Internet Keywords helped us find several problems with Domain
Guessing and URL fixup.


    
    

    
  
Please don't rush into this. This product is not being built for the Mozilla
testers.  Most people affected would have no idea how to re-enable it, yet it is
the case that testers who wish to disable it are perfectly capable of changing
their prefs.js.  cc Samir, Patrice

    
    

    
  
Peter: this change is completely easily reversible.

I think I have given many good reasons why we should do this on an interim
basis, if not permanently. The bugs I reference are mostly untargeted/futured
and this feature's bugs also need to be QA re-assigned because the tester field
is stale.

If there is nothing going on with this feature, I don't see why we cannot do
something for DNS and Network testing, which is an area where I think people are
working hard, finding and fixing problems. We already had a good experience with
turning off Internet Keywords by default.

If you want to make this easy to turn on, fix bug 115539. No bugs have been
filed saying IK is too hard to turn on, so I think the track record is good.

(It also doesn't work well via proxies, either).

    
    

    
  
once we get done w/ 1.3b, I'll be submitting a patch to turn this off, by default.

This will be a interim test, we'll see what kind of user feedback we get.


    
    

    
  
As I understand it, Darin is going to put the DNS re-write into 1.6a, so after
that is baked, I'm going to turn off domain guessing for 1.6b.

This will be a trial run. If enough people think the change makes sense, I will
leave the change into 1.6f. If enough people complain, then we'll gather some
feedback, and consider making the permanent change dependent on adding other UI
or shortcuts to keep the user experience pleasant.

I already run several of my profiles w/o it, and despite my occassional need to
feel lazy and type "google" in the URL bar, the benefit is that URLs intranet
hostnames don't get broadcast over the publinc network anymore.
Assignee: hewitt → benc
QA Contact: claudius → benc
Target Milestone: --- → mozilla1.6beta

    
  
Status: NEW → ASSIGNED
Component: Location Bar → Embedding: Docshell
Summary: Disable domain guessing by default → Domain Guessing: Disable by default
Target Milestone: mozilla1.6beta → mozilla1.7alpha

    
    

    
  
Comment on attachment 76074 [details] [diff] [review]
patch

Firebird has it's own auto-completion feature via a keyboard shortcut now.

        Attachment #76074 -
        Flags: review?(asa)

    
    

    
  
Comment on attachment 76074 [details] [diff] [review]
patch

sr=bzbarsky if asa is ok with this.

        Attachment #76074 -
        Flags: superreview+

    
  

        Attachment #76074 -
        Flags: superreview+ → superreview?(bzbarsky)

        Attachment #76074 -
        Flags: superreview?(bzbarsky) → superreview+

    
  
Blocks: 233392

    
  
Blocks: 185922
Flags: blocking1.7a?

    
    

    
  
not going to hold the alpha release for this, though I think we should
definitely consider setting the pref to off by default at least for non-final
builds. 
Flags: blocking1.7a? → blocking1.7a-

    
    

    
  
making sure ben goodger knows the impact of this bug since it will affect all
the end users in firefox and camino.

    
    

    
  
We already scoped out the implications for FireFox in bu 185922. Basically, it
won't matter b/c Internet Keywords traps the majority of cases DG would take effect.

    
    

    
  
Comment on attachment 76074 [details] [diff] [review]
patch

We should give this a shot in 1.8 and see what we learn.

        Attachment #76074 -
        Flags: review?(asa) → review+

    
    

    
  
If anyone can checkin, that would be great. I don't have cvs code privs.
Target Milestone: mozilla1.7alpha → mozilla1.8alpha

    
    

    
  
I've been preoccupied with other things for the last year, but I think I have time to make this change and monitor the bugs.

I'd like to do trunk-first, (aka Mozilla-only). Am I hopelessly out of date, let me know.

    
    

    
  
I need to jump on the bandwagon here as well. I just tried to visit wikipedia (en.wikipedia.org) and -- even though en.wikipedia.org resolves for me -- I got redirected to "www.en.wikipedia.org.com" -- which is an annoying redirect to a domain squatter called yeah.com (who owns ".org.com"). These points all seem to have been brought up before, but here's a few problems with this so-called "feature".

* It's broken -- it ocassionally breaks connectivity to valid domains.
My resolver logs show receiving a query for "www.en.wikipedia.org.com IN A" immediately after returning a valid A record for "en.wikipedia.org".

* It makes false assumptions about the structure of hostnames:
-- All web server hostnames start with www (common, but far from universal)
-- Bigger sin: All web servers are in the .com TLD (other than statistical probability, there is no rationale whatsoever for this assumption)

* Related to the above -- this introduces a .com bias into Firefox. Not valid for US users, and certainly even less valid for users in any other country, where domains based on the country's ccTLD are likely to be more prevalent.

* It caters to cybersquatters. Firefox is directly driving revenue into the hands of exploitative cybersquatters like yeah.com. Today, popups -- tomorrow, malware?

* It's poorly documented. I knew IE had a feature like this (a good reason NOT to use IE, methinks). I did not know Firefox did until I spent time debugging my ISP's DNS servers and realized the rogue queries could only have originated from Firefox itself. If I hadn't happened to work for my ISP (and thus be able to access DNS resolver logs) finding it would've been even harder.

* It's not helpful. Someone needing a "shortcut" to get to a site can either bookmark it, or simply type "sitename" into the search box rather than the address bar. This is why Firefox *has* a search box, and any search engine is more likely to return an accurate result than Firefox's retarded assumption that www.<sitename>.com will magically yield the site the user wanted, rather than annoying cybersquatter page.

* The address bar is named thus because it contains an address -- URI, URL, whatever you want to call it. Overloading it with "enhancements" like this reduces usability, it doesn't enhance it.

I fear the powers that be will not be willing to cut this so-called "feature" altogether, but for the sake of all that is good in the universe, at least have the decency to disable it by default.

    
    

    
  
Comment 49 doesn't seem to be about this bug.  This bug is about behavior on DNS error...

    
    

    
  
Boris -- the bug seems to trigger if Firefox erroneously believes it can't resolve a certain hostname (en.wikipedia.org). The resolver logs show the two queries (en.wikipedia.org, then www.en.wikipedia.org.com ) in immediate succession.

However, this bug is about changing whether domain guessing is on by default, and my posting was in support of disabling it by default. Description of the erroneous behavior that led to my position on this issue is merely incidental to my comments on the bug.

If you prefer, I can submit a new bug on my exact issue. However, it seems to me there are a lot of bugs open on related-but-not-quite-the-same type of issues, which makes it harder to focus on fixes that would be common to all of these.

    
    

    
  
Why is a bug about the default setting of a product (at least that's what the summary says) living in Core?

    
  
Assignee: benc → nobody
Component: Document Navigation → Location Bar and Autocomplete
Flags: blocking1.7a-
Product: Core → Firefox
QA Contact: benc → location.bar
Target Milestone: mozilla1.8alpha1 → ---
Status: ASSIGNED → NEW
Whiteboard: wontfix?

    
    

    
  
(In reply to comment #53)
> Why is a bug about the default setting of a product (at least that's what the
> summary says) living in Core?

The Firefox bug is bug 185922.

Fixing this bug would affect products beyond Firefox.

Why hasn't the patch landed?
Component: Location Bar → Document Navigation
Product: Firefox → Core
QA Contact: location.bar → docshell
Whiteboard: wontfix?

    
  
Severity: normal → S3

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: