264610 - (domain-guessing) Domain Guessing: URL is not updated when guessing loads www.hostname.com

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect)

Description

[Joseph Delaney]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

This looks very similar to Bug 236608 but that bug specifically did NOT affect
Firefox.

If you type a single word in the location bar, such as "cnn"  it will correctly
load cnn.com or www.cnn.com but the location bar does not update to reflect the
true location. It still says "cnn"

Reproducible: Always
Steps to Reproduce:
1. Type "cnn" in the location bar, hit enter.
2. Even more bizarre, try typing "rutgers" and hit enter.


Actual Results:  
The browser finds http://cnn.com but the location bar still says "cnn". In the
case of "rutgers" the browser will find http://rutgers.com which redirects
immediately to http://www.rutgers.edu/ but the location bar does not change even
though the top-level domain has changed.

Expected Results:  
The location bar should reflect the location of the page. Always.

This used to work correctly in earlier versions of Firefox.

Comment 1

[Bill Gianopoulos [:WG9s]]

This is a duplicate of bug 254040 which has been fixed on the branch.  Just
download the lastest branch nightly.

Comment 2

[Peter van der Woude [:Peter6]]

*** This bug has been marked as a duplicate of 254040 ***

Comment 3

[Phil Ringnalda (:philor)]

Wups, not a dup: Domain Guessing isn't I Want To Get Lucky.

Steps to reproduce:
1. in about:config, change keyword.enabled to false, ensure
browser.fixup.alternate.enabled is true
2. use LiveHTTPHeaders so you see what's happening
3. type rutgers in the addressbar

You don't do a keyword: search for rutgers and get redirected to
www.rutgers.edu, you go directly to www.rutgers.com which redirects to
www.rutgers.edu, without clearing what you typed. That's Domain Guessing, and
this is the Firefox version of bug 236608 - either we've regressed since then,
when people said it worked in Firefox, or (more likely) they weren't turning off
keyword.enabled (see bug 236608 comment 32 and bug 236608 comment 33 where the
answer should have been "yes, I'm remembering to do that").

Luckily, not many people disable keyword.enabled, because it's probably too late
for 1.0.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Another way to reproduce this is to simply type www.<domain>, which will first
try www.<domain>.com and then display that page. It still does not update the
url in the location bar.

For example, enter www.firefox in the location bar and press enter.

Comment 5

[Chris Vance]

(In reply to comment #4)
> Another way to reproduce this is to simply type www.<domain>, which will first
> try www.<domain>.com and then display that page. It still does not update the
> url in the location bar.

I saw this yesterday and today as well.  www.url redirects to
http://apps5.oingo.com/apps/domainpark/domainpark.cgi?client=netw8744&s=domainpark.networksolutions.com

What is worse is typing "www.getfirefox/releases/".  The browser displays
http://www.mozilla.org/products/firefox/ but still shows the URL typed.  The
/releases/ isn't even taken into consideration.

Comment 6

[Chris Vance]

(In reply to comment #5)
> www.url redirects to
>
http://apps5.oingo.com/apps/domainpark/domainpark.cgi?client=netw8744&s=domainpark.networksolutions.com

I should note that I was testing this via Telnet to view the server response
headers, and I forgot to add the Host: header.  The correct redirected URL for
www.url.com is:

http://apps5.oingo.com/apps/domainpark/domainpark.cgi?client=netw8744&s=www.url.com

Comment 7

[David Balažic]

I see this problem on in winXP FF-1.0  system, but no on another w2k FF-1.0.
I enter "sophos.si" as test.

Comment 8

[benc]

related bug 236608 blocked 1.7 branch, so this might be worthy of blocking
aviary1.0, or being targeted for next FF release.

Comment 9

[Asaf Romano (gone)]

1.0 was out a month ago...

Comment 10

[Thomas Kaschwig]

*** Bug 283859 has been marked as a duplicate of this bug. ***

Comment 11

[Thomas Kaschwig]

I can confirm this bug with Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.6)
Gecko/20050223 Firefox/1.0.1 and the latest trunk build on Windows (Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050226 Firefox/1.0+).

It also works, when you enter a valid URI, which has no DNS record:
Enter "thomaskaschwig.de" (which has no DNS record) into the location bar and
hit enter. Firefox loads "www.thomaskaschwig.de", which is a redirect to
http://www.kaschwig.net/, but still displays "thomaskaschwig.de" in the location
bar. The "View Page Info" and the "View Source" dialogs are showing the correct
URI: http://www.kaschwig.net/

Comment 12

[Daniel Veditz [:dveditz]]

*** Bug 284269 has been marked as a duplicate of this bug. ***

Comment 13

[Daniel Veditz [:dveditz]]

*** Bug 287811 has been marked as a duplicate of this bug. ***

Comment 14

[Daniel Veditz [:dveditz]]

*** Bug 287114 has been marked as a duplicate of this bug. ***

Comment 15

[Chris]

WFM

Comment 16

[Chris]

(In reply to comment #15)
> WFM

sorry...WFM:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050422
Firefox/1.0+
(WINDOWS 2000)

Comment 17

[David Balažic]

Bug still alive in :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3

Tried "sophos.si".
I have TBP 1.2.4 and SubmitToTab 0.3.1 extensions.

Comment 18

[Daniel Veditz [:dveditz]]

*** Bug 293202 has been marked as a duplicate of this bug. ***

Comment 19

[Asa Dotzler [:asa]]

WFM.

Comment 20

[Phil Ringnalda (:philor)]

Still present in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050615 Firefox/1.0+ per the STR in comment 3

Comment 21

[Daniel Veditz [:dveditz]]

This bug is very much present in Deer Park (20050712). If for some reason you
can't reproduce this then try some of the domains from the bugs I duped to this one.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

While I have no doubt this is a bug (I reproduced it), keyword.enabled is not a
pref we have a UI for, so I'm going to say that this isn't a blocker. 

Comment 23

[Daniel Veditz [:dveditz]]

(In reply to comment #22)
> While I have no doubt this is a bug (I reproduced it), keyword.enabled is not a
> pref we have a UI for, so I'm going to say that this isn't a blocker. 

Ignore comment 3, you do not need to set keyword.enabled to false to reproduce
this -- see all the dupes.

You need keyword set to false if you try to reproduce with a one-word term like
"rutgers" (otherwise the keyword code takes over), but if you type in any
foo.com or www.foo that gets converted to www.foo.com then you can reproduce
this in the default Firefox configuration. This happens fairly commonly.

rutgers.com
www.google

This gets more important with more spoofy URLs (like those with IDN characters)
where this also avoids our URI fixup code. Restoring previous flags since the
minus was based on a misunderstanding of the bug.

Comment 24

[Ed Lee :Mardak]

Bug 233853 has a fix for suffix completion depending on cmd/shift enter. Right
now, if you type in "mozilla/?" then press cmd-shift-enter (to add on .org),
you'll end up at "www.mozilla/?.org" which firefox assumes to be
"www.mozilla.com/?.org" therefore showing the index page of mozilla.com instead
of that of mozilla.org. But after the page loads, the location bar shows only
"mozilla/?".

Comment 25

[Asa Dotzler [:asa]]

Ben, can you update the ETA here? Thanks.,

Comment 26

[Phil Ringnalda (:philor)]

Attachment: port of bug 236608 patch

Pretty straight port of the seamonkey patch that's been baking for more than a
year. Works on all of the testcases in all of the dups.

Comment 27

[Mike Connor [:mconnor]]

Comment on attachment 193999 [details] [diff] [review]
port of bug 236608 patch

vlad/bsmedberg should be able to get to this, I don't have time before I leave,
sorry.

Comment 28

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 193999 [details] [diff] [review]
port of bug 236608 patch

The patch looks fine to me, but all of the comments need to be updated --
there's lots of references to setting userTypedClear to true/false, when
instead it's being handled as a counter now.  (One of the comments was updated,
but the rest need to be updated as well.)

r=vladimir with updated comments.

Comment 29

[Phil Ringnalda (:philor)]

Attachment: with comments updated

Updated comments, including reversing the endDocumentLoad comment's meaning to
reflect reality, carrying over the r+.

Comment 30

[:Gavin Sharp [email: [e-mail]]]

Trunk:
toolkit/content/widgets/browser.xml; new revision: 1.75;
toolkit/content/widgets/tabbrowser.xml; new revision: 1.107;
browser/base/content/browser.js; new revision: 1.499;

Comment 31

[Tracy Walker [:tracy]]

verified with Linux trunk Firefox 2005-08-29-06-trunk

Comment 32

[Marcia Knous [:marcia]]

Verified using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20050829 Firefox/1.6a1

Comment 33

[Phil Ringnalda (:philor)]

*** Bug 306318 has been marked as a duplicate of this bug. ***

Comment 34

[Jay Patel [:jay]]

v.fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1)
Gecko/20050829 Firefox/1.6a1.  We should get this onto the branch.

Comment 35

[Asaf Romano (gone)]

1.8 Branch:
Checking in toolkit/content/widgets/browser.xml;
/cvsroot/mozilla/toolkit/content/widgets/browser.xml,v  <--  browser.xml
new revision: 1.70.2.2; previous revision: 1.70.2.1
done
Checking in toolkit/content/widgets/tabbrowser.xml;
/cvsroot/mozilla/toolkit/content/widgets/tabbrowser.xml,v  <--  tabbrowser.xml
new revision: 1.103.2.4; previous revision: 1.103.2.3
done
Checking in browser/base/content/browser.js;
/cvsroot/mozilla/browser/base/content/browser.js,v  <--  browser.js
new revision: 1.479.2.19; previous revision: 1.479.2.18
done

Comment 36

[Tracy Walker [:tracy]]

verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07

Comment 37

[benc]

*** Bug 297393 has been marked as a duplicate of this bug. ***