User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040802 Firefox/0.9.1+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040802 Firefox/0.9.1+ When typing a word WITHOUT spaces in to the address bar to find a page to do a google search for the first link firefox goes to the page but does not display the url it instead displays the google search. Reproducible: Always Steps to Reproduce: 1. type in "ebgames" in the addres bar leaving the.com out. 2. the page will load but the correct address will not show unless you refresh the page. Actual Results: The site http://www.ebgames.com/ebx/default.asp will load but only "ebgames" (witout the quotes" will show in the address bar. other examples include: "ign" "mozillafirefox" "slashdot" or any other word without spaces. Expected Results: The software should display the full address and not the word typed into the address bar. This works on a fresh profile with no extensions or themes. Branch/zip. This could be used to trick users so it could be a security problem but is not something that could be exploited easily.

Does not occur on 20040722 build, so may in fact be related to http://bugzilla.mozilla.org/show_bug.cgi?id=231393 checkins as mentioned in the forums, which were made on 7/23.

Confirmed on 20040801 aviary on the Mac. Confirming and setting hardware and OS to All.

This also affects other URL fixups. Typing "http://test" loads test.com. Potential security issue if you consider users trying e.g. http://intranet when their company's DNS server is muxed.

confirming Linux - Fx 0.9 branch 20040807

How about something like this? p.s. The change is in both browser.js and tabbrowser.xml because the progresslistener in tabbrowser.xml is only used when the browser is in tabbed mode and the progresslistener in browser.js is not (easily) tab aware.

-> pch for a look at this patch

Well due to google pagerang of MS site, and due to the results of "http" search, ommitting the ":" in an address can have this type of consequence. By the way using Gecko/20040817 Firefox/0.9.1+ the bug doesn't occures each times. Try the "language tools" address... It displays the correct address for me.

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

Seems to be fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)

In reply to the previous comment, I see no change in today's Linux builds. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)

(In reply to comment #10) > Seems to be fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.7.3) > Gecko/20040902 Firefox/1.0 PR (NOT FINAL) I don't confirm for the pretty same UA installed from scratch. It doesn't work well. The steps to reproduce give the same and other examples too.

confirming Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)

donno if this helps but if the search query is one word such as windowsxp, this bug appears. but if the search query is two words, this bug will not appear.

I think this problem only appears in trunk-builds. (I cannot reproduce it in 0.9.3 final.)

(In reply to comment #15) > I think this problem only appears in trunk-builds. > (I cannot reproduce it in 0.9.3 final.) Nope. Branch as well.

Still seeing this using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040920 Firefox/0.10.

(In reply to comment #17) > Still seeing this using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; > rv:1.7.3) Gecko/20040920 Firefox/0.10. Also with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040925 Firefox/0.10

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

(In reply to comment #19) > *** Bug 261965 has been marked as a duplicate of this bug. *** It is not a duplicate: see 261965.

pch, had any time to look at this or ideas on how to fix. I think we need to get this soon if it is going to make it for 1.0

It has been working for me in some instances in Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10. However I don't recall how I got them to work.

Comment on attachment 155864 [details] [diff] [review] Clear user typed value for keyword loads r+a=ben@mozilla.org

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041009 Firefox/0.10 I use "browse by name" as my keyword URL instead of "i'm feeling lucky". The URL is correct if I type "ebgames" but not if I type "foo". Maybe the patch assumes the keyword URL will result in a redirect.

(In reply to comment #24) > I use "browse by name" as my keyword URL instead of "i'm feeling lucky". The > URL is correct if I type "ebgames" but not if I type "foo". Maybe the patch > assumes the keyword URL will result in a redirect. This patch just fixes the regression from the patch in Bug 231393. I think the behaviour you're seeing existed before the patch from that bug (I tried in Firebird 0.6 and it seems to act the same way as recent nightlies do). Can you confirm that the current behaviour is the same as the pre-"Bug 231393 patch" behaviour? I don't know if there is another bug dealing with the keyword:<keyword> issue or not (assuming the regression really is fixed).

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

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

> I don't know if there is another bug dealing with the keyword:<keyword> issue or > not (assuming the regression really is fixed). I didn't find one, so I filed bug 264830.

Don't see this bug in trunk, status: FIXED?

Yes, this looks to be fixed in the aviary landing. Reopen if you see something that clearly wasn't fixed when the aviary branch was landed. (tested using the Linux 20041216 nightly)