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-??
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.
Linux works fine also. Maybe bug 326469 caused this?
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.
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.
Correction: event.screenY and screenX are always zero in the autocomplete popup. They might still work in other popups.
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.)
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.
(Ignore the unfinished sentence in comment 7, sorry. I wish spellcheck could catch that. ;-) )
*** Bug 364069 has been marked as a duplicate of this bug. ***
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... :(
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).
is this already fixed or does it still occur in firefox trunk builds?
This now WFM: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a4pre) Gecko/20070326 Minefield/3.0a4pre
WFM, Firefox 2007-03-27 on MacOSX WFM, SeaMonkey 2007-03-27 on MacOSX -> WORKSFORME