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.
??? Never seen this behaviour in Mozilla. www.* and *.com are *never* added.
Reporter : what build are you running, on what OS ?
Huh? Mozilla has done this at least since M15 - see also bug 34943.
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 ?
If this is done by the OS, and Mozilla doesn't add www. and .com, then how do
you explain bug 34943?
(I'm using Win2k.)
firstname.lastname@example.org, 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.
*** This bug has been marked as a duplicate of 34943 ***
Nope, separate issue. This one os about the location bar.
type "packetgram" into the location field and hit return...
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.
"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...
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.
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, I agree. 68407 is a dup of this bug.
> 68407 is a dup of this bug.
No, that bug is bigger and a meta-bug. This one is a blocker for bug 68407.
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.
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.
Update from n.p.m.browser: Andrea Monni agrees with me too.
...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.
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
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.
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.
The automagical prepending and appending occurs in docshell/webshell area.
Assigning to that component. (gagan @neeti's desk)
*** Bug 125871 has been marked as a duplicate of this bug. ***
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.
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?
Duping against bug 34943
*** This bug has been marked as a duplicate of 34943 ***
#21: What you are really asking for is bug 127872.
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.
updated both bug's summary...
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.
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.
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.
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.
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.
Fixed with the checkin for bug 34943. See bug 34943 comment 57.
Reopening to debate whether browser.fixup.alternate.enabled should be true or
false by default. See bug 34943 comment 56 to 61.
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.
Yes, turn it on by default, esp. because of bug 34943.
Ops, I meant that completion/guessing should be *off* by default.
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.
> I believe the feature provides useful functionality and should stay on by
I see no positive comments about this feature in this bug, other than those made
> 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?
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
> 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.
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.
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.
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.
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
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
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.
> 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.
Created attachment 76053 [details] [diff] [review]
disable domain guessing
Die, evil misfeature, die!
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...)
Bug 133371 created.
Renaming this bug.
Please can I have a review for attachment 75990 [details] [diff] [review]?
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?
> 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.
URI fixup does a lot of things.
Something more specific would be better.
This pref is specific. Enable www. & .com fixup or disable it. The pref only
deals with that one feature.
> 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?
Created attachment 76576 [details] [diff] [review]
Picture of the pref with patch applied
Attaching a picture to demonstrate the pref.
Comment on attachment 76576 [details] [diff] [review]
Picture of the pref with patch applied
The right mime type this time
Created attachment 76577 [details]
Oops, trying again
IMO, it should be in the Advanced... dialog for Location Bar Autocomplete.
The list of domains excluded from what's related is far too small with this
patch. I agree with BenB -- move it to Advanced.
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.
+cc: marlon for prefs panel changes.
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.
Where can we discuss if this is desirable at all or not?
+nsbeta: This needs to beat the UI Freeze, as I understand it.
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.
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.
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).
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.
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
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.
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.
*** Bug 158162 has been marked as a duplicate of this bug. ***
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.
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
> 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...
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.
Tad bit too late for 1.0...
*** Bug 161699 has been marked as a duplicate of this bug. ***
*** Bug 170287 has been marked as a duplicate of this bug. ***
Setting target milestone to 'Future' since 'mozilla1.1alpha' has already passed.
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.
reset milestone and removed old mozilla keywords.
If we do this, I would like to see a "more information" button (like Internet
Mozilla documentation for this feature is at:
Ok, after consulting Jatin on pref phrasing this is what we came up with:
[ ] 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.
Marlon, what should the accesskey be?
Created attachment 112254 [details] [diff] [review]
Add the pref per comment #89
Comment on attachment 112254 [details] [diff] [review]
Add the pref per comment #89
Taking to land.
The pref is in. Enjoy.
VERIFIED, win98, today's daily build.
I'll verify this when 1.3b is out if nobody else does.
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:
Can you pick what key you want? I think Chris will do the impl.