Closed Bug 254040 Opened 17 years ago Closed 17 years ago

Incorrect address in address bar when doing a google search.

Categories

(Firefox :: Address Bar, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: spam, Assigned: p_ch)

References

Details

(Keywords: fixed-aviary1.0, regression)

Attachments

(4 files)

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.
Component: Find Toolbar / FastFind → Location Bar and Autocomplete
Confirmed on 20040801 aviary on the Mac. Confirming and setting hardware and OS
to All.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR?
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0+
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
Assignee: firefox → p_ch
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.
Keywords: regression
*** 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)
Status: NEW → ASSIGNED
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
Attachment #155864 - Flags: review+
Attachment #155864 - Flags: approval-aviary+
Keywords: fixed-aviary1.0
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)
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.