Clicking in the location bar history drop down menu does not load the url

VERIFIED WORKSFORME

Status

()

Core
Widget: Cocoa
VERIFIED WORKSFORME
11 years ago
11 years ago

People

(Reporter: mats, Assigned: Josh Aas)

Tracking

({pp, regression})

Trunk
PowerPC
Mac OS X
pp, regression
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
Clicking in the location bar history drop down menu does not load the url 

STEPS TO REPRODUCE
(0. visit some sites so you have something in the menu)
1. Start Firefox
2. left-click on the down-arrow to the right in the location bar
3. left-click on one of the menu items

ACTUAL RESULTS
It appears to start loading the URL (throbber starts spinning), but after
a second or so it stops and the new URL was not loaded.

EXPECTED RESULTS
The selected URL should be loaded

PLATFORMS AND BUILDS TESTED
Bug occurs in Firefox trunk 2006-09-29 on MacOSX
Bug occurs in Firefox trunk 2006-10-05 on MacOSX
Bug does NOT occur in Firefox trunk 2006-09-28-08 on MacOSX
Bug does NOT occur in SeaMonkey 2006-10-05 on MacOSX

i.e. regression range: 2006-09-28-08 -- 2006-09-29-??
(Reporter)

Comment 1

11 years ago
Selecting a menu item using the keyboard works fine though.
Works for me using a windows trunk build from today. Doesn't look to me like anything in that checkin window would cause this.
(Reporter)

Comment 3

11 years ago
Linux works fine also. Maybe bug 326469 caused this?
Keywords: pp
(Reporter)

Updated

11 years ago
Flags: blocking1.9?

Comment 4

11 years ago
I see this too, with both the "recently typed URLs" dropdown and autocomplete.  It seems to be loading whatever is in the address bar (the current URL, or the few characters you typed to invoke autocomplete) instead of the URL you clicked.

Updated

11 years ago
Blocks: 326469

Comment 5

11 years ago
I've found the cause of this bug and why my patch in bug 339447 is not (fully) working. In autocomplete.xml's method getHoverCell() we use the mouse event's screenX and screenY properties, to determine what cell was hit.

However, on mac event.screenX and event.screenY are always 0 in popups. I've been debugging this hard today, but no solution yet. 

Fixing that problem will also make it possible to fix bug 339447 at the same time.

Comment 6

11 years ago
Correction: event.screenY and screenX are always zero in the autocomplete popup. They might still work in other popups.

Updated

11 years ago
Assignee: nobody → hwaara

Comment 7

11 years ago
So after some CVS blame investigation, seems like the "mouse events not working in popups" was already known when checking in the patch in bug 332917.

The problem is that in cocoa widgets, just before sending off the event, we always change the widget parameter of the nsEvent to be the main window (rather than the popup window's widget).  Gecko relies on being able to use the 

Then when autocomplete.xml wants to know the mouse event's coords, it asks for the event's screenX/screenY. Our event code forwards the request to some other gecko code. This code is now doing hit-testing to get the view/widget at the specified point and boom, now things go wrong.

In essence, for mouse events, we should just send off the popup window's widget in the event. (Sorry for the long post, I need to learn into how much detail I should go.)

Comment 8

11 years ago
Created attachment 248738 [details] [diff] [review]
Proposed fix

Here's the proposed fix, outlined in the previous comment.

Send mouse events to the widget corresponding to the popup view.

We might realize that more events need to be forwarded to it later on, so I added a comment about that.
Attachment #248738 - Flags: review?(joshmoz)

Comment 9

11 years ago
(Ignore the unfinished sentence in comment 7, sorry. I wish spellcheck could catch that. ;-) )

Updated

11 years ago
Blocks: 339447

Comment 10

11 years ago
*** Bug 364069 has been marked as a duplicate of this bug. ***

Comment 11

11 years ago
Comment on attachment 248738 [details] [diff] [review]
Proposed fix

This patch fixes autocomplete menus, but instead regresses other XUL menus (folders on the bookmarks toolbars) to not work. (Akin to bug 356528)

More debugging apparently needed... :(
Attachment #248738 - Flags: review?(joshmoz)
(Reporter)

Updated

11 years ago
Blocks: 367581

Comment 12

11 years ago
With Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.9a2pre) Gecko/20070119 SeaMonkey/1.5a this problem is not reproducable, but the auto-completition menu does not work there (see bug #367581).

Comment 13

11 years ago
not firefox
Assignee: hwaara → joshmoz
Component: Location Bar and Autocomplete → Widget: Cocoa
Product: Firefox → Core
QA Contact: location.bar → cocoa

Updated

11 years ago
Flags: blocking1.9?

Comment 14

11 years ago
is this already fixed or does it still occur in firefox trunk builds?

Comment 15

11 years ago
This now WFM:  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070326 Minefield/3.0a4pre
(Reporter)

Comment 16

11 years ago
WFM, Firefox 2007-03-27 on MacOSX
WFM, SeaMonkey 2007-03-27 on MacOSX

-> WORKSFORME
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Updated

11 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.