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.

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

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

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.

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.

(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.

(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

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.

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

1.0 was out a month ago...

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

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/

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

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

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

WFM

(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)

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.

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

WFM.

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

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.

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.

(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.

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/?".

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

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 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 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.

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

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;

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

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

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

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.

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

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

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