Closed Bug 240095 Opened 20 years ago Closed 18 years ago

Location Bar doesn't stay open (collapses) when clicking on arrow the first time

Categories

(Toolkit :: Autocomplete, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8.1beta1

People

(Reporter: hbug_1, Assigned: masayuki)

References

Details

(Keywords: fixed1.8.1, top100)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040408 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040408 Firefox/0.8.0+

When a web page text box is focused, clicking the address bar drop down history
arrow will open the address history and immediately close it again.  This also
happens when focus comes from the FF search box.  When focus comes from any
other component the history opens correctly (as far as i can tell from testing)

Reproducible: Always
Steps to Reproduce:
This only seems to happen with single-line textfields. 
confirmed with 20040429 trunk build on winXP. seems to be windows only. possibly
related to bug 192577.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed.

- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a) Gecko/20040514
Firefox/0.8.0+
- Microsoft Windows 2000 Pro 5.00.2195 SP4
Summary: address bar drop down history fails to open when focus comes from a text box → address bar drop down history fails to open when focus comes from a text box / field
*** Bug 235525 has been marked as a duplicate of this bug. ***
*** Bug 250636 has been marked as a duplicate of this bug. ***
Top100 - This is a very prominent bug if you happen to try and use your location
bar dropdown while at Google.
Keywords: top100
*** Bug 282046 has been marked as a duplicate of this bug. ***
(In reply to comment #6)
> Top100 - This is a very prominent bug if you happen to try and use your location
> bar dropdown while at Google.

It's also pretty prominent if you let Firefox be your homepage because it comes
up with the cursor blinking in the Google search field.  I hadn't realized the
connection between the text box, but the Firefox homepage sure slapped me in the
face with it every time!
very prominent => blocking aviary 1.1 ?
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 287367 has been marked as a duplicate of this bug. ***
WFM 20050319 trunk WinXP. Anyone else?
Still broken for me using a trunk build from 20050323 on Windows 2000.  (I also
tried a trunk build from 20050319, it wasn't working either.)
Odd. If I am using Firefox over VNC, it doesn't happen. When I'm there at the
screen in person it does.
Two ways I've found to work around this (for the current session anyway) seem to be:

1) Click "View", "Toolbars", "Customize", move your address bar into your menu
toolbar, and the pulldown starts to work.

2) Click "View", "Toolbars", "Customize", "Done", reload page, click "View",
"Toolbars", "Customize", "Done", reload page, and the pulldown starts to work.

As stated before, the problem can also be avoided by making sure your cursor
isn't in a <input type="text"> field when you click on the pulldown.
*** Bug 289880 has been marked as a duplicate of this bug. ***
Confirmed here.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
(In reply to comment #16)
> Confirmed here.
> 
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Strange... I have another computer here with Firefox 1.04 where the problem
doesn't happen. The browser ID string is the same as above. This computer is an
older PC Chips 598LMR board with an AMD K6-2 processor running at 500 Mhz. The
other computer is a newer board based on the Intel 865 chipset. Both computers
are running Windows 98 SE.
(In reply to comment #17)
> (In reply to comment #16)
> > Confirmed here.
> > 
> > Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
> 
> Strange... I have another computer here with Firefox 1.04 where the problem
> doesn't happen. The browser ID string is the same as above. This computer is an
> older PC Chips 598LMR board with an AMD K6-2 processor running at 500 Mhz. The
> other computer is a newer board based on the Intel 865 chipset. Both computers
> are running Windows 98 SE.

OK, I take that back, the problem exists on both machines.
Also, it remains a problem in Deer Park.
Assignee: bugs → nobody
QA Contact: bugzilla → toolbars
*** Bug 295056 has been marked as a duplicate of this bug. ***
*** Bug 316987 has been marked as a duplicate of this bug. ***
Summary: address bar drop down history fails to open when focus comes from a text box / field → Location Bar doesn't stay open (collapses) when clicking on arrow the first time
*** Bug 318025 has been marked as a duplicate of this bug. ***
Component: Toolbars → Location Bar and Autocomplete
OS: Windows XP → All
QA Contact: toolbars → location.bar
Hardware: PC → All
Version: unspecified → Trunk
Component: Location Bar and Autocomplete → Autocomplete
Priority: -- → P1
Product: Firefox → Toolkit
QA Contact: location.bar → autocomplete
Target Milestone: --- → mozilla1.9alpha1
Attached patch Patch rv1.0Splinter Review
On mouse down event on the dropdown button, the autocomplete input widget doesn't have focus. So, on the event, we are opening the dropdown list, but the focus event that is occured after mouse down event is re-attach autocomplete controller. In this time autocomplete controller kills old popuped window.

We need to ensure the widget having focus before opening the dropdown list.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #207054 - Flags: first-review?(mconnor)
Whiteboard: [needs review mconnor]
*** Bug 323478 has been marked as a duplicate of this bug. ***
*** Bug 325542 has been marked as a duplicate of this bug. ***
*** Bug 325713 has been marked as a duplicate of this bug. ***
I have no idea how long ago I found this error/bug, and I was far from the first to report it I found out.  Many revisions to Firefox have been released since the first bug report yet nothing has changed.  I'm forced to conclude one of the following: that no one cares, that no one can figure out how to change it, or that it is such a low priority that basically isn't of consequence to those capable of fixing the bug.

So I give up and have no further interest in the matter, as it appears neither do those in a posotion to repair it.
*** Bug 329288 has been marked as a duplicate of this bug. ***
Since this doesn't have a blocking flag, adding mconnor to cc list and leaving this comment so he gets bugmail about it and puts it on his radar.  

I would imagine this should block something, but I'll leave the nomination to someone more in the know about what should block what.
Attachment #207054 - Flags: first-review?(mconnor)
Attachment #207054 - Flags: first-review+
Attachment #207054 - Flags: approval-branch-1.8.1+
checked-in to trunk and 1.8 branch.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [needs review mconnor]
Target Milestone: mozilla1.9alpha1 → mozilla1.8.1beta1
Comment on attachment 223708 [details] [diff] [review]
Patch for check-in(Trunk)

+          // Eusure this having focus.

Should either fix the two problems with this comment or remove it.  Looking at the two lines before, it's pretty obvious what the code does.
*** Bug 346418 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.