I've added that as part of getting the UI hooked up in bug 115539.
Actually, this still needs more work: 1- document the prefs. 2- test the w/ the feature off to verify the behavior.
Added prefs UI and prefs strings.
/tmp/cvs8Erc1X: 9 lines, 319 characters. Checking in domain-guessing.html; /cvsroot/mozilla-org/html/docs/end-user/domain-guessing.html,v <-- domain-guessing.html new revision: 1.5; previous revision: 1.4 done
- <meta http-equiv="content-type" - content="text/html; charset=ISO-8859-1"> (style guide advises against this) - found. Let us assume that the user's default domain name is "mcom.com".<br> (what does "default domain name" mean?) - Domain guessing will attempt to add "www." to the front and/or ".com" + Domain guessing will attempt to add "www." to the beginning and/or ".com" - <span style="font-weight: bold;">How do I use Domain Guessing?</span><br> + <h2>How do I use Domain Guessing?</h2> - Domain Guessing can be enabled/disabled via Preferences | Smart - Browsing | Domain Guessing (Mozilla 1.3 and later, see bug <a + Domain Guessing is available in Mozilla 1.? or later. In Mozilla 1.3 or + later, you can turn Domain Guessing on and off from Preferences (View | + Preferences | Smart Browsing | Domain Guessing) (see bug <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=115539">115539</a>). - Domain Guessing is controlled by a several preferences.<br> + Domain Guessing is controlled by several preferences.<br> - browser.fixup.alternate.enabled - true/false, controlled by Prefs UI - browser.fixup.alternate.prefix - "www." - browser.fixup.alternate.suffix - ".com" + browser.fixup.alternate.enabled | true/false | accessible via Preferences + browser.fixup.alternate.prefix | "www." | hidden (see briefprefs.html) + browser.fixup.alternate.suffix | ".com" | hidden (see briefprefs.html) (should be in table. use <tt> instead of <span>.) - <span style="font-family: monospace;"> </span>This feature is currently - on by default, but daily builds might ship with the preference off - during test periods.<br> (un-necessary info) - input into a displayed page. Another form of URL resolution is Internet - Keywords, which asks a remote server what page should be displayed.<br> + input into a displayed page. Another form of URL resolution is + <a href="internet-keywords.html">Internet Keywords</a>, which asks a + remote server what page should be displayed.<br> (internet-keywords.html probably needs to link to this page too) "Why is it called Domain Guessing..." should be after "limitation" + <p> The main reason several contributors settled on this name is that the - browser is actually guessing that that the new domain name might work. + browser is actually guessing how the new Web address might work. - The guess is two-fold: the browser does know the user means - "www.hostname.com", and the browser does not know that - "www.hostname.com" actually exists in DNS. This is not auto-completion, + The guess is two-fold: 1) the browser does know the user means + <q>www.hostname.com</q> but 2) does not know if <q>www.hostname.com</q> + actually exists. This is not auto-completion, because the browser is getting an error for what you typed, and - re-trying with a second guess without asking the user for permission. + re-trying with a guess without user prompt. - Autocompletion would be something like the menu bar offering to turn - what you typed into "www.hostname.com", "www.hostname.net", etc. in the - autocomplete pulldown menu. In other words, autocomplete would complete + Autocomplete would be something like offering choices of "www.hostname.com", + "www.hostname.net", etc. in a pull-down menu. In other words, autocomplete + would <i>complete</i> - the user input proactively, not the DNS request after an error occurred.<br> + the user input proactively instead of sending a second network request after + an error occurred.</p> - <br> - Domain Guessing has a couple important limitations:<br> + <p>Domain Guessing has some important limitations:</p> 5- Security should be number 1, before everything else - Domain Guessing affects URLs that have only a hostname - (http://mozilla/index.html) but not fully qualified domain names, - "FQDNs" (http://www.mozilla.org). Domain Guessing occurs in some cases, (this is confusing) 4- Flawed usage of DNS contains some unnecessary information and is too technical for a end-user doc.
(sure, I'll QA it, no shortage of bugs for me anyhow...) - <meta http-equiv="content-type" - content="text/html; charset=ISO-8859-1"> Composer may have put that in, I have no opinion on this matter. - found. Let us assume that the user's default domain name is "mcom.com".<br> default domain is a system-level pref. The resolver uses default domain when it thinks you wanted it to be used, but left it off. The exact behavior varies by system, but the practical meaning is: if you provide a hostname, the resolver searches for hostname.defaultdomain. For this doc, maybe we should change the example to mozilla.org. + Domain Guessing is available in Mozilla 1.? or later. In Mozilla 1.3 or Domain guuessing has been in mozilla pretty much sinced the beginning. Getting it pref'd occurred sometime later, and getting the UI exposed happened in 1.3. I don't think it is worth reseaching when the initial behavior was checked in, it might be pretty impossible to find, because nobody even gave this behavior a name until I wanted to get it out of the way. - <span style="font-family: monospace;"> </span>This feature is currently - on by default, but daily builds might ship with the preference off - during test periods.<br> (un-necessary info) This needs to stay in, because we might start flipping the enabled pref for daily builds. On role of this document is duplicate bug prevention. + The guess is two-fold: 1) the browser does know the user means I like the improvements you have made here for readability, but I think this line should remain unchanged. Here's why: The browser is guessing, it cannot know the user intent. If I typed: "starcraft", intending to find starcraft.mcom.com (my venerable NT web server, may it RIP...), the browser would then want to falsely assume that I meant "www.starcraft.com". In many cases, (if you poke around the bug reports), this guess turns out to be a false assumption. That is why this feature can be so annoying to intranet users. - "FQDNs" (http://www.mozilla.org). Domain Guessing occurs in some cases, (this is confusing) This document was not written for end users in mind. Basically, I don't QA DG, but people keep filing bugs against DNS when it is DG's fault. So I wrote this document as a handy "here's why it works that way" URL as well as a single unitifed argument for why it should be turned off. For now, I think the more technical DNS and network aspects need to be left in, because it is often hard for people who think this is "neat" to understand just how badly done this is. We need a very end-user oriented write up in bug 190170, so I'm not disagreeing with your points about what is end-user and what is technical, but I hope you might consider abstracting what you think is useful for end users, and putting up some text for the online-help files.
QA Contact: rudman → benc
The world is changing, so since I wrote it, it makes sense now for me to own this.
Assignee: rudman → benc
Resolve as fixed so this doesn't show up in the radar. People can still follow the feedback link and comment here good job, Ben
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
V. Thanks for the help Daniel!
Status: RESOLVED → VERIFIED
I would like to add diffrent extentions to search in rg .org .net. co.uk .nl in the priority order that I can fill in myself. Raymond
See bug 77740. You probably should look around in Firefox. They implement similar functionality, but in a less broken way. Domain Guessing is probably going to be turned off by default soon.
It would be nice if this feature allowed you to set a list of suffixes to try. Or if it tried each suffix without the "www." before adding the "www."
John: This bug is about the documentation of the feature, not the feature itself. You might find that there are bugs about this already.
You need to log in before you can comment on or make changes to this bug.