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

Status: VERIFIED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Mats Palmgren (inactive)]

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

Comment 1

[Mats Palmgren (inactive)]

Selecting a menu item using the keyboard works fine though.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Works for me using a windows trunk build from today. Doesn't look to me like anything in that checkin window would cause this.

Comment 3

[Mats Palmgren (inactive)]

Linux works fine also. Maybe bug 326469 caused this?

Comment 4

[Jesse Ruderman]

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.

Comment 5

[Håkan Waara]

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

[Håkan Waara]

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

Comment 7

[Håkan Waara]

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

[Håkan Waara]

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

Comment 9

[Håkan Waara]

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

Comment 10

[Hiro]

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

Comment 11

[Håkan Waara]

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

Comment 12

[Georg Maaß]

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

[Andrew Schultz]

not firefox

Comment 14

[Stuart Parmenter]

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

Comment 15

[froodian (Ian Leue)]

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

Comment 16

[Mats Palmgren (inactive)]

WFM, Firefox 2007-03-27 on MacOSX
WFM, SeaMonkey 2007-03-27 on MacOSX

-> WORKSFORME