Closed Bug 317056 Opened 15 years ago Closed 5 years ago

URL rewrites (adding "www.") should be undone if they, too, fail


(Core :: DOM: Navigation, enhancement)

Not set





(Reporter:, Unassigned)


(Blocks 1 open bug)


(Keywords: ue)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When entering a URL, people sometimes make typos.  Thus, the
URL is invalid, and the browser makes a few guesses (like
prepending "www.") to see if it can guess something valid.
However, sometimes the guess is also an invalid URL and
the browser's guess is left in the Location bar, making
it unnecessarily painful to correct the typo.

For example, I mean to type "", but I accidentally
type "slashdot.og" (i.e. I leave out the 'r').  The browser
tries the domain "slashdot.og" and this fails, so then it
automatically tries the domain "www.slashdot.og", and this
also fails.  Then the text "http://www.slashdot.og" is what's
left in the Location bar; now correcting a one-character typo
is a lot more of a pain than it should be.

In the particular case of, visiting
"" will redirect you to the correct
URL, "", automatically but this is not
the case for all web sites.  In some cases, ""
is correct but "" does not redirect.
In this case, the "" typo would be changed into
"" and it would be necessary to delete
the "www." as well as adding the missing "o".

Reproducible: Always

Steps to Reproduce:
1.  Type a URL that isn't supposed to have a "www." prefix
into the Location bar, but make a typo.

Actual Results:  
The browser will have added "www.", even though this is not correct

Now correct your typo; this takes longer because the browser thinks
its guess is better than what you originally typed, even though it
knows that neither one is a valid URL.

Expected Results:  
The browser should save the original text somewhere in a buffer
somewhere.  If none of its guesses are correct, then it should
restore the original text so that the user only has to correct
the typo and not also undo the results of the browsers inferences.
Oh yeah, lest this escape notice, I should point out that this behavior
is not limited just to the case of adding "www." at the beginning
of a domain.

It can also occur when the browser infers the protocol from the URL.
For example, suppose I want to visit the NetBSD FTP site, and I mean
to type "".  Normally, the browser will change that to
"".  Now, suppose I accidentally type
"".  Then browser does not match "ftp" and changes it
to "".  So, here is another situation where I
have to correct more than the typo.
Summary: URL rewrites should be undone if they, too, fail → URL rewrites (adding "www.") should be undone if they, too, fail
Assignee: nobody → darin
Component: Location Bar and Autocomplete → Networking: HTTP
Product: Firefox → Core
QA Contact: → networking.http
Version: unspecified → 1.8 Branch
Assignee: darin → adamlock
Component: Networking: HTTP → Embedding: Docshell
QA Contact: networking.http → adamlock
There is nothing that can be done in the second case, the code is looking to match "ftp". If you don't type that, how would the code know you meant ftp?
(In reply to comment #2)
> There is nothing that can be done in the second case, the code is looking to
> match "ftp". If you don't type that, how would the code know you meant ftp?

Obviously it can't, but that's not the point.  The point is that
if the code fails to discover what you meant, then it should put
things back like it found them rather than leaving them in an
arbitrary state.

Creating a URL from the string the user types can be viewed as a
search problem.  You are searching the space of possible URL
corresponding to the string for one that is valid.

I am saying the bug is that if the search fails, then afterwards
the text field contains the last item tried rather than the string
the user typed.  This is a bug because what the user typed is much
more likely to be close to what they want than the last item in a
failed search based on what they typed.

So, in the second case, my contention is that the text field should
contain "" and neither "" nor
"".  The domain "" is a
non-existent domain, so the user should be given the chance to go
back and correct the failure at the point where it happened.
You appear to be making two related but non-identical requests here.

The first is that when the browser attempts to modify a failed URL (specifically, by adding a protocol, "www." prefix, and/or ".com" suffix) and the modified version also fails, then the address bar should revert to the original form. That's an interesting idea. Confirming bug, marking as Enhancement.

Your second is an address wizard that looks for other typos in a URL and tries to correct them. That sounds like major work, unrelated to the first idea. You could submit it as a separate bug, but you'd probably have better luck if you could convince a 3rd party to create such a trick as an XPI browser extension.
Severity: minor → enhancement
Ever confirmed: true
OS: Mac OS X → All
Hardware: Macintosh → All
Actually, I'm just making one request.  I admit some of my comments may have muddied the waters, so let me start my explanation over:

There is a text-input field into which I can type either a URL or a string which is shorthand for a URL.  If I type in shorthand for a URL, the browser will try various transformations to turn it into a real URL.  My request is that if the browser can't, through all of its various transformations, make a URL that works, it should put the contents of that text field back to how I had entered it so I can correct the typo.

Or to put it another way, if the browser goes down a path that leads to a dead end, then its transformations haven't been of any value, and it should backtrack to the beginning.  It should not leave me in the dead-end alley and force me to do the backtracking of all its transformations manually.  The transformations were obviously not beneficial, so the changes should be discarded.

Some examples:
(1) I mean to type "" but accidentally type "slashdot.og".  The browser tries the URL "http://slashdot.og/" and this fails.  Next, the browser tries "http://www.slashdot.og/" and this fails also.  Since everything it tried has failed, it should put "slashdot.og" back into the text box.  The text field should not contain "www." because trying the "www." did not achieve success and there is no reason to believe adding the "www." was better.

(2) I mean to type "" but accidentally type "".  The browser sees there is no URL scheme.  The text does not match "ftp", so it chooses the "http" scheme, producing the URL "".  It fails to retrieve this URL since the DNS name doesn't exist.  So it should put "" back into the text box.  It should not leave "" in the text box because this URL didn't load, and therefore there is no reason to believe that prepending "http://" was the right thing to do.

So, I'm not saying the browser should magically conclude that "fpt" was really supposed to be "ftp".  I'm just saying that I should be able to correct my own transposition typo without the extra work of cleaning up after the browser's failed experiments (that were based on bad data to begin with).
Duplicate of this bug: 434962
Assignee: adamlock → nobody
QA Contact: adamlock → docshell
Version: 1.8 Branch → Trunk
it seems this (bug) is known for quite a time...but i think firefox's behavior changed a few releases ago! it's actual behavior is really annoying!
I'd go further and argue that Firefox shouldn't change what's shown in the address bar until/unless the correction (e.g. adding www) turns out to work.  This avoids a race between a user fixing a typo and Firefox reverting the URL.
Although I am not a programmer, I would love it if somebody took up fixing this bug... or at least got it assigned to 3.7 or 4.0 so that somebody took it up.

I personally see this as 2 or more separate bugs.

1. intelligent changing the URL varying on guessed protocol if there is a typo.
2. The superbar does not behave in a friendly manner if you type a bad URL and can steal focus. (My pet peve)

I am a horrible typer.. I usually catch my errors before the page finishes loading.. and find the bar stopping me from finishing typing rather annoying.

I don't use bugzilla much.. so I don't know how things work.. but if the 2 features could be split, and my pet peeve (number 2) be done... I would be thrilled.

Although I'm not a coder. I"m guessing my #2 would be easier to implement as it is a simple behavior/prompt hiccup.. where as getting #1 to behave in a manner that would result in the URL you go to to be where you actually intended to go a lot more of a pandoras box.. or hard to implement fully.. like separating http from https.. and auto adding http:// when it may prevent you from getting to your desired URL or location.
Keywords: ue
Blocks: cuts-control
What's even worse is when you type something like "lcoalhost" instead of "localhost" in the location bar, and the browsers leaves you with "", which you subsequently have to re-type.
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 66183
You need to log in before you can comment on or make changes to this bug.