Last Comment Bug 115539 - Domain Guessing: Add pref UI to disable/enable (adding "www." and ".com" to domain names)
: Domain Guessing: Add pref UI to disable/enable (adding "www." and ".com" to d...
Status: VERIFIED FIXED
:
Product: Core
Classification: Components
Component: Document Navigation (show other bugs)
: Trunk
: All All
: -- normal with 3 votes (vote)
: ---
Assigned To: Christopher Aillon (sabbatical, not receiving bugmail)
: benc
: Andrew Overholt [:overholt]
Mentors:
: 125871 158162 170287 (view as bug list)
Depends on:
Blocks: 66183 133371 34943 63736 68407
  Show dependency treegraph
 
Reported: 2001-12-16 15:34 PST by Jonas Jørgensen
Modified: 2011-08-05 21:35 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
patch to turn this off by default (797 bytes, patch)
2002-03-24 10:43 PST, Jonas Jørgensen
no flags Details | Diff | Splinter Review
UI for the pref (2.64 KB, patch)
2002-03-25 10:19 PST, Adam Lock
no flags Details | Diff | Splinter Review
disable domain guessing (435 bytes, patch)
2002-03-25 13:10 PST, Jonas Jørgensen
no flags Details | Diff | Splinter Review
Picture of the pref with patch applied (86.88 KB, patch)
2002-03-28 08:49 PST, Adam Lock
no flags Details | Diff | Splinter Review
Picture again (86.88 KB, image/jpeg)
2002-03-28 08:54 PST, Adam Lock
no flags Details
More compact UI for pref (2.94 KB, patch)
2002-05-24 11:50 PDT, Adam Lock
no flags Details | Diff | Splinter Review
Add the pref per comment #89 (2.19 KB, patch)
2003-01-21 22:13 PST, Christopher Aillon (sabbatical, not receiving bugmail)
timeless: review+
jag-mozilla: superreview+
Details | Diff | Splinter Review

Description Jonas Jørgensen 2001-12-16 15:34:16 PST
If I type "example.net" in the location bar and it doesn't work, Mozilla will
automatically try "www.example.net" instead. If I just type "example", Mozilla
will try "www.example.com".

I find this very annoying. If a machine in my local network called "whatever" is
down, why would I want Mozilla to try www.whatever.com? It's a waste of time and
bandwith, and almost all important sites work without "www." anyway.
Comment 1 Jo Hermans 2001-12-24 07:11:48 PST
??? Never seen this behaviour in Mozilla. www.* and *.com are *never* added.
Reporter : what build are you running, on what OS ?
Comment 2 Jonas Jørgensen 2001-12-25 09:06:12 PST
Huh? Mozilla has done this at least since M15 - see also bug 34943.
Comment 3 Jo Hermans 2001-12-26 15:04:22 PST
I'm using build 200112106 on Mac OS 9.2.2, and I have *never* seen this
behaviour (tried all examples in bug 34943 to be sure). Otherwise I would have
logged this as a bug / security risk myself. My Internet Keywords is switched
off, and location autocomplete (all 3 options) is on.

In my DNS-settings. I haven't defined any search path either (starting domain
name, ending domain name), which would have explained this behaviour. Are you
sure it isn't done by the OS ?
Comment 4 Jonas Jørgensen 2001-12-31 05:06:40 PST
If this is done by the OS, and Mozilla doesn't add www. and .com, then how do
you explain bug 34943?
Comment 5 Jonas Jørgensen 2001-12-31 05:11:34 PST
(I'm using Win2k.)
Comment 6 Ben Bucksch (:BenB) 2001-12-31 06:07:09 PST
johan.rh.hermans@alcatel.be, do you use proxies? IIRC, the code differs in this
case. I use proxies and have *luckily* not seen this bug.

IMO, this bug should be fixed.

Compare bug 37867.
Comment 7 Morten Nilsen 2001-12-31 16:25:44 PST

*** This bug has been marked as a duplicate of 34943 ***
Comment 8 Ben Bucksch (:BenB) 2001-12-31 22:21:52 PST
Nope, separate issue. This one os about the location bar.
Comment 9 benc 2002-01-01 23:57:00 PST
type "packetgram" into the location field and hit return...

Comment 10 Doug Turner (:dougt) 2002-01-14 11:29:42 PST
Making WONTFIX.  

If you are still intested in this, post a message to one of the public
newsgroups.  If there is overwhelming response to stop adding common names to a
url, we will reconsider.  I guess, at the minimum, we could add a pref, but I do
not see the value.
Comment 11 Henrik Gemal 2002-01-14 13:34:40 PST
"www." ".com" should only be added if the user enter a name in the Location
field and pressed CTRL+ENTER, like in IE.
So I vote to reopen and fix this one...
Comment 12 Jonas Jørgensen 2002-01-14 13:58:19 PST
Adding www. and .com on Ctrl+Enter is (part of) bug 37867, but that will
probably never be implemented since bug 97123 is (at least IMO) a better idea
for what Ctrl+Enter in the URL bar should do.
Comment 13 Gervase Markham [:gerv] 2002-01-15 01:16:35 PST
Doug: a good reason for implementing a pref. for this behaviour is that it's one
of the W3C's Common User Agent Problems - see bug 68407. I'd like to reopen this
bug for the purposes of having such a pref (which could control all the "URL
enhancement" features which come under that bug.)

Gerv
Comment 14 Doug Turner (:dougt) 2002-01-15 08:04:32 PST
Gerv, I agree.  68407 is a dup of this bug.

Comment 15 Ben Bucksch (:BenB) 2002-01-16 01:53:59 PST
> 68407 is a dup of this bug.


No, that bug is bigger and a meta-bug. This one is a blocker for bug 68407.
Comment 16 Jonas Jørgensen 2002-01-16 09:13:20 PST
Ben Bucksch, Henrik Gemal, Gerv, Jeremy M. Dolan and Giuseppe Verde want this
bug to be reopened. That might not be overwhelming, but I think it's enough.
Reopening.

My suggestion is that you just take this functionality out, at least until it's
decided how it should work and how to customize it.
Comment 17 Jonas Jørgensen 2002-01-16 11:20:15 PST
Update from n.p.m.browser: Andrea Monni agrees with me too.
Comment 18 Jonas Jørgensen 2002-01-18 14:49:00 PST
...and so does Jesse Houwing. Eight persons and counting.

Would fixing this involve more than just ripping out some code? If not, fixing
this bug would also be a /very/ easy way of fixing bugs 34943, 40082 and 66183.
Comment 19 benc 2002-01-22 11:26:58 PST
If we have to do this in pieces, removing this behavior first, then fixing it
later via bug 37867 would be reasonable. 

This would be best, because I don't think anyone is going to agree on an ideal
behavior for this feature, so removing it then hopefully having a configurable
solution to re-implementing it, would be ideal. 

The only concern is that this behavior is a 4xp behavior.

As for removing it, I know I'm not the brightest coder, but there is probably a
single spot where the URL hostname is wrapped in "www." + hostname ".com", and
the URL is re-constructed and sent to getURL()...

Someone could comment this out in their tree, build it, and I could provide some
testcases.

Comment 20 Daniel Dvorkin 2002-01-22 11:42:51 PST
The "ideal behavior for this feature" is for it not to exist.  It was a bad idea
back when the majority of URL's were www.something.com; it's a terrible idea
now.  In short, it's not a feature, it's a bug.

Comment 21 TGOS 2002-01-26 10:47:45 PST
On my PC this bug prevents "Internet Keywords" from working correctly. E.g. when
I  just enter "test" into the address bar, I'd expect Mozilla to try http://test
(adding http:// by default is reasonable, as most liks are http:// and if users
want ftp://, they shall add it on their own) and once Mozilla recognized that
http://test doesn't exist, it should ask whatever server is responsible for the
Internet keywords. On my PC this is Google, taking the "I'm feeling lucky" page.

Problem: If I enter "test", I end up on http://www.test.com. This is not the
Google result! Google would have redirected me to http://www.toefl.org/. I only
get there if I enter "keyword:test" into the address bar. Only if I enter two
separate words, Internet Keywords will work as expected. So a funtion which
makes another implemented function useless is certainly no feature, but a bug.
Comment 22 neeti 2002-02-13 12:35:36 PST
The automagical prepending and appending occurs in docshell/webshell area. 
Assigning to that component. (gagan @neeti's desk)
Comment 23 Christian :Biesinger (don't email me, ping me on IRC) 2002-02-16 06:15:35 PST
*** Bug 125871 has been marked as a duplicate of this bug. ***
Comment 24 Matthew Hannigan 2002-02-16 06:51:36 PST
I had just entered bug 125871 but agree that it was a duplicate
of this. However I think my bug report gave another example of
how you can encounter this bug and is worth looking at especially
if you're not convinced this is an important bug to fix. 

Smmary of that bugs comments is that making a typo (leaving out
the dot) will invoke this unwanted behaviour.

Comment 25 Jonas Jørgensen 2002-02-18 14:33:06 PST
Oh, god, please, no. All this bug asks for is the _removal_ of a (mis)feature,
it can't take more than a few minutes to do it. There are *three* other bugs
that looks like they will be fixed by doing this, two of which are futured.

Could you reconsider the target milestone, Adam? Please?
Comment 26 Adam Lock 2002-02-20 14:29:22 PST
Duping against bug 34943

*** This bug has been marked as a duplicate of 34943 ***
Comment 27 benc 2002-03-04 03:50:50 PST
#21: What you are really asking for is bug 127872.
Comment 28 benc 2002-03-04 04:04:34 PST
REOPEN: adam: I don't think this is a duplicate of 34943. This bug talks about
what I think we are now grudgingly going to call "domain guessing" in the
location bar. (also this bug cannot be a duplicate and block it at the same time)

That is a 4xp behavior that people dislike, but probably an acceptable legacy
feature, if we could just make it customizable.

There is a lot of drift in 34943, but that talks about how domain guessing
occurs in absolute URL's with a hostname, presumably, the authors did not
contemplate that http://hostname would become http://www.hostname.com.

Comment 29 benc 2002-03-04 04:38:33 PST
updated both bug's summary...
Comment 30 Jonas Jørgensen 2002-03-04 04:49:46 PST
Clearing Target Milestone for reevaluation since this bug, after being futured,
was duped against bug 34943 which was then targeted to 1.0 and had a patch
attached which attempts to fix this bug.
Comment 31 Adam Lock 2002-03-04 08:01:53 PST
The patch on the other bug allows you to disable appending www. & .com and to
change these to other values, e.g. www. & .org if you like. 

You're right that some people don't like this feature but a lot do. Therefore
I'd be happy to see another patch to add a checkbox to control the feature. My
patch just wires the the fixup object to look for such a pref setting and I'll
probably punt the bug to someone in UI/Security to come up with the pref checkbox.

Personally I think both bugs are dupes unless you've got something else you'd
like to see the patch do.
Comment 32 amutch 2002-03-05 22:14:06 PST
Please add a pref or something to allow this behavior to be disabled.  While
some people might like this feature, it's an absolute disaster for those of us
supporting browsers in public settings. Have you ever seen how kids search the
WWW?  They enter in the word that they are looking for into the browser location
bar. Try that with "whitehouse" and see where that takes you.  No, not a good
thing at all. 

Defaulting to .com doesn't even make sense anymore. A better default behavior
would be to search at Google or something similar.  
Comment 33 Adam Lock 2002-03-06 04:15:22 PST
There is such a patch in bug 34943 to make www. & .com fixup a pref. It's
waiting for an sr.

I still believe this bug is a dupe of the other one.
Comment 34 Jonas Jørgensen 2002-03-06 05:03:41 PST
If that is what the patch does, it will fix _this_ bug -- it will _not_ fix bug
34943. When www..com fixup is enabled, it should only happen in the location bar
-- NOT on links. That is what bug 34943 is about.

If you _removed_ this feature rather than just making it optional, both this bug
and bug 34943 would be fixed. But if the feature is still there, bug 34943 will
still exist, and so will bug 66183.
Comment 35 Jonas Jørgensen 2002-03-23 06:25:51 PST
Fixed with the checkin for bug 34943. See bug 34943 comment 57.
Comment 36 Jonas Jørgensen 2002-03-24 10:36:13 PST
Reopening to debate whether browser.fixup.alternate.enabled should be true or
false by default. See bug 34943 comment 56 to 61.
Comment 37 Jonas Jørgensen 2002-03-24 10:43:18 PST
Created attachment 75851 [details] [diff] [review]
patch to turn this off by default

If it is decided that this should be on by default, attachment 75410 [details] [diff] [review] should be
checked in. Otherwise, this patch should be checked in.
Comment 38 Ben Bucksch (:BenB) 2002-03-24 13:04:57 PST
Yes, turn it on by default, esp. because of bug 34943.
Comment 39 Ben Bucksch (:BenB) 2002-03-25 04:02:14 PST
Ops, I meant that completion/guessing should be *off* by default.
Comment 40 Adam Lock 2002-03-25 05:08:42 PST
CC'ing Mitch

I believe the feature provides useful functionality and should stay on by
default. Yes, bug 34943 needs to be dealt with, but fixup in the address bar
should stay. Too many novices use this feature (even if they don't know it) to
simply disable it by default. 

We also need a pref UI to make it easy to turn on/off.
Comment 41 Jonas Jørgensen 2002-03-25 06:58:43 PST
> I believe the feature provides useful functionality and should stay on by
> default.

I see no positive comments about this feature in this bug, other than those made
by you.

> Yes, bug 34943 needs to be dealt with

What about bug 66183? It is currently futured.

> Too many novices use this feature (even if they don't know it) to
> simply disable it by default.

Comments 32 describes the usefulness of this feature for novices very well:
   "Have you ever seen how kids search the WWW?  They enter in the
   word that they are looking for into the browser location bar.
   Try that with "whitehouse" and see where that takes you."

> We also need a pref UI to make it easy to turn on/off.

Why? Why does this feature belong in Mozilla at all?
Comment 42 benc 2002-03-25 08:29:10 PST
Lets have one bug for each item:

Is this feature going to stay in existence? Looks like yes. So this bug status
is shared (as I understand bugzilla) by adam and jonas. You two will need to
come to some common ground as to what the status should be.

Should there be a pref? Yes. Do we need a new bug? If so I'll create one.

Should this pref be on or off by default? For mozilla, I recommend no. For
anyone else (like netscape) it's your call. Do we need a new bug? If so I'll
create one.
Comment 43 Jonas Jørgensen 2002-03-25 08:50:15 PST
> Is this feature going to stay in existence? Looks like yes. So this bug status
> is shared (as I understand bugzilla) by adam and jonas. You two will need to
> come to some common ground as to what the status should be.

If this feature is turned on by default, this bug is FIXED. If it's turned off
by default, this bug is WONTFIX.

> Should there be a pref? Yes. Do we need a new bug? If so I'll create one.

If you mean a *UI* pref, yes, we need a new bug.

> Should this pref be on or off by default? For mozilla, I recommend no. For
> anyone else (like netscape) it's your call. Do we need a new bug? If so I'll
> create one.

We don't need a new bug -- that is precisely what this bug is about.

What Netscape does is their decision. For Mozilla, it seems that users are
generally against this feature, so let's turn it off.
Comment 44 Daniel Dvorkin 2002-03-25 08:59:03 PST
The behavior (on vs. off by default) is not a new bug.  Fixing a bug includes
having the fixed code exhibit the desired behavior.  (In fact, that may be a
pretty good definition of what a bug fix actually is, regardless of how much
work has to be done to the underlying code to arrive at that goal.)  And as long
as it's on by default, frankly, it will still be a bug.
Comment 45 Adam Lock 2002-03-25 10:19:05 PST
Created attachment 75990 [details] [diff] [review]
UI for the pref

This patch supplies a UI checkbox in the Smart Browsing panel to disable the
pref if you like.

Reviews please.
Comment 46 Jonas Jørgensen 2002-03-25 11:45:43 PST
Comment on attachment 75851 [details] [diff] [review]
patch to turn this off by default

I was under the impression that attachment 75410 [details] [diff] [review] hadn't been checked in yet.
Turns out that it has, so this patch is obsolete now.
Comment 47 Jonas Jørgensen 2002-03-25 11:47:53 PST
Adam: You still haven't explained why you are against turning this pref off by
default. Remember, we're not talking about Netscape 6, only about mozilla.org's
Mozilla.
Comment 48 Adam Lock 2002-03-25 12:08:43 PST
I don't want to get in a long running debate over this. I have said before why I
think it should be enabled purely on usability grounds. If you want to debate
the issue, raise a specific bug on the matter perhaps assigned to security or
usability.

I am more interested in fixing underlying technical issues and I have submitted
a UI patch to this bug and another patch to bug 34943 today. Whatever the
default value is, both patches are required and they're both ready for review.
Comment 49 Jonas Jørgensen 2002-03-25 13:06:23 PST
> I have said before why I think it should be enabled purely on usability grounds.

You mean "Too many novices use this feature (even if they don't know it) to
simply disable it by default"? Well, novices don't use mozilla.org's Mozilla
distribution, so could we just turn it off here and leave it on in Netscape?

> If you want to debate the issue, raise a specific bug on the matter perhaps
> assigned to security or usability.

I *did* file a bug to debate whether www. and .com should be appended
automatically or not. The number is 115539.
Comment 50 Jonas Jørgensen 2002-03-25 13:10:33 PST
Created attachment 76053 [details] [diff] [review]
disable domain guessing

Die, evil misfeature, die!
Comment 51 benc 2002-03-25 15:05:34 PST
These are two distinct technical issues. Please create a new bug where you argue
this should be off by default. 

When bugs contain both implementation of prefs and debates of the default value,
the bugs tend to drift. The two items also need to be separately implemented by
a coder and QA.

(When you create that bug, I have a long list of reasons why it should be off by
default in mozilla, probably even longer than yours...)
Comment 52 Jonas Jørgensen 2002-03-25 15:13:15 PST
Bug 133371 created.
Comment 53 Adam Lock 2002-03-26 05:32:44 PST
Renaming this bug.

Please can I have a review for attachment 75990 [details] [diff] [review]?
Comment 54 benc 2002-03-26 09:48:04 PST
What is the name of the pref going to be? (I looked at the patch but couldn't
easily tell). Any chance it could be named something ending in "domainguessing",
if we have agreed this is the name of this feature/behavior?
Comment 55 Jonas Jørgensen 2002-03-26 10:03:08 PST
> What is the name of the pref going to be?

The pref already exists - it was created with the first patch for bug 34943.
It's name is browser.fixup.alternate.enabled.
Comment 56 benc 2002-03-26 11:09:41 PST
URI fixup does a lot of things.

Something more specific would be better.
Comment 57 Adam Lock 2002-03-26 11:34:38 PST
This pref is specific. Enable www. & .com fixup or disable it. The pref only
deals with that one feature.
Comment 58 Matthew Hannigan 2002-03-26 18:24:12 PST
Adam Lock:
> I have said before why I think it should be enabled
> purely on usability grounds.

I can't find that. Where is it?  Can it bear repeating
in these comments somewhere?


Comment 59 Adam Lock 2002-03-28 08:49:33 PST
Created attachment 76576 [details] [diff] [review]
Picture of the pref with patch applied

Attaching a picture to demonstrate the pref.
Comment 60 Adam Lock 2002-03-28 08:51:14 PST
Comment on attachment 76576 [details] [diff] [review]
Picture of the pref with patch applied

The right mime type this time
Comment 61 Adam Lock 2002-03-28 08:54:02 PST
Created attachment 76577 [details]
Picture again

Oops, trying again
Comment 62 Ben Bucksch (:BenB) 2002-03-28 09:17:27 PST
IMO, it should be in the Advanced... dialog for Location Bar Autocomplete.
Comment 63 Jonas Jørgensen 2002-03-28 09:35:17 PST
The list of domains excluded from what's related is far too small with this
patch. I agree with BenB -- move it to Advanced.
Comment 64 Adam Lock 2002-03-28 09:55:45 PST
It has nothing to do with the autocomplete feature so it doesn't make sense to
put it in there. Autocomplete is the drop down list of addresses you see when
you start typing.
Comment 65 benc 2002-04-03 09:13:57 PST
+cc: marlon for prefs panel changes.
Comment 66 Adam Lock 2002-05-24 11:50:20 PDT
Created attachment 84934 [details] [diff] [review]
More compact UI for pref

This new patch for the UI puts the pref in the Internet Keywords section so it
needs less room. If anyone has any ideas of a better way to word the text
please say so, otherwise I'd like to get this pref into Mozilla so we can
debate other issues surrounding it.
Comment 67 jlms 2002-05-28 10:00:53 PDT
Where can we discuss if this is desirable at all or not?
Comment 68 benc 2002-05-28 10:13:58 PDT
+nsbeta: This needs to beat the UI Freeze, as I understand it.
Comment 69 Peter Trudelle 2002-05-29 02:01:16 PDT
This is far too late to be trying to rush in such questionable, unplanned
changes; especially without involving the owners of affected modules and
components, such as  the URL Bar.  We need thorough discussion and review before
disabling features that are in our shipping products.
Comment 70 Adam Lock 2002-05-29 08:44:49 PDT
I believe the pref should go in on the trunk, but not the branch. It's miles too
late for localization anyway.

Can someone please review the patch for the trunk? It's simple and pretty
obvious what it's doing - namely adding a checkbox to enable/disable the feature.
Comment 71 benc 2002-05-30 07:20:21 PDT
marlon!
Comment 72 benc 2002-05-30 07:27:52 PDT
Peter: we've been discussing this feature, and it's various bad behavior for a
long time. Are you speaking for mozilla or Netscape? The reason we (those of us
who favor it) pushed for a pref is so that it could be defaulted off for
Mozilla, but still defaulted on for vendors that think the current
implementation is acceptable.

If there is a specification for the behavior, then we should debate the details
in spec and then file bugs to go to the correct implementation. In the case of
URLbar, I have never seen anything of that nature. In fact, somewhere betwee
0.9.9. and RCx, there was another change, where literal hostnames typed into the
URL bar NEVER go to IK, but always get sent to the resolver, then domain guessing. 

Personally, as the default owner of Networking QA, I'm tired of spurious DNS
bugs being filed in my component because of this feature. (try typing "mozilla"
and hitting return and you'll see what I mean).

Comment 73 Peter Trudelle 2002-05-30 12:21:50 PDT
I'm speaking for myself, but as the development manager for Netscape Navigator
(you know, the browser produced by our employer;-).  Making such unplanned
changes affects my team's ability to release this product on time and with the
expected feature set and quality.  I'm not sure I see signficant justification
for changing default behavior that has been in both products for years. Lack of
a spec isn't a reason to make changes at will. Even if it is only disabled in
mozilla, that is still several hundred thousand users, perhaps over a million
counting RedHat.  Only a small number of them will be heard in bugs and
newsgroups, and then only when they are unhappy, you won't hear from the people
who are happy with the current default. Also, at this point, I don't think we
can afford to spend time on bugs that haven't been plussed.
Comment 74 Adam Lock 2002-05-30 12:41:37 PDT
Irrespective of the default setting, it still needs a checkbox in the prefs
dialog.  On that basis, can I have a review of my patch please?

All the politics of whether to enable it or not should be confined to bug 133371
Comment 75 Peter Trudelle 2002-05-30 15:21:47 PDT
It isn't just the default state, it is the endless addition of complexity
without any apparent design, usability, or involvement of other groups that need
to do work to support this, such as Doc. Time spent by Netscape employees on
this also means that fewer of the things we really need for MachV get done.  cc
Jatin. Who owns the Smart Browsing prefs panel?  You should get their review too.
Comment 76 benc 2002-06-05 02:42:43 PDT
I think that everyone involved has done everything they need, and at all times,
we have been running around, trying to get the design right, involve the right
people, explain why this is really badly broken, etc. Personally, I have spent a
lot of time being nice (and occassionaly not), trying to get a clear set of bugs
that would lead to a set of actions that would make sense for everyone, mozilla,
mozilla testers, mozilla-based products, UI people, and most importantly (I
think) DNS itself.

For a while, I think the conversations were rudderless, but now there is a
specfic set of bugs, that gives a pretty reasonable course of action. 

If you don't want to take these fixes in commercial, stub then out in the
commercial overlay. It is your product, so it is your call there. In mozilla, I
cannot believe that at the last hour, 1.0 is going to go out with this still
completely broken. See bug 95707, if you haven't actually tried this, you should. 

In mozilla, I have an obligation to demand that we implement features that
comply with networking standards and demonstrate a literacy of how the internet
is structured. This feature does not meet any sensible, modern understanding of
how DNS domains are constructured, and is archaic and reminicent of the .com era. 

If you are running around with a feature that does not have a design
documentation (and apparently no clear QA ownership), then I think you should
take the change, because with this fix, you have control of this feature. If it
regresses wildly, or becomes a blackhole of risk, you can turn it off easily.
This behavior has gone rogue before, doing domain guessing on links and inline
HREFs that had non-qualified hostnames. 

What we really need is to implement bug 88217, which nobody seems to think is
important, but would make most of the problems with this bug (and a whole class
of other misc. DNS funkiness go away). 

That being said, who is the module owner, and who can do the UI review? I will
be happy to take any amount of time necessary to convince them that this should
be checked in as soon as possible.
Comment 77 Wesha 2002-07-18 12:36:08 PDT
*** Bug 158162 has been marked as a duplicate of this bug. ***
Comment 78 Blake Ross 2002-07-20 00:44:57 PDT
Can we please try to stay focused on the fact that we're making a product for
the people of the world?  That Ma and Pa Jones don't care at all about this
preference?  That even little advanced son Jones doesn't care?  That even I
don't care, and I rate pretty highly on the geek scale?  This bug seems to have
morphed over and over.  Let's stick to the issue presented in the summary --
that a few people want UI to set this pref -- and leave issues of defaults to be
decided in the newsgroup (with a subsequent bug if the outcome warrants it).

Hewitt (owner of urlbar) and Marlon should probably be the ones to make this
call.    I've e-mailed them.  There is no reason for anyone else to comment here
until they do.
Comment 79 marlon bishop 2002-07-22 11:09:56 PDT
i think this is a good thing to pref.  Far too many depend on it though so i'd
rather at least Netscape keep it on by default.  For Netscape, it should go in
smart browsing pref panel grouped together and underneath the current 'Location
Bar Autocomplete', however rename the group to just 'Location Bar'.  my attempt
at titling the pref might be something like:

(x) Enable domain guessing (append .com to unspecified URLs) 

However i wouldn't call it 'guessing' unless it actually is somewhat clever like
attempting .net .org if .com is 404.  cc'ing jatin for pref phrasing
Comment 80 Ben Bucksch (:BenB) 2002-07-22 12:29:17 PDT
> Far too many depend on it though so i'd
> rather at least Netscape keep it on by default.

Netscape has Internet Keywords enabled by default, not? Wouldn't Netscape's
Internet Keywords server be asked in the case that the user enters "test" and
<http://test> doesn't exist? That might be good migration path for users used to
the (IMO) broken behaviour. Just an idea...
Comment 81 benc 2002-07-22 13:10:42 PDT
Marlon: "domain guessing" was a name some of us came up w/ because it does
*guess*, I mean, there is not logical reason to assume you could query for
".com" so from a DNS perspective, this is viewed as wasteful, drawing-straws
kind of behavior. It is, based on statistics, the least-worst string to try, but
not much better than that.

Maybe the problem is that it isn't really "smart", and hence, might not be good
for "smart browsing".

One technical point: the guessing occurs on a DNS lookup failure, not on a 404.
If you received a 404, that would mean that you did get a DNS lookup to an IP
address and make a successful HTTP connection.

Ben: If you want something like that to work, you might want to look at #72 and
do some testing of a current build. What you want currently does not work, even
though it used to. Since there was no design spec, and you can use "go $IK" to
access single word keywords, I did not file a bug on this.
Comment 82 Anthony DeRobertis 2002-07-27 13:02:52 PDT
Tad bit too late for 1.0...
Comment 83 Adam Lock 2002-09-24 13:28:27 PDT
*** Bug 161699 has been marked as a duplicate of this bug. ***
Comment 84 Adam Lock 2002-09-24 13:29:15 PDT
*** Bug 170287 has been marked as a duplicate of this bug. ***
Comment 85 Juan José Mata 2002-10-22 22:59:48 PDT
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
Comment 86 benc 2002-11-02 00:40:55 PST
if a bug was targeted for a release, then pushed back, shouldn't it go to either
"--" (assign me!) or to some other milestone?

"Future" = doomed in most components.
Comment 87 benc 2002-12-13 00:24:15 PST
reset milestone and removed old mozilla keywords.
Comment 88 benc 2002-12-18 09:32:57 PST
If we do this, I would like to see a "more information" button (like Internet
Keywords).

Mozilla documentation for this feature is at:
http://www.mozilla.org/docs/end-user/domain-guessing.html
Comment 89 marlon bishop 2003-01-16 15:14:46 PST
Ok, after consulting Jatin on pref phrasing this is what we came up with: 

---
Domain Guessing

[ ] Automatically add "www." and ".com" to the location if a web page isn't found.
---

i do agree it's a good idea to pref this, just make sure it wouldn't be disabled
by default for Netscape.
Comment 90 Christopher Aillon (sabbatical, not receiving bugmail) 2003-01-17 02:25:53 PST
Marlon, what should the accesskey be?
Comment 91 Christopher Aillon (sabbatical, not receiving bugmail) 2003-01-21 22:13:40 PST
Created attachment 112254 [details] [diff] [review]
Add the pref per comment #89
Comment 92 jag (Peter Annema) 2003-01-21 22:48:35 PST
Comment on attachment 112254 [details] [diff] [review]
Add the pref per comment #89

sr=jag
Comment 93 Christopher Aillon (sabbatical, not receiving bugmail) 2003-01-21 23:31:19 PST
Taking to land.
Comment 94 Christopher Aillon (sabbatical, not receiving bugmail) 2003-01-21 23:32:14 PST
The pref is in.  Enjoy.
Comment 95 benc 2003-01-22 13:46:16 PST
VERIFIED, win98, today's daily build.

I'll verify this when 1.3b is out if nobody else does.
Comment 96 Aaron Leventhal 2003-01-24 09:36:34 PST
It needs to have an accesskey. It won't be visibly underlined until we fix bug
68841, but it's better to put it there now.

Here's the XUL accesskey FAQ: 
http://www.mozilla.org/projects/ui/accessibility/accesskey.html
Comment 97 benc 2003-01-24 15:12:03 PST
Can you pick what key you want? I think Chris will do the impl. 
Comment 98 benc 2004-01-26 12:02:54 PST
V

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