Closed Bug 115539 Opened 23 years ago Closed 22 years ago

Domain Guessing: Add pref UI to disable/enable (adding "www." and ".com" to domain names)

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jonasj, Assigned: caillon)

References

(Blocks 2 open bugs)

Details

Attachments

(4 files, 3 obsolete files)

disable domain guessing
435 bytes, patch
Details | Diff | Splinter Review
Picture again
86.88 KB, image/jpeg
Details
More compact UI for pref
2.94 KB, patch
Details | Diff | Splinter Review
Add the pref per comment #89
2.19 KB, patch
timeless
: review+
jag+mozilla
: superreview+
Details | Diff | Splinter Review
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.)
Blocks: 68407
Blocks: 63736
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.
*** This bug has been marked as a duplicate of 34943 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Nope, separate issue. This one os about the location bar.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
type "packetgram" into the location field and hit return...
Severity: minor → normal
Keywords: mozilla1.0
Blocks: 34943
Blocks: 66183
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Component: Networking → XP Apps
Resolution: --- → WONTFIX
"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.
Blocks: 40082
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
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. 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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
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 testcases.
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)
Assignee: neeti → adamlock
Status: REOPENED → NEW
Component: XP Apps → Embedding: Docshell
QA Contact: benc → adamlock
*** 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.
Target Milestone: --- → Future
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
No longer blocks: 40082
#21: What you are really asking for is bug 127872.
Blocks: 40082
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...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Stop adding "www." and ".com" to domain names automatically → Domain guessing in Location (Stop adding "www." and ".com" to domain names automatically)
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.
Status: REOPENED → NEW
Target Milestone: Future → ---
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.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Reopening to debate whether browser.fixup.alternate.enabled should be true or false by default. See bug 34943 comment 56 to 61.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
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.
> 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?
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.
> 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.
Attached patch UI for the pref (obsolete) — — Splinter Review
This patch supplies a UI checkbox in the Smart Browsing panel to disable the pref if you like. Reviews please.
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.
Attachment #75851 - Attachment is obsolete: true
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.
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.
> 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.
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]?
Summary: Domain guessing in Location (Stop adding "www." and ".com" to domain names automatically) → Add pref UI to disable/enable domain guessing in Location (adding "www." and ".com" to domain names)
Target Milestone: --- → mozilla1.0
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.
QA Contact: adamlock → benc
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?
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
Attached image Picture again —
Oops, trying again
Attachment #76576 - Attachment is obsolete: true
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.
Target Milestone: mozilla1.0 → mozilla1.1alpha
Blocks: 133371
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.
Attachment #75990 - Attachment is obsolete: true
Where can we discuss if this is desirable at all or not?
Keywords: nsbeta1
+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.
marlon!
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...
Keywords: mozilla1.1, patch
*** 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.
Target Milestone: mozilla1.1alpha → Future
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.
Keywords: mozilla1.0, mozilla1.1
Target Milestone: Future → ---
No longer blocks: 40082
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
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.
Marlon, what should the accesskey be?
Comment on attachment 112254 [details] [diff] [review] Add the pref per comment #89 sr=jag
Attachment #112254 - Flags: superreview+
Attachment #112254 - Flags: review+
Taking to land.
Assignee: adamlock → caillon
Status: REOPENED → NEW
The pref is in. Enjoy.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
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: http://www.mozilla.org/projects/ui/accessibility/accesskey.html
Can you pick what key you want? I think Chris will do the impl.
V
Status: RESOLVED → VERIFIED
Summary: Add pref UI to disable/enable domain guessing in Location (adding "www." and ".com" to domain names) → Domain Guessing: Add pref UI to disable/enable (adding "www." and ".com" to domain names)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: