Last Comment Bug 404314 - when I click on a menu instead of click and hold it randomly selects a menu item and activates it
: when I click on a menu instead of click and hold it randomly selects a menu i...
Status: RESOLVED FIXED
[fixed by bug 406646]
: dogfood, regression
Product: Core
Classification: Components
Component: XUL (show other bugs)
: Trunk
: All All
: P2 normal with 31 votes (vote)
: mozilla1.9.2a1
Assigned To: Neil Deakin (away until Oct 3)
:
:
Mentors:
: 403540 414632 419861 433658 448012 459665 478153 480879 485574 495985 (view as bug list)
Depends on: 312225 406646
Blocks: 422021 488381
  Show dependency treegraph
 
Reported: 2007-11-19 00:38 PST by Daniel Brooks [:db48x]
Modified: 2015-06-10 13:34 PDT (History)
66 users (show)
mbeltzner: blocking1.9.1-
roc: wanted1.9.1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
workaround for phantom double-clicks (9.01 KB, patch)
2008-04-10 21:59 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
nsMenuPopupFrame.cpp assertion (42.27 KB, text/plain)
2008-11-30 16:48 PST, Alexander Sack
no flags Details
nsCSSFrameConstructor.cpp stack (54.58 KB, text/plain)
2008-11-30 16:49 PST, Alexander Sack
no flags Details
fix assertion and issue from comment 120 [checked in (comment 139)] (762 bytes, patch)
2008-12-17 08:28 PST, Neil Deakin (away until Oct 3)
roc: review+
roc: superreview+
Details | Diff | Splinter Review
(no clue) lazy menugenerated attempt (4.36 KB, patch)
2008-12-20 09:15 PST, Alexander Sack
no flags Details | Diff | Splinter Review
bad hack to try make this happen more frequently (733 bytes, patch)
2009-01-27 08:21 PST, Marco Bonardo [::mak]
no flags Details | Diff | Splinter Review

Description Daniel Brooks [:db48x] 2007-11-19 00:38:51 PST
This has mostly happened when I open the context menu, but it also happened with a bookmark folder the other day. It seems that it may only happen when the computer is a bit busy, but I really haven't noticed any pattern.
Comment 1 Reed Loden [:reed] (use needinfo?) 2007-11-19 00:40:03 PST
I can definitely confirm this. both bz and roc see the same thing, too.
Comment 2 Daniel Brooks [:db48x] 2007-11-19 00:40:31 PST
Oh, and I haven't seen this in the windows nightlies, but that may only be because I use them so much less frequently.
Comment 3 Reed Loden [:reed] (use needinfo?) 2007-12-08 01:12:22 PST
This drives me insane and kills my productivity, as I continue to get random bookmarks added because Firefox randomly picks "Bookmark this page" from the context menu. :/
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-12-17 19:18:49 PST
This bug is really bad but I don't know how to reproduce it either, or even start working on it. I see it on Mac. Raising priority. We need steps to reproduce. Neil, any ideas what could be the problem or how we could even start looking at it?
Comment 5 Neil Deakin (away until Oct 3) 2007-12-18 07:24:00 PST
If a menu happens to appear positioned so that the mouse is over an item when it appears, the mouseup event gets fired at the menu and executes the command.

It shouldn't be happening with context menus though as they should always be positioned 2 pixels away from the mouse.
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2007-12-18 16:50:12 PST
For me, two-finger click can trigger the bug, but ctrl-click never does.
Comment 7 Neil Deakin (away until Oct 3) 2007-12-20 10:53:46 PST
I can't reproduce this bug in any way, so I can't really comment on what's wrong.
Comment 8 Caio Tiago Oliveira (asrail) 2007-12-31 14:04:26 PST
That most likely happens with me with links in Chatzilla.

I think that when the computer is under high load, you move the mouse before the context appearing, then you already have released the mouse and it thinks you want the old mac way of using menus.

Or the menu opens sometimes under the mouse and the item is selected on release.

See:
bug 312225 too.


Comment 9 Reed Loden [:reed] (use needinfo?) 2007-12-31 14:09:03 PST
(In reply to comment #8)
> I think that when the computer is under high load, you move the mouse before
> the context appearing, then you already have released the mouse and it thinks
> you want the old mac way of using menus.
> 
> Or the menu opens sometimes under the mouse and the item is selected on
> release.

Neither of the above things are what I see... What happens to me is when I right click an option and not move my mouse at all, it will randomly select a menu item.
Comment 10 Neil Deakin (away until Oct 3) 2007-12-31 14:24:19 PST
> Neither of the above things are what I see... What happens to me is when I
> right click an option 

What is 'an option'?

> and not move my mouse at all, it will randomly select a menu item.

Where does the menu appear? Does it select a menuitem not under the cursor? Does any item appear highlighted, even briefly? Does repeating without moving the mouse select the same menuitem, or do you really mean 'randomly select'?
 
Comment 11 Reed Loden [:reed] (use needinfo?) 2007-12-31 14:33:22 PST
(In reply to comment #10)
> > Neither of the above things are what I see... What happens to me is when I
> > right click an option 
> 
> What is 'an option'?

Sorry, I meant a link.

> > and not move my mouse at all, it will randomly select a menu item.
> 
> Where does the menu appear? Does it select a menuitem not under the cursor?
> Does any item appear highlighted, even briefly? Does repeating without moving
> the mouse select the same menuitem, or do you really mean 'randomly select'?

The menu never appears. It just does the random action without displaying a menu at all. For example, this last time it showed me the properties window for the link. I'm not moving the mouse when I right click, so I think it's pretty random for which option gets selected. I do hit "open in new tab", "bookmark this link", and "properties" (all at different parts of the menu) more often than the others, I guess... I still don't have good STR for this on Linux. It just happens seemingly randomly when I right click a link, but it happens probably at least 10-25% of the time, causing a true annoyance.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2007-12-31 14:49:22 PST
Comment 11 exactly describes what I'm seeing on Linux, though I mostly seem to hit "open in new tab" and "bookmark this link".  Every few days I have to go and delete the 20-30 random bookmarks that have piled up in that time.
Comment 13 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-01-01 00:52:20 PST
Ditto. When this happens to me I'm definitely not moving the mouse at all.
Comment 14 jag (Peter Annema) 2008-01-13 10:52:59 PST
Same here as Reed and bz. On Intel Mac. It's sort-of like the "are you feeling lucky?" for context menu, except it's not necessarily picking the top hit. While I seem to get "open in new tab" most of the time, I'll also get "Save Link Target As ...". Don't really remember hitting any of the others.

Ctrl+click (to bring up the context menu on the Mac) seems to be immune.
Comment 15 Jakub 'Livio' Rusinek 2008-01-29 12:37:27 PST
*** Bug 414632 has been marked as a duplicate of this bug. ***
Comment 16 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-02-27 19:04:57 PST
I haven't seen this for a while. Are people still seeing it?
Comment 17 Reed Loden [:reed] (use needinfo?) 2008-02-27 19:09:22 PST
(In reply to comment #16)
> I haven't seen this for a while. Are people still seeing it?

Yes, all the time. It's extremely painful when I'm committing patches, as I right-click to copy the attachment URL.
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-02-27 19:16:36 PST
I wonder if I'm not seeing it anymore because the Mac build got faster.
Comment 19 Jakub 'Livio' Rusinek 2008-02-27 21:44:00 PST
I see it all the time too.
Comment 20 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-02-28 19:43:11 PST
This should still block but I have no traction since I can't reproduce reliably. Maybe I need to use a Linux build for a while.
Comment 21 Jakub 'Livio' Rusinek 2008-02-28 21:39:30 PST
Of course you need.

This bug is about LINUX, so you need.
Comment 22 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-02-29 05:20:55 PST
I *was* seeing it on Mac quite a lot.
Comment 23 Ty Williams 2008-03-11 14:20:45 PDT
This seems very similar to the bug I just filed for the Mac https://bugzilla.mozilla.org/show_bug.cgi?id=422021

Summary: If you two-finger-tap as right-click, you will often get the random-menu-item execution rather than the context menu. If you ctrl-click as right click you almost always get the context menu.

This bug was not present in Ff 2.* and is present in the Ff 3.0 betas.
Comment 24 Jesse Ruderman 2008-04-07 14:43:52 PDT
roc, have you been able to reproduce this bug on Linux?
Comment 25 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-07 15:19:54 PDT
On Linux, I'm seeing something different to what I saw on Mac. Right-click seems to sometimes just not do anything. Maybe the difference is because on Linux I seems to get a different context menu to Mac...

But thanks for the heads-up. I probably can debug this now.
Comment 26 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 01:53:26 PDT
Okay, we get all the way down to nsXULPopupManager::FirePopupShowingEvent, at least, but the menu just doesn't pop up. Still looking.

I actually have a feeling that this failure to pop up the menu on Linux might be a different problem to the problems described in comments #3 and #4, at least. The menu doesn't pop up but we don't seem to ever execute any commands. I was definitely seeing random commands being executed on Mac. Hopefully that bug just went away by itself...
Comment 27 Reed Loden [:reed] (use needinfo?) 2008-04-08 01:59:04 PDT
I'm still seeing random commands being executed on Linux as of a current nightly.
Comment 28 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 01:59:48 PDT
Okay, it seems that right after we show the popup we're immediately getting an event that causes us to hide it:

#0  nsMenuPopupFrame::SetPopupState (this=0x8a210f4, aPopupState=ePopupHiding)
    at /home/roc/shared/mozilla-trunk/layout/xul/base/src/nsMenuPopupFrame.h:131
#1  0xb5351e8e in nsXULPopupManager::HidePopup (this=0x865a830, 
    aPopup=0x89dfa30, aHideChain=1, aDeselectMenu=1, aAsynchronous=0)
    at /home/roc/shared/mozilla-trunk/layout/xul/base/src/nsXULPopupManager.cpp:649
#2  0xb5352776 in nsXULPopupManager::Rollup (this=0x865a830, aLastRolledUp=0x0)
    at /home/roc/shared/mozilla-trunk/layout/xul/base/src/nsXULPopupManager.cpp:187
#3  0xb62f46c6 in check_for_rollup (aWindow=0x8d90c08, aMouseX=664, 
    aMouseY=244, aIsWheel=0)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4214
#4  0xb62f5900 in nsWindow::OnButtonPressEvent (this=0x8eaaa60, 
    aWidget=0x8d3ca58, aEvent=0x813a8b8)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:2095
#5  0xb62f5c58 in button_press_event_cb (widget=0x8d3ca58, event=0x813a8b8)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4636
#6  0xb7a3b1b0 in gtk_marshal_BOOLEAN__VOID ()
   from /opt/gnome/lib/libgtk-x11-2.0.so.0
#7  0xb752ec0b in g_closure_invoke () from /opt/gnome/lib/libgobject-2.0.so.0
#8  0xb753fd3d in g_signal_override_class_closure ()
   from /opt/gnome/lib/libgobject-2.0.so.0
#9  0xb754100f in g_signal_emit_valist ()
   from /opt/gnome/lib/libgobject-2.0.so.0
Comment 29 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 02:00:16 PDT
OK, it's quite possible that the same cause is causing both bugs.
Comment 30 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 02:27:15 PDT
OK, when I right-click (actually two-finger-tap, I sure hope *that* doesn't make a difference!) I sometimes get one button press event and the menu pops up.

When the menu doesn't come up, it's because we got a double-click sequence from GTK!

Breakpoint 10, button_press_event_cb (widget=0x8665808, event=0x813aae8)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4632
4632        nsWindow *window = GetFirstNSWindowForGDKWindow(event->window);
$62 = {type = GDK_BUTTON_PRESS, window = 0x8d90c08, send_event = 0 '\0', 
  time = 27489145, x = 139, y = 114, axes = 0x0, state = 0, button = 3, 
  device = 0x813c800, x_root = 563, y_root = 236}

Breakpoint 11, button_release_event_cb (widget=0x8d3ca58, event=0x8666908)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4645
4645        nsWindow *window = GetFirstNSWindowForGDKWindow(event->window);
$63 = {type = GDK_BUTTON_RELEASE, window = 0x8d90c08, send_event = 0 '\0', 
  time = 27489166, x = 139, y = 114, axes = 0x0, state = 1024, button = 3, 
  device = 0x813c800, x_root = 563, y_root = 236}

Breakpoint 10, button_press_event_cb (widget=0x8d3ca58, event=0x813ab38)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4632
4632        nsWindow *window = GetFirstNSWindowForGDKWindow(event->window);
$64 = {type = GDK_BUTTON_PRESS, window = 0x8d90c08, send_event = 0 '\0', 
  time = 27489166, x = 139, y = 114, axes = 0x0, state = 0, button = 3, 
  device = 0x813c800, x_root = 563, y_root = 236}

Breakpoint 10, button_press_event_cb (widget=0x8d3ca58, event=0x8666958)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4632
4632        nsWindow *window = GetFirstNSWindowForGDKWindow(event->window);
$65 = {type = GDK_2BUTTON_PRESS, window = 0x8d90c08, send_event = 0 '\0', 
  time = 27489166, x = 139, y = 114, axes = 0x0, state = 0, button = 3, 
  device = 0x813c800, x_root = 563, y_root = 236}

Breakpoint 11, button_release_event_cb (widget=0x8665808, event=0x813aa98)
    at /home/roc/shared/mozilla-trunk/widget/src/gtk2/nsWindow.cpp:4645
4645        nsWindow *window = GetFirstNSWindowForGDKWindow(event->window);
$66 = {type = GDK_BUTTON_RELEASE, window = 0x8d90c08, send_event = 0 '\0', 
  time = 27489166, x = 139, y = 114, axes = 0x0, state = 1024, button = 3, 
  device = 0x813c800, x_root = 563, y_root = 236}

The sequence is correct for a double-click, as documented here:
http://developer.gnome.org/doc/GGAD/sec-gdkevent.html

But I don't know why GTK thinks I'm double-clicking :-(. I can reproduce the problem with ctrl-click into my Linux VM, so I don't think it's two-finger-tap translation messing things up.

Interestingly I can reproduce the phantom double-click on left-click too.

Maybe this is just some kind of weird input problem? What kind of input devices are people who can see this problem using?
Comment 31 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 03:11:42 PDT
I actually see this in gedit as well.
Comment 32 Ty Williams 2008-04-08 09:36:33 PDT
Robert, two-finger-tapping vs actual right-click (by plugging in an external mouse with 2 buttons) vs ctrl-click are currently producing different contextual menu results at least on Mac. I've got a bug open about it.


Just brought it up since you said "actually two-finger-tap, I sure hope *that* doesn't
make a difference!" in #30.
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2008-04-08 09:40:46 PDT
I was using Ctrl-click on a MacBook when I was seeing this.  I haven't used the context menu there for a while (adapted to doing other things, since the context menu was so unreliable).
Comment 34 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-08 15:59:43 PDT
I'm not really sure what to do here. We could try to ignore double-clicks and triple-clicks that occur too soon after the first click, but that might interfere with alternative input mechanisms that can generate double-clicks directly (if there are any).

Does anyone else see this with other GTK apps? I'm pretty sure I see the same problem in gedit.
Comment 35 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-09 22:56:14 PDT
If you look closely at comment #30, it actually shows that the RELEASE event after the first press has *exactly the same timestamp* as the PRESS event for the second press. That is very odd and suggests that something is being synthesized for some reason.
Comment 36 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-09 23:09:37 PDT
OK, I fired up xev and got the following results for one of my two-finger-taps:

ButtonPress event, serial 26, synthetic NO, window 0x2a00001,
    root 0x3e, subw 0x0, time 32339400, (106,110), root:(672,141),
    state 0x0, button 3, same_screen YES

ButtonRelease event, serial 26, synthetic NO, window 0x2a00001,
    root 0x3e, subw 0x0, time 32339407, (106,110), root:(672,141),
    state 0x400, button 3, same_screen YES

ButtonPress event, serial 26, synthetic NO, window 0x2a00001,
    root 0x3e, subw 0x0, time 32339407, (106,110), root:(672,141),
    state 0x0, button 3, same_screen YES

ButtonRelease event, serial 26, synthetic NO, window 0x2a00001,
    root 0x3e, subw 0x0, time 32339407, (106,110), root:(672,141),
    state 0x400, button 3, same_screen YES

Note in particular how the last three events all have the same timestamp.

So the blame for the problem --- the problem I'm seeing, at least --- can be placed in the X server or above. In my case it could be an issue in VMWare or Mac OS X as well.

So whoever's seeing this bug --- please try gedit and/or xev and see if you can replicate the problem there.
Comment 37 Michael Ventnor 2008-04-10 01:21:11 PDT
Could this be a problem of the mouse driver? I use Synaptics touchpad driver on my Macbook Pro and I don't see this problem.
Comment 38 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-10 14:22:32 PDT
I'm using some VMWare emulation driver, "vmmouse", "ImPS/2 Generic Wheel Mouse".

For me, this is clearly not a Gecko bug, but I really need feedback from other people who see the problem before I can be sure that's true across the board.

In the meantime, I'll try to put together a workaround. The safest option would be to ignore press events with the same timestamp as a release event whose corresponding press event triggered a context menu.
Comment 39 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-10 14:24:26 PDT
A slightly less conservative option would be to drop the "triggered context menu" condition --- that would fix other phantom double-click issues.
Comment 40 Boris Zbarsky [:bz] (still a bit busy) 2008-04-10 19:32:43 PDT
For what it's worth, I was seeing this on my MacBook with the default touchpad stuff in OSX, and on Linux using the dumb-as-rocks PS/2 mouse driver for X and an actual right button on a 3-button mouse.
Comment 41 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-10 21:56:34 PDT
Okay, I've got a workaround patch for the phantom-double-click issue.

I'm also seeing bug 312225, where clicking in the bottom-right corner of the screen pops up the context menu with the mouse already over the bottom item, so releasing the button triggers the last command in the menu.

But it sounds like neither of these issues are what reed, bz, jag and others have been seeing. I really need someone who can reproduce this on demand to answer the questions here such as comment #36.

Another question is, if you can reproduce this on demand, try holding the right button down for a while before releasing --- what's the behaviour? Does the menu pop up? Is the mouse cursor over an item? Does the bug still occur?
Comment 42 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-10 21:59:05 PDT
Created attachment 315039 [details] [diff] [review]
workaround for phantom double-clicks

This is the workaround for the phantom double-clicks that I'm seeing. It would be interesting to know if this fixes problems for anyone else, although I'm not hopeful.

I'd be reluctant to take this patch if it only fixes issues for me, since something is clearly broken for all apps in my VM setup and it's hardly worth trying to work around that.
Comment 43 Boris Zbarsky [:bz] (still a bit busy) 2008-04-10 22:13:13 PDT
I don't have builds on hand that I could test with at the moment, but I did test the things you ask in comment 41 back when (though the issue was not reproducible on demand, just very common).  When I clicked and held, the context menu always popped up, and the mouse cursor was never over an item.
Comment 44 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-11 03:23:15 PDT
Ok. Did this bug ever trigger when you released the right button after holding it down for a while?
Comment 45 Boris Zbarsky [:bz] (still a bit busy) 2008-04-11 10:51:03 PDT
I don't think so, but I'm not sure I ever managed to click the right button, hold it without moving the mouse at all, then release...
Comment 46 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-11 14:46:27 PDT
Yeah, I guess that's hard with a mouse. It's easy with a trackpad.
Comment 47 Damon Sicore (:damons) 2008-04-18 15:37:03 PDT
Progress on this?
Comment 48 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-18 15:40:31 PDT
I don't think I can reproduce the bug as originally reported, and I haven't received much feedback after repeated requests. I suggest we take this off the blocker list.
Comment 49 Reed Loden [:reed] (use needinfo?) 2008-04-18 17:18:49 PDT
(In reply to comment #48)
> I don't think I can reproduce the bug as originally reported, and I haven't
> received much feedback after repeated requests. I suggest we take this off the
> blocker list.

I apologize for not responding to the feedback requests, but I'm in the middle of crunch time for school (projects, exams, etc.), so I haven't had much time on my hands at all to respond to all my bugmail. This issue is probably my top #1 or #2 issue that I personally hit on a very regular basis that causes major issues for me since the result is very random, so please do not take it off the blocker list.

http://ubuntuforums.org/showthread.php?t=725962 is a report on the Ubuntu Forums about this same issue. Maybe you could mention your questions there to see if that user can help you?
Comment 50 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-18 20:46:01 PDT
I thought someone could just post a link to this bug there, but never mind, I'll register and post there.
Comment 51 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-18 20:58:48 PDT
I guess someone did post a link to this bug there, about a month ago. Oh well. I posted my questions there, we'll see if anything happens.

If someone who can reproduce this bug and isn't crunched for time can get in touch with me on IRC, we can work together to try to locate the bug.
Comment 52 Michael Ventnor 2008-04-18 21:34:09 PDT
Aha, I can reproduce this now. It happens on my Macbook Pro touchpad when I right click to bring up a menu near the bottom-right corner of the screen, so that the menu appears above the cursor and slightly to the left.
Comment 53 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-18 23:00:42 PDT
That's bug 312225. From what people have been saying, this bug can happen even when the mouse and menu are nowhere near the bottom right.
Comment 54 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-18 23:04:48 PDT
Hmm, it might be worth fixing 312225 just in case it helps here. It would certainly make things a bit clearer. I'll make that wanted1.9+ ... I think Karl could reproduce it so I may be able to fix it with his help on Monday.
Comment 55 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-23 14:41:45 PDT
Okay, I just checked in a fix for bug 312225. It would be useful if anyone who thought they were seeing this bug could retest with tonight's nightly.

There's been no additional feedback in the last five days here or in the Ubuntu forum, so I can't really make the case that this should still be a release blocker. But I don't want to upset Reed so I'll refrain from dropping the axe just yet :-).
Comment 56 Ty Williams 2008-04-23 18:08:24 PDT
I'll give it a whirl as I'm still getting the problem in beta 5. At what time will the nightly get built?
Comment 57 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-23 18:52:20 PDT
This should have it:
http://ftp.mozilla.org/pub/mozilla.org/mozilla.org/firefox/tinderbox-builds/fx-linux-tbox-trunk/firefox-3.0pre.en-US.linux-i686.tar.bz2
Comment 58 Damon Sicore (:damons) 2008-04-24 12:13:33 PDT
I think we can fix this in a 1.9.0.x release.  Hard to reproduce.  Moving to 1.9.0.x.
Comment 59 Daniel Holbert [:dholbert] 2008-04-24 12:22:58 PDT
(In reply to comment #58)
> I think we can fix this in a 1.9.0.x release.

Yeah -- I don't think we should block on this, given that it seems to have a very low level of reproducibility, meaning that we wouldn't even be able to easily test whether we'd fixed it or not. :)  (FWIW, I'm running Ubuntu, and I've never been able to reproduce it.)

roc -- is your workaround still potentially valid?  If so, could someone who can reproduce the bug test out that patch to see if it fixes the problem for them?
Comment 60 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-24 14:01:32 PDT
I doubt my workaround patch is going to fix the problems people have been complaining about. It works around some bug in my VM/Linux install that breaks *all* apps. I agree this should be non-blocking.
Comment 61 Ty Williams 2008-04-24 14:04:13 PDT
You guys are aware this happens on the Mac build too, right? So it's not just the linux builds running in a VM.
Comment 62 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-24 22:46:55 PDT
I saw it on Mac for a while myself. Then I stopped seeing it and I haven't seen it for a couple of months now. It still happens on Mac for you?
Comment 63 Ty Williams 2008-04-24 22:50:58 PDT
Yeah, with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b1, I'm still seeing it every day. It ***ONLY*** happens if I use the trackpad tap for the click though. If I plug in a mouse, or if I use the actual button on the trackpad, it doesn't happen. However, even using the trackpad tap, it doesn't _always_ happen, just frequently enough to make it basically impossible to rely on.

Additionally, if I use trackpad tap as the click, selecting something like "Copy Link to Clipboard" looks visually like it works (proper behavior of the GUI), but the action isn't actually carried out (in this example, nothing is put in the clipboard). However, if I use an external mouse of the trackpad button, everything functions properly.
Comment 64 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-24 22:57:07 PDT
You mean the two-finger tap that simulates right-click? I always use that.

Your build is about a month old, maybe it got fixed after that on Mac? I dunno.

If you could come up with reliable steps to reproduce, that would be great. Otherwise we're dead in the water.
Comment 65 Ty Williams 2008-04-24 22:59:30 PDT
I mean both two-finger-tap to make right click and hold-ctrl-and-one-finger-tap as right click.

I'll grab a nightly and see what's up. Unfortunately, I don't have a specific way to trigger it, it's just that if I use it for 15 minutes, it'll go wrong at least a couple of times.
Comment 66 Ty Williams 2008-04-24 23:08:50 PDT
ok, testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042404 Firefox/3.0b1 now.
Comment 67 jag (Peter Annema) 2008-04-26 08:17:43 PDT
Didn't this bug start out as a Mac bug?

Anyway, it used to happen to me quite a bit (about 3 or 4 out of 10 times) but in the last few months I've only noticed it happen a few times. I have adjusted to use cmd+click to open a link in a new tab instead of using the context menu, so that's one reason, but I also suspect changes to the Mac widget code have reduced the occurrence of this problem.

I run SeaMonkey Mac trunk, btw.
Comment 68 Daniel Brooks [:db48x] 2008-04-26 13:10:45 PDT
No, I reported this problem on linux.
Comment 69 Ty Williams 2008-04-27 10:41:50 PDT
OK, testing on the 2008042404 nightly build shows the bug has mutated. The bug here appears to be resolved EXCEPT for inside of text-entry boxes. If you right-click within a text-entry box, the contextual menu 1) will appear wherever it feels like and 2) won't contain the contextually correct menu items.

Did whatever was done to fix this bug break something else? I'm going to start a new bug for the new problem. 
Comment 70 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-04-27 16:45:11 PDT
Daniel, reed, are you still seeing this on Linux?

Ty, thanks for the info. Please do report that as a separate bug. Please mention whether it happens only with trackpad-double-tap or whatever. And please mention if it's 100% reproducible and give steps that work reliably if you can!
Comment 71 Daniel Holbert [:dholbert] 2008-04-27 17:26:12 PDT
(In reply to comment #70)
> Daniel, reed, are you still seeing this on Linux?

(assuming that's directed to Daniel Brooks / db48x -- I never saw the bug on linux, per comment 59)
Comment 72 Reed Loden [:reed] (use needinfo?) 2008-04-27 18:17:42 PDT
(In reply to comment #70)
> Daniel, reed, are you still seeing this on Linux?

Yep, hit it at least twice yesterday. :(
Comment 73 Reed Loden [:reed] (use needinfo?) 2008-05-13 23:39:34 PDT
*** Bug 433658 has been marked as a duplicate of this bug. ***
Comment 74 Karl Tomlinson (:karlt) 2008-05-14 21:59:51 PDT
I saw something similar to this with FF2 after changing screen resolution with xrandr.  It seemed the menu was placed according to the resolution at the time Firefox was started.
Comment 75 fdebruin 2008-05-25 03:23:54 PDT
This bug seems pretty reproducible with the FF version (3 beta 5) that got installed with the new Ubuntu release on our Thinkpad.

It occurs almmost all the time (80% of the cases) when you open a context menu with right click and the menu is in the right bottom part of the screen. It also seems to happen when the menu is so large that it hits the bottom of the screen.

Frank
Comment 76 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-05-25 14:47:37 PDT
That is bug 312225 which is fixed on trunk.
Comment 77 None 2008-05-27 02:31:02 PDT
For what it's worth, I'm using Windows XP and this happens to me.

However, I was able to successfully reproduce it somewhat reliably using this
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/187313/comments/31
Comment 78 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-05-27 17:46:40 PDT
Interesting. I still can't reproduce this on any platform I have, though.

If someone can reproduce this on any platform with those steps --- or any other steps --- feel free to find me on irc.mozilla.org #developers ('roc') and I'll be more than willing to step through a debugging session to try to narrow down the problem.
Comment 79 Alexander Sack 2008-05-30 10:16:09 PDT
*** Bug 419861 has been marked as a duplicate of this bug. ***
Comment 80 J 2008-06-27 11:48:56 PDT
I've been following this on Launchpad, and it occurs with both my laptop's touchpad and usb mouse, and on my desktop.  Both are using a fully updated version of Ubuntu 8.04.  It seems to happen most often when it's a quick click; to keep the FF right-click context menu from randomly going to Bookmark or something, I need to hold the right-click down longer than usual in order to bring up the context menu and not get the random behavior.  It makes opening a link in a new tab a bit of a hassle.

Middle-click does not pose a problem. 
Comment 81 Daniel Holbert [:dholbert] 2008-06-27 12:01:52 PDT
Going back on Comment 59 / comment 71, I actually *have* now run into this bug very occasionally, though I have no suggestions for easy ways to reproduce it. (I'm on FF3 / Ubuntu 8.04)
Comment 82 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-06-27 16:54:20 PDT
I'm running on low on ideas. dholbert, do you feel like running Firefox in a VMWare Workstation 6 VM with recording on and when you eventually hit this bug, debugging it under replay?
Comment 83 Daniel Holbert [:dholbert] 2008-06-27 17:22:37 PDT
Sure, I can give that a shot.
Comment 84 Neil Deakin (away until Oct 3) 2008-07-25 17:49:16 PDT
*** Bug 448012 has been marked as a duplicate of this bug. ***
Comment 85 Bill 2008-07-26 18:01:46 PDT
This is bug is a killer for Firefox 3, and because of it I'm having to use Opera.

This computer is running Ubuntu, but it was also a problem on my XP machine when I last tried to run Firefox 3 on it (about a month ago).
Comment 86 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-07-26 19:02:35 PDT
Perhaps you could help us come up with reliable steps to reproduce.
Comment 87 Bill 2008-07-26 20:00:40 PDT
I haven't noticed anything that will reliably invoke it.

I generally work by opening new tabs, instead of successively visiting different addresses on the same tab.

An example would be to go to a page with links to several news stories, like a yahoo news page.  Attempt to open several of the pages which are of interest on that page by right-clicking a link, then selecting 'open link in new tab' from the right-click menu.  Proceed down the page, opening several new tabs in the background.

At some point, right-clicking will stop bringing up the right-click menu, & instead just execute the function of some random item from the right-click menu, such as 'bookmark this link' or 'open link in new window'.

The behavior can be stopped by going to another page, right-clicking anywhere on the page to bring up the right-click menu, then left-clicking at an empty space on that page to get rid of the menu, then navigate back to the page that had the problem.  It will then return to working normally (for a while).

Although the menu item which begins to be activated by right-clicking is random, it seems like that same item (whichever one starts, for instance 'bookmark this link') remains the right-click activated item when the bug occurs on that page.
Comment 88 Jakub 'Livio' Rusinek 2008-07-27 02:38:15 PDT
roc, right click some link in Firefox 3. Don't hold RMB, but only click. Frequently Firefox did what I didn't wanted.

For example blocked some image server and I don't know/I can't revert that. Glorious, don't you think?
Comment 89 Praveen Garlapati 2008-07-28 04:34:13 PDT
I definitely see this issue with right click in Firefox. I always had this issue even in FF 2.0

The sequence goes somewhat like this:

1. I try to right click on a link
2. Before the actual right click menu is shown an option like bookmark or new tab or new window is chosen automatically and performed.

While it is not reproducible reliably it can be easily seen when doing the right click repeatedly/fastly on links.

Let me know if I can help someway to debug this.
Comment 90 Daniel Holbert [:dholbert] 2008-07-28 07:01:25 PDT
Bill, Jakub, Praveen:  Could you guys post how fast your CPU is & how much memory you have?  I've gotten the impression that this is easier to reproduce on slower machines, so I'm curious if your experiences support that theory.
Comment 91 Jakub 'Livio' Rusinek 2008-07-28 08:04:21 PDT
768MB @ 1,6Ghz
Comment 92 Praveen Garlapati 2008-07-28 08:24:21 PDT
Mine is a Lenovo T60 Laptop

Processor: 2.0GHz Core Duo
Memory: 1 GB
Comment 93 Aaron C. de Bruyn 2008-07-28 12:35:03 PDT
This happens to me under Ubuntu 8.04 on a Compaq Presario 2100 w/ 2.1 GHz AMD Athlon and 1 GB memory, although it rarely happens after a fresh start.  It's usually after I've been surfing around for a few hours/days and I'm out of memory and starting to swap.  Firefox is usually up to ~30%-40% memory usage.
Comment 94 Joakim Asplund 2008-08-08 09:43:51 PDT
(In reply to comment #5)
> If a menu happens to appear positioned so that the mouse is over an item when
> it appears, the mouseup event gets fired at the menu and executes the command.
> 
> It shouldn't be happening with context menus though as they should always be
> positioned 2 pixels away from the mouse.
> 

But this still might not be enough, as with some pointing devices your hand and thus the mouse cursor might move a bit when pressing the mouse button. In the Windows version of FF(and all other Windows programs) this is not a problem as the context menu is shown on mouse up, not mouse down. 

I must say though that showing the menu on mouse down is pretty nice when you get used to having to do it that way. I miss it a lot when running Windows! 

It should be possible to solve the problem by introducing a short delay before the menu accepts mouseups for selecting menu items.

Does Firefox use Gtk for menus or does it use its own? If it uses Gtk then this should probably done in Gtk instead as this affects a lot of Gnome programs too.
Comment 95 Jakub 'Livio' Rusinek 2008-08-08 09:46:02 PDT
GTK draws the menus. In GTK menu shows on mouse down, not mouse up - this is definitely Firefox issue. In GTK such bug doesn't appear.
Comment 96 Joakim Asplund 2008-08-08 10:20:35 PDT
I've had it happen in Nautilus too... Just try holding the click a little too long and move the mouse at the same time (which will happen by itself on some pointing devices) and you have just done something you didn't intend to do.
Comment 97 Daniel Holbert [:dholbert] 2008-09-24 17:28:01 PDT
(In reply to comment #96)
> I've had it happen in Nautilus too... Just try holding the click a little too
> long and move the mouse at the same time (which will happen by itself on some
> pointing devices) and you have just done something you didn't intend to do.

I've been suspicious that this sort of thing (cursor movement _during_ the right-click) was causing this bug, but now I think there's more going on here.

I just now reproduced this bug, with the context-menu-item at the _very opposite end of the context menu_ being auto-selected.  I don't think I could've selected an entry so far away with an accidental small cursor movement.  (FWIW, the cursor also looked pretty much motionless at the time -- I was intentionally trying to keep it in a fixed position.)
Comment 98 Bill 2008-09-25 04:23:20 PDT
It definitely has nothing to do with cursor movement.

Once the behavior has begun, I have positioned the cursor over an item, let go of the mouse, pressed down the right mouse button with a finger, and still can get a random action from the right-click menu.

It does not 'hang' on one particular item; subsequent clicks can produce other random actions from the right-click menu.

It can for a while be 'reset' to produce the right-click menu instead of a random action once it has begun by positioning the cursor in some non-active space on the page (with no text, no links, etc.), and right-clicking.  Ths brings up the basic web page right click menu with only Reload, Bookmark etc.; then hit the Esc button or left-click in another non-active space to dismiss the menu.  Right-clicking on an active item will then bring up the right-click menu like it's supposed to (for a while).
Comment 99 None 2008-10-08 22:52:22 PDT
I've just found that Firefox doesn't seem to have this bug on my secondary monitor. Just my primary one. What it does consistently do however, is show the context menu on the right side of the window, or monitor. I didn't get a chance to check because a bit more complicated when I was testing it out.

The extension Snap Links lets you draw a rectangle with a right-click to open links in new tabs. When I drew this rectangle, then right-clicked (when the extension glitched and didn't let the rectangle disappear), the context menu went back to appearing with the cursor even (as well as stopping the extension from working all together).
Possibly an unrelated bug though.


One more thing however. On the monitor where the context-menu-item bug occurs, the arrow is almost actually pointing inside the context menu. On the monitor where it doesn't occur, the pointer is pointing a couple of pixels away from the context menu.
Comment 100 Adam Olejniczak 2008-10-09 22:30:18 PDT
I'm seeing this bug as well. Linux FF 3.03

The easiest way to reproduce it for me is to run any google search, then right click on different links on different places. 
Usually in under 30 clicks or less then a minute the bug will occur. 

Now not confirmed but it seems sometimes that it matters how far to right or left on the actual link I click. Though that might be just my imagination. 

Anyway google search right click on links for minute and there bug should reveal itself.
Comment 101 Chris 2008-10-13 07:40:38 PDT
*** Bug 459665 has been marked as a duplicate of this bug. ***
Comment 102 Adam Olejniczak 2008-10-31 06:40:35 PDT
One more note. (Guess we are out of luck for so long finding this bug any notes help)

Sometimes it works this way that I get random actions when clicking on right side of the link.

When I then move mouse over beginning of the link and right click there I get proper menu displayed.
Comment 103 Yann MERRIEN 2008-11-05 17:33:04 PST
Is the Bug 406646 related to this one? (or duplicate?)
Comment 104 None 2008-11-21 06:44:38 PST
Okay, I've confirmed that the SnapLinks addon causes this problem. Uninstalling it from my PC stops the bug from occurring (and also stops the context menu from popping up directly under the pointer.) Installing it on a different computer also creates problems with the context menu (it moves the menu to the left of the screen no matter where you click).

I guess this means, for me at least, it's a bug with the extension and not FireFox. But I suppose if people who don't have this problem want to replicate the bug, they can try installing it.
https://addons.mozilla.org/en-US/firefox/addon/4336
Comment 105 None 2008-11-21 06:47:36 PST
P.S.
Just noticed there's a new entry for the new version of this extension- and there are comments relating to these similar bugs that it causes.
https://addons.mozilla.org/en-US/firefox/addon/8675
Comment 106 Bill 2008-11-21 06:54:51 PST
(In reply to comment #104)
> Okay, I've confirmed that the SnapLinks addon causes this problem.

I do not have SnapLinks installed & I get the random right-click context menu selection when I right-click on a link.
Comment 107 Jakub 'Livio' Rusinek 2008-11-21 06:56:21 PST
I don't have this extension but sometimes I see this problem.

Most probably it is caused by popup menu changing its position to fit on screen.
Comment 108 Yann MERRIEN 2008-11-21 06:56:45 PST
I don't use SnapLinks, but I have this bug. FYI I use only AdBlockPlus,
Rikaichan and Ubuntu addons.
Comment 109 Nate R 2008-11-21 13:25:38 PST
I'm also seeing this bug several times a day, and it's driving me nuts :-) My setup is:

Ubuntu 8.10 (upgraded from 8.04, upgraded from 7.10)
FF 3.04 
Only Add-on is Ubuntu Firefox Modifications 0.6
PC: 
- 2.6 GHz Pentium 4
- 1 GB RAM
- NVidia 7600 GFX card,running binary NVidia drivers
- Microsoft Wireless Laser Mouse 5000

It sounds like this bug is related to a timing issue somewhere in the stack (X, GTK, Xulrunner). My intuition says that Firefox is using GTK in a different way than most applications, and with certain input devices (tablets appear to be most common) some signals are fired incorrectly. I don't think running Firefox in a VM is a good way to test, because there are inherent timing differences in a virtualized input driver. Gotta love bugs that are hard to reproduce! It would be nice to know if someone at Mozilla is still looking at this, because I consider it a major bug. You just expect that a stock Firefox install under Ubuntu is going to work well, given the popularity of both projects and their strong open source communities. But I digress... Let me know if there is an easy way to log this on my computer.
Comment 110 Nate R 2008-11-21 13:35:37 PST
I forgot to add that some Ubuntu users have found a workaround by installing the Mouse Gestures Redox Add-on. Please see this bug report on launchpad for details - https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/187313. It's a very hack-ish workaround, but I'm curious why it would fix the problem.
Comment 111 Daniel Holbert [:dholbert] 2008-11-21 15:05:50 PST
(In reply to comment #110)
> some Ubuntu users have found a workaround by installing
> the Mouse Gestures Redox Add-on.
[snip]
> but I'm curious why it would fix the problem.

I think that add-on fixes the problem by changing Firefox to show context menus on mouse-*up* rather than on mouse-down.

Basically, it seems that this bug is caused via the following mechanism:
    (1) mouse-button-down opens menu
    (2) mouse-button-up activates a (random?) item in that menu
If you use that add-on, the mouse-button-up event can't activate an item in the menu, because the menu is only just appearing at that point.
Comment 112 Alexander Sack 2008-11-30 13:51:37 PST
I can reproduce this on ubuntu by left-clicking on the menu bar entries (just keep mouse down for just a very short time): start with File ... Edit, View, History ... eventually it will select a menu entry without the mouse being even in the proximity (e.g. i use a thinkpad pointer so the mouse is definitly not above the appearing popup). I tried rocs patch: attachment 315039 [details] [diff] [review] ... but that didnt help.
Comment 113 Alexander Sack 2008-11-30 13:55:43 PST
see this on 1.9.1 (and on --enabled-debug build) ... snapshot: Fri Nov 28 12:12:15 2008 +0100

Also i get the following debug output when i click and this happens

22:01 < asac> WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file 
/home/asac/Development/upstream/mozilla/mozilla-central/layout/base/nsCSSFrameConstructor.cpp, line 
              7773
Comment 114 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-11-30 14:59:54 PST
mmm, thanks!!! Setting a breakpoint there would be *very* interesting. dbaron, dholbert --- can you try that?
Comment 115 Alexander Sack 2008-11-30 16:45:54 PST
i also get another assertion ... but that happens everytime i click on a menubar item.

###!!! ASSERTION: Creating widget for MenuPopupFrame with children: '!mGeneratedChildren && !GetFirstChild(nsnull)', file /home/asac/Development/upstream/mozilla/mozilla-central/layout/xul/base/src/nsMenuPopupFrame.cpp, line 230

also, while trying longer it happened at least one time without the nsCSSFrameConstructor.cpp assertion. so all this might be independent.
Comment 116 Alexander Sack 2008-11-30 16:48:22 PST
Created attachment 350700 [details]
nsMenuPopupFrame.cpp assertion

backtrace and backtrace full with nsMenuPopupFrame:230
Comment 117 Alexander Sack 2008-11-30 16:49:28 PST
Created attachment 350701 [details]
nsCSSFrameConstructor.cpp stack

backtrace and backtrace full in nsCSSFrameConstructor.cpp:7773
Comment 118 Boris Zbarsky [:bz] (still a bit busy) 2008-12-03 19:06:36 PST
Neil, can you look at that nsMenuPopupFrame assert?
Comment 119 Neil Deakin (away until Oct 3) 2008-12-04 07:20:59 PST
Looks like you have a case where the popup has child frames created but no widget. That nsMenuPopupFrame.cpp assertion checks two cases, is mGeneratedChildren set or if there is a child frame?

Do you have an accessibility tool of some sort running? It looks as if nsMenuPopupFrame::AttributeChanged can cause the popup to open without ensuring the widget exists.
Comment 120 Donald Broatch 2008-12-06 00:42:12 PST
This bug appeared for me after updating Ubuntu to 8.10.

I don't have any problem reproducing the bug: the first time I start Firefox, clicking on 'Bookmarks' brings up the new bookmark dialogue- this happens at least once, sometimes twice or more (I cancel the new bookmark dialogue, click 'Bookmarks' again and see the dialogue instead of the drop down menu).

Similarly, clicking 'History' when Firefox has just started goes back a page (this just happened four times when I clicked the 'History' button), which is the first option in the drop down menu.

I haven't noticed the other drop-down menu items being affected, and the problem doesn't seem to arise again once the malfunctioning menus have been clicked and the inappropriate dialogues closed enough times for the error not to reappear.

The right click in Firefox also occasionally brings up the wrong dialogue- the AdBlock dialogue, which unlink the drop-down menus is the last item in the list.

Let me know if I can post any more information or logs: as I said, this bug is far from difficult to reproduce on my computer.
Comment 121 Yann MERRIEN 2008-12-08 05:31:57 PST
Am I the only one to have both this bug and Bug 406646 (bug when clicking Bookmarks) ?

Looks like they are related...

By the way I quickly tried the Mouse Gestures Redox Add-on, seems it doesn't work for me: when I right-click and release somewhere-else a bug occurs:
-if i release more on the left, it activates "Previous page"
-if i release more on the right, it activates "Next page"
-if i release more on the right+up, it activates "Maximize/Restore Window size"
-if i release more on the right+down, it activates "See page info"
And when I activate the orange line in the Addon options, Firefox crashes at first right-click use.

regards
Comment 122 Daniel Holbert [:dholbert] 2008-12-08 07:06:41 PST
(In reply to comment #121)
> By the way I quickly tried the Mouse Gestures Redox Add-on, seems it doesn't
> work for me: when I right-click and release somewhere-else a bug occurs:
> -if i release more on the left, it activates "Previous page"

That's not a bug -- those are the "Mouse Gestures" themselves. :)  To disable them, click Tools | Add-ons, and click "Preferences" on Mouse Gestures, and uncheck everything.  After that, the extension's only function is to change when context menus appear (& hence work around this bug), as described in comment 111.

> And when I activate the orange line in the Addon options, Firefox crashes at
> first right-click use.

If that's reproducible, please file a separate bug on that.
Comment 123 Yann MERRIEN 2008-12-09 07:45:06 PST
Thank you Daniel. I unchecked everything in the Addon preferences and it seems to be ok as a work-around.
And nevertheless I reproduced again the Bug 406646 ... I still think these 2 bugs behavior are similar... i hope i can find a work-around for the second one.
Comment 124 Dave Garrett 2008-12-11 10:31:51 PST
*** Bug 403540 has been marked as a duplicate of this bug. ***
Comment 125 Patrik Nilsson 2008-12-11 12:02:20 PST
I have two computers with ubuntu linux 8.10. Both with the same addons. My impresstion is that the bug appears when firefox hasn't got enough idle time (OnIdle).

From a project I have done on my own I know ubuntu (wxwwidget?) updates the menu at idle time and not when it is to displayed. Windows, on the other hand, updates the menus just before the menus are going to be shown.

One reason why I believe it is idle bug is that the bug almost newer occurs on the faster computer with a hard-disk, but frequently on the slower computer  with solid state hard-disk (acer aspire one 110).
Comment 126 Kris Bloe 2008-12-14 04:37:38 PST
Sometimes when I right click, the correct menu is shown, but the link I'm clicking on gets highlighted by a thick red bar round it.

I can only guess that the this bug's problem would have occurred if I'd have not clicked for so long.

p.s. I have firebug installed.
Comment 127 Donald Broatch 2008-12-16 22:36:41 PST
I've just noticed that the problem I describe above does not occur in my wife's account on the same computer. She has not set any bookmarks yet, so the problem in my account may have something to do with the number of bookmarks.

The History tab in my wife's account also works correctly. She doesn't use the computer as much as me, so her browsing history is fairly limited.
Comment 128 Alexander Sack 2008-12-17 04:40:26 PST
(In reply to comment #119)
> Looks like you have a case where the popup has child frames created but no
> widget. That nsMenuPopupFrame.cpp assertion checks two cases, is
> mGeneratedChildren set or if there is a child frame?
> 
> Do you have an accessibility tool of some sort running? It looks as if
> nsMenuPopupFrame::AttributeChanged can cause the popup to open without ensuring
> the widget exists.

Yes, we have "Assistive Technologies" (thats atk) enabled by default in ubuntu since intrepid. Most likely thats the reason why this happens more frequently here now.

Could it be that sending the "PopupOpened" (http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#609) even when childrens are added lazily (http://mxr.mozilla.org/mozilla-central/source/layout/xul/base/src/nsMenuPopupFrame.cpp#618) can cause unexpected things?
Comment 129 Salvatore Alongi 2008-12-17 04:42:06 PST
I have AMD64 3000+, 2GB RAM, ATI HD3650 and SAPPHIRE Axion with ATI200 chipset. 
I use Ubuntu 8.10 and firefox 3.0.4 (last version).

If I do right click on a link (e.g. links found via google) random actions occur (saving a bookmark, opening the link in a new window, activating addons, and so on). I think something of the "right click menu" activates.

NOTE: it doesn't happen in firefox 3.0.4 for MS Windows.
Comment 130 Alexander Sack 2008-12-17 04:45:05 PST
(In reply to comment #127)
> I've just noticed that the problem I describe above does not occur in my wife's
> account on the same computer. She has not set any bookmarks yet, so the problem
> in my account may have something to do with the number of bookmarks.
> 

Could you check wehther your wife's account has "Assistive Technologies" enabled (in GNOME: System -> Preferences -> Assistive Technologies -> Enable Assistive Tech.)? 

Same for you Salvatore, if you have it enabled, does disabling and restarting your system improve things for you?
Comment 131 Donald Broatch 2008-12-17 05:15:58 PST
I've disabled Assistive Technologies, and the problems with Bookmarks and History seem to have gone away, thanks.

I checked my wife's account and it was not enabled, so that possibly explains why I didn't see the problem there.
Comment 132 Neil Deakin (away until Oct 3) 2008-12-17 05:57:31 PST
(In reply to comment #131)
> I've disabled Assistive Technologies, and the problems with Bookmarks and
> History seem to have gone away, thanks.

That's great. Hopefully, I can make a patch to fix that. It just involves creating the right Widget in nsMenuPopupFrame::AttributeChanged.

It doesn't explain why some people are seeing it on Mac though which doesn't build accessibility support.
Comment 133 Alexander Sack 2008-12-17 07:49:49 PST
(In reply to comment #132)
> (In reply to comment #131)
> > I've disabled Assistive Technologies, and the problems with Bookmarks and
> > History seem to have gone away, thanks.
> 
> That's great. Hopefully, I can make a patch to fix that. It just involves
> creating the right Widget in nsMenuPopupFrame::AttributeChanged.
> 
> It doesn't explain why some people are seeing it on Mac though which doesn't
> build accessibility support.

How about what I asked above: we fire PopupOpened even though the childs are not yet initialized (e.g. lazy). see comment 128
Comment 134 Neil Deakin (away until Oct 3) 2008-12-17 08:28:28 PST
Created attachment 353441 [details] [diff] [review]
fix assertion and issue from comment 120 [checked in (comment 139)]

Don't think that this patch will fix the original bug report, but it should help on Linux.
Comment 135 Salvatore Alongi 2008-12-17 10:14:04 PST
(In reply to comment #129)
> (In reply to comment #127)
> > I've just noticed that the problem I describe above does not occur in my wife's
> > account on the same computer. She has not set any bookmarks yet, so the problem
> > in my account may have something to do with the number of bookmarks.
> > 
> 
> Could you check wehther your wife's account has "Assistive Technologies"
> enabled (in GNOME: System -> Preferences -> Assistive Technologies -> Enable
> Assistive Tech.)? 
> 
> Same for you Salvatore, if you have it enabled, does disabling and restarting
> your system improve things for you?

It was already disabled so I played a bit with this option (restarting my computer when enabling/disabling) but I got no luck: my right click on a link is still broken.
Comment 136 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-12-17 11:42:06 PST
Comment on attachment 353441 [details] [diff] [review]
fix assertion and issue from comment 120 [checked in (comment 139)]

Let's get this in ASAP and see if it helps everyone.
Comment 137 Nate R 2008-12-17 19:55:24 PST
The accessibility setting was already disabled on my computer as well. I have noticed that Firefox tends to be slow in general, so the idle bug theory seems spot on. I've noticed Firefox taking 75% CPU on my P4 2.6 GHz at times, which is clearly another bug - possibly related.
Comment 138 Benjamin Geer 2008-12-17 19:57:47 PST
Installing the Mouse Gestures Redox add-on, and disabling all the mouse gestures in its configuration settings, has been an effective work-around for me.
Comment 139 Neil Deakin (away until Oct 3) 2008-12-19 07:02:16 PST
Checked this patch in. It seems like the patch may instead be the one for bug 406646.
Comment 140 Alexander Sack 2008-12-20 08:31:16 PST
hmmm ... i tried it and while it makes the ASSERTION go away it doesnt fix the real issue ... i could still reproduce this when having accessibility enabled (similar behaviour as in #406646).
Comment 141 Alexander Sack 2008-12-20 09:15:53 PST
Created attachment 353977 [details] [diff] [review]
(no clue) lazy menugenerated attempt

this fixes it for me ... the patch sets menugenerated after the children are added. Anyway, as the patch title says, I have no real clue what happens on accessibility side now. Comments?
Comment 142 Patrik Nilsson 2008-12-20 10:57:20 PST
By turning of the "Assistive Technologies" on my acer aspire one the bug happens less frequently.
Comment 143 Patrik Nilsson 2008-12-20 11:23:09 PST
of==off:)

This is a description of the workaround I did (in my project) because the menu wasn't updated at instant.

I turned off the automatic updates of the menus and used the following code instead.

Example of a function checking if it is enabled.

void DMemoryFrame::OnEditPaste(wxCommandEvent& event)
{
    if(!GetEnabledMenuItem(event.GetId()))
        return;

    //........
}

Function to check if a menu item is enabled, by id.

bool DMemoryFrame::GetEnabledMenuItem(wxWindowID id)
{
    wxUpdateUIEvent event(id);
    event.SetEventObject( this );

    if( ProcessEvent(event))
    {
        if(event.GetSetEnabled())
            return event.GetEnabled();
    }

    return false;
}

The menu was still updated when it was opened by the user and to ensure all shortcuts keys (i.e. CTRL+V) worked I enabled the menu when it was closed. The user doesn't see this.

void DMemoryFrame::OnMenuClose(wxMenuEvent &event)
{
    wxMenuBar* menubar=GetMenuBar();
    if(menubar!=0)
    {
        if(menubar->IsKindOf(CLASSINFO(wxMenuBar)))
        {
            for(unsigned int i=0;i<menubar->GetMenuCount();i++)
            {
                wxMenu* menu=menubar->GetMenu(i);
                if(menu!=0)
                {
                    if(menu->IsKindOf(CLASSINFO(wxMenu)))
                    {
                        UpdateUI(menu);
                    }
                }
            }
        }
    }
}

The below function actually enabled a specific item. 

void DMemoryFrame::UpdateUI(wxMenu *menu)
{
    if(menu!=0)
    {
        wxMenuItemList::compatibility_iterator  node = menu->GetMenuItems().GetFirst();
        while( node!=0 )
        {
            if(!IsShownOnScreen() || wxPendingDelete.Member(this))
                break;

            wxMenuItem* item = node->GetData();
            if(item==0)
                break;

            if(!item->IsSeparator())
            {
                wxWindowID id = item->GetId();
                menu->Enable(id, true);

                if ( item->GetSubMenu() )
                    UpdateUI(item->GetSubMenu());
            }

            node = node->GetNext();
        }
    }
}
Comment 144 Alexander Sack 2008-12-20 11:43:36 PST
Patrick, can you try the patch i attached? btw, what are you trying to workaround with the code you pasted?
Comment 145 Neil Deakin (away until Oct 3) 2008-12-20 12:27:05 PST
(In reply to comment #140)
i could still reproduce this when having accessibility enabled

Does the bug not occur when accessibility is disabled? Do you mean this bug or bug 406646?

> Created an attachment (id=353977) [details]
> (no clue) lazy menugenerated attempt

Not sure what this patch is trying to do, apart from disabling accessibility support ;) The menugenerated attribute is set by the accessibility code to inform the popup to generate its contents immediately, as the accesibility api needs the content for proper element examination and traversal. The menugenerated attribute isn't used at all, nor ever set, if no accessibility use is present.

NOTE: if any popup has the menugenerated attribute set, it means that some application MUST be using the accessibility api to access it. (baring some extension that just sets this attribute arbitrarily)
Comment 146 Donald Broatch 2008-12-20 22:32:06 PST
Although disabling Assistive Technologies fixed the problem with Bookmarks and History for me, I still have an occasional problem with a right-click on highlighted text bringing up the last item on the menu (rather than the first with Bookmarks and History). For me this is the AdBlock dialogue.

Yesterday Firefox was highlighting a mis-spelled word in a comment form like this one, and right-clicking only brought up the AdBlock dialogue. This happened six or seven times.

when I tried right-clicking a link, behaviour was normal, and when I went back to the mis-spelled word, right clicking brought up the correction options.
Comment 147 IU 2008-12-20 23:29:43 PST
This problem happens on Windows builds also.  I have been experiencing it for at least a couple of months, but I didn't report it because I thought it was caused by an extension.
Comment 148 Patrik Nilsson 2008-12-21 01:38:51 PST
To Alexander Sack:

> Patrick, can you try the patch i attached?

Where can I get it in binary form? I could only find text (non compiled version):

> btw, what are you trying to workaround with the code you pasted?
To highlight the difference between windows and linux because it was said it only happens on linux. But this is not necessarily true anymore (comment 147)
Comment 149 Martijn Wargers [:mwargers] (not working for Mozilla) 2008-12-21 07:15:14 PST
If I understand comment 139 correctly, then the patch that should fix this bug is already in current trunk, so you could test these builds:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
..to check if this is truly fixed for you.
Comment 150 IU 2008-12-21 09:31:01 PST
This still happens.  The probability of encountering it is greater if you have certain extensions installed and have enabled menu theming.  For example: enable FlatStyle --> Use on Menus --> Standard in "CuteMenus Crystal SVG" extension.  You will have to restart for the change to take effect.  From here on, you will occasionally run into this bug.  Extension link: https://addons.mozilla.org/en-US/firefox/addon/1330

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081220 Minefield/3.2a1pre ID:20081220033344
Comment 151 IU 2009-01-08 15:12:01 PST
(In reply to comment #36)
> So the blame for the problem --- the problem I'm seeing, at least --- can be
> placed in the X server or above. In my case it could be an issue in VMWare or
> Mac OS X as well.
> 
> So whoever's seeing this bug --- please try gedit and/or xev and see if you can
> replicate the problem there.

This bug exists on the Windows XP platform as well (see Comment #147 and #150), so I highly doubt it.

*** Could someone please modify "Platform" to include Windows XP. ***

If it helps, I first encountered this bug when the "new tab" button on tabbar change landed.  I would recommend looking at the check-ins from that day.
Comment 152 Daniel Holbert [:dholbert] 2009-01-08 15:41:15 PST
(In reply to comment #151)
> This still happens.  The probability of encountering it is greater if you have
> certain extensions installed and have enabled menu theming.

IU: Have you ever encountered this bug *without* those extensions & customizations?  If not, I wonder if you might be hitting a different (though possibly related) bug in one of your extensions.

I say this because only two people here mention being able to reproduce this at all on Windows (you plus the author of comment 77), and two others have indicated they specifically *can't* reproduce this on Windows (comment 2, comment 129).  And given that most of our users are on Windows, I'd expect to have gotten a lot more reports of this bug on Windows if it were a problem there.
Comment 153 IU 2009-01-08 15:58:22 PST
(In reply to comment #152)
> IU: Have you ever encountered this bug *without* those extensions &
> customizations?  If not, I wonder if you might be hitting a different (though
> possibly related) bug in one of your extensions.
> 
> I say this because only two people here mention being able to reproduce this at
> all on Windows (you plus the author of comment 77), and two others have
> indicated they specifically *can't* reproduce this on Windows (comment 2,
> comment 129).  And given that most of our users are on Windows, I'd expect to
> have gotten a lot more reports of this bug on Windows if it were a problem
> there.

Yes I have reproduced without extensions, but it is very difficult and an extremely rare occurrence, which is why I am not surprised the other Windows users have difficulty reproducing it.  I recommended the extensions as a way of significantly increasing the probabilities of reproducibility.
Comment 154 Bill 2009-01-08 17:40:22 PST
> I say this because only two people here mention being able to reproduce this at
> all on Windows (you plus the author of comment 77)

You have miscounted, I am neither of those persons & reliably get the bug's behavior in both my Ubuntu & XP machines.  I am the author of comment 85.
Comment 155 Daniel Holbert [:dholbert] 2009-01-08 17:44:37 PST
Ah, my apologies.  I searched for the string "windows", so I missed your mention of "XP" in comment 85.

Setting OS --> All (indicating Linux + Windows + ...?) per comment 151, comment 153, comment 154.
Comment 156 Alex R. 2009-01-08 18:01:02 PST
(In reply to comment #151)
> If it helps, I first encountered this bug when the "new tab" button on tabbar
> change landed.  I would recommend looking at the check-ins from that day.

I experience it under 3.0.5 on Ubuntu 8.10, so I doubt that is the cause.
Comment 157 IU 2009-01-09 01:24:51 PST
Just a heads up:

I've found a regression point much later than the original filing of this bug: Builds prior to the September 6, 2008 Trunk build were okay.  September 6, 2008 and onward contained the bug.

I've also figured out a method to reproduce, but it will be a couple of days before I get them posted.  I may even create and post a link to a demonstration video.  All this was on Windows XP SP3.

Stay tuned...
Comment 158 Daniel Holbert [:dholbert] 2009-01-09 08:52:58 PST
(In reply to comment #157)
> I've found a regression point much later than the original filing of this bug:
[snip]
> All this was on Windows XP SP3.

IU: That's awesome!  However, given the later different regression date, you're likely hitting a different underlying issue than the original issue here (or a different manifestation of the same issue).

For simplicity's sake (and because this bug already has 150+ comments), could you file a new bug for the Windows issue, and post your demo video / instructions to reproduce / etc. on *that* bug?  You can post a link to that bug from this bug -- it'll just be better organizationally (& easier to follow) if we separate it out, I think.

(I'm returning this bug to OS = linux, with the intention of having the new bug cover the issue on Windows)
Comment 159 Daniel Andrei R. Garcia 2009-01-11 22:38:57 PST
To be sure I am on the correct page. this is the bug in firefox 3 that whenever I right click a link on a webpage - other unintended events happen like:

1. it opens evolution even if it wasn't a mailto link
2. it opens the link on a new tab
3. it opens the link on a new page
4. it opens the "save link as" dialog

Right? Right?
Comment 160 Dave Garrett 2009-01-11 23:13:13 PST
Daniel: The title of this bug is: "when I click on a menu instead of click and hold it randomly selects a menu item and activates it". In other words, opening of menus sometimes accidentally does one of the things in the menu, but this can be avoided by holding the button instead of clicking and releasing. The unintended events can be anything in said menu. For example, right-click on link accidentally opening in a new window. Please read the numerous comments above if you'd like more info.

Please don't post comments unless you have something new you'd like to add, thus emailing to the 45 other people CCed on this bug. ;)
Comment 161 Daniel Andrei R. Garcia 2009-01-12 01:25:36 PST
Ok noted dave. Thanks for confirming. By the way, it opens up evolution even if the link clicked isn't an email address.
Comment 162 Bill 2009-01-12 03:16:10 PST
(In reply to comment #159)
> To be sure I am on the correct page. this is the bug in firefox 3 that whenever
> I right click a link on a webpage - other unintended events happen like:
> 
> 1. it opens evolution even if it wasn't a mailto link
> 2. it opens the link on a new tab
> 3. it opens the link on a new page
> 4. it opens the "save link as" dialog
> 
> Right? Right?

Well, it used to be.  But someone merged this bug thread with the one Dave is describing below, which is apparently different.  The one I was originally reporting is the one you're describing:  right-clicking brings up a random item from the right-click menu.
Comment 163 IU 2009-01-12 21:12:24 PST
I have just finished filing Bug 473291 for my observation on Windows.  Don't get hung up on the CuteMenus - Crystal SVG extension requirement, as it is required to aid reproducibility.
Comment 164 Marco Bonardo [::mak] 2009-01-27 08:21:14 PST
Created attachment 359051 [details] [diff] [review]
bad hack to try make this happen more frequently

with this nonsense hack to slowdown popupshowing i can reproduce on Win with easy steps:
1. click on Bookmarks, the bookmarks menu open
2. close the menu clicking elsewhere
3. move the mouse upon Bookmarks so it's highlighted
4. click. sometimes nothing happens, sometimes the Bookmark This Page panel opens.
5. repeat 4
I don't know if the "first item" issue is the same as "random item issue" but fixing one could probably help fixing the other one.
Enn did not have luck reproducing with these steps on IRC, but i can reproduce, so if you have any patch to test i'm available.
Notice i hardly noticed this issue on 3.0.x but now on 3.1 i see it quite more often on Vista too.
Comment 165 IU 2009-01-27 08:37:25 PST
Using a build with the tabs drop-down menu (e.g. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008/09/2008-09-06-06-mozilla-central/firefox-3.1b1pre.en-US.win32.zip) with my steps in bug 473291, I was able to reliably reproduce this bug on the tabs drop-down menu.  You may want to also look at that.
Comment 166 Daniel Holbert [:dholbert] 2009-01-27 09:08:36 PST
(In reply to comment #164)
> I don't know if the "first item" issue is the same as "random item issue" 

Marco: The "first item" issue is bug 406646, so you may want to post your hack there instead.
Comment 167 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-01-27 18:23:56 PST
Neil, can you try Marco's patch and see if you can reproduce?
Comment 168 andrewhazel 2009-02-04 12:26:47 PST
ive had this problem for ages - months - got the new 3.06 and it just happened again -  i click on bookmarks normally when just starting browser so on google - then a box comes up and asks me if i want to book mark google.com - if i ignore it it automatically bookmarks google. hope someone can fix it - it dont happen every time i click bookmarks its quite random so i have no idea why this happens
Comment 169 Patrik Nilsson 2009-02-09 12:15:57 PST
It seems to me that the bug only appears when a page has recently been loaded (background tab or foreground) and the load process in some way destroys the menu information.

When I last time got the bug I right clicked on every link (google search) and it happened all the time. When I finally right clicked in an empty space (got the menu with back, forward, reload, ...) and then immediately right clicked on a link, the menu was updated and worked.
Comment 170 Patrik Nilsson 2009-02-10 11:44:06 PST
I have noscript addon installed. Today I got the same random pick when I chose its icon with left mouse button. 

Can it be that the menu class itself sometimes during initiation gets a signal that fires the menu item that currently is added? Can it be that page loading mechanism not always resets its state and fires OnRightDown()/OnLeftDown() until it get reinitiated?

Just speculations, but hopefully helpful...
Comment 171 Patrik Nilsson 2009-02-10 11:49:19 PST
Bookmark menu is reinitiated every time it is to be shown; the bookmarks are added to the menu. The other ones are more 'static'.
Comment 172 Robert Wiblin 2009-02-11 04:03:11 PST
Still observed on Ubuntu 8.10 using Firefox 3.1b2.
Using Dell Inspiron 6000, 1gb of RAM, 1.7ghz, using laptop touchpad.
Comment 173 None 2009-02-11 04:57:28 PST
I've mentioned this before, but to reiterate- When this bug was occuring, I noticed the mouse pointer (the tip anyway) was exactly on the edge, almost inside, of the menu box when opening the context menu.

After uninstalling the extension that caused it, the pointer moved to approx 2 or 3 pixels away from the menu box whenever opening the context menu.

Has anyone noticed the same thing?

This is Windows XP SP3 btw. Has anyone opened a new bug for this yet?
Comment 174 Patrik Nilsson 2009-02-11 11:20:37 PST
I've thought of this possibility with the mouse tip too, but I don't think it occurs more often because of this. Altough it happens too often anyway...
Comment 175 Samuel Sidler (old account; do not CC) 2009-02-17 11:42:00 PST
This isn't wanted on 1.9.0. We've lived with it this far, if it gets fixed at some point and a branch-specific patch is made, you can request approval and we'll consider it.
Comment 176 Henrik Skupin (:whimboo) 2009-02-17 11:46:07 PST
*** Bug 478153 has been marked as a duplicate of this bug. ***
Comment 177 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-02-17 11:59:05 PST
We can't block on this because we still have no idea how to reproduce/debug it :-(
Comment 178 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-02-19 15:42:44 PST
We have a likely fix in bug 406646.
Comment 179 Daniel Holbert [:dholbert] 2009-02-19 20:34:39 PST
(In reply to comment #178)
> We have a likely fix in bug 406646.

As noted in bug 406646 comment 162, I've made two try-server builds with that bug's current patch, which hopefully should fix this bug as well.

If those who can frequently reproduce this bug could test with one of these builds to see if it's fixed there, that'd be much appreciated!

Based off of mozilla-central trunk (Firefox 3.2 pre):
https://build.mozilla.org/tryserver-builds/2009-02-19_16:11-dholbert@mozilla.com-try-f7d80ef59ea/

Based off of mozilla-1.9.1 branch (Firefox 3.1 pre):
https://build.mozilla.org/tryserver-builds/2009-02-19_18:04-dholbert@mozilla.com-try-72cf37a71ea/
Comment 180 Cros13 2009-02-20 03:48:37 PST
Patch works for me.
I went to cnn.com and right clicked every link to open it in a new tab.
The bug was occuring for me for 1 in 5 right clicks.
With this patch no more!
Comment 181 Nate R 2009-02-20 05:54:28 PST
Patch works for me too! I downloaded the 3.1 build for Linux, and played around with it for 5 minutes. No stray menu items activated. I went back to FF 3.0.6, turned off Mouse Gestures Redox, and reproduced the bug in 10 seconds. I don't know the schedule, but please put this in FF 3.1!
Comment 182 Max Arnold 2009-02-20 19:27:03 PST
I've backported this patch to firefox-3.0.6. Problem seems to be solved, thanks!
Firefox become usable again and I'm switching back to it from Opera. But to be sure, a longer testing period probably required.
Comment 183 Patrik Nilsson 2009-02-21 01:28:30 PST
Yes, a longer test might be required...

I visited www.aftonbladet.se and on the third right click this bug happened. The archive I tested was "dholbert@mozilla.com-try-f7d80ef59ea-firefox-try-linux.tar.bz2" and it wrote "minefield" instead of "Firefox" in the title bar, so I guess I ran it.

The other day I got this bug when I clicked the "tools" menu. This means for me that the bug must be located in the core of the menu system.
Comment 184 Cros13 2009-02-21 04:42:10 PST
I've been using the Minefield Build for 2 workdays now without seeing the issue reoccur.
Comment 185 Patrik Nilsson 2009-02-24 11:15:57 PST
Today I got an insight of what the bug is.

I was working with Firefox while I did other things in the background on my work's Windows computer. The RAM was short so it used the virtual memory on the hard disk. Everything run very slowly.

The bug appeared. I was right clicking on a link. I saw item by item appearing on the menu. The menu items didn't appear in order they later should and it highlighted the first one coming up. It was somewhere in the middle of the menu. When the menu was fully drawn it disappeared and selected the first item on the list, not the highlighted one.
Comment 186 Kevin Brosnan 2009-03-01 18:18:05 PST
*** Bug 480879 has been marked as a duplicate of this bug. ***
Comment 187 Patrik Nilsson 2009-03-03 11:18:17 PST
The title says: when I click on a menu instead of click and hold it *randomly* selects a menu item and activates it

It is not at random. Firefox believes the menu is opened and selects the item it thinks is under the cursor.

I had several links above each other (row by row), when I right clicked on different lines I got different menu items auto selected and the order was as the correct right click menu. When I left clicked within the invisible drawn menu and then right clicked on a link a menu item was auto selected.

When I left clicked outside the menu and then right clicked within the invisible menu the invisible was closed and a visible menu was shown.

Can it be that when Firefox is busy doing other things and when the user right clicks, Firefox pretends that the menu is shown but it is not and the user selects invisible menu item? Or can it be that Firefox not fully closes the previous menu from memory, but on screen and the user randomly selects invisible items? Maybe the last one seems most logical.
Comment 188 e.gorodinsky 2009-03-06 07:56:17 PST
It appears that the firefox build based off of mozilla-1.9.1 branch (Firefox 3.1 pre) doesn't have this bug, while the build based off of mozilla-central trunk (Firefox 3.2 pre) does have it.
Comment 189 Patrik Nilsson 2009-03-09 12:23:29 PDT
The bug seems to appear less frequently in Firefox v3.0.7, but unfortunately is still there.
Comment 190 Robert O'Callahan (:roc) (email my personal email if necessary) 2009-03-09 14:57:13 PDT
The fix from bug 406646 has not yet landed in 3.0.x or 3.1.x. It's on trunk only.

It sounds to me like everyone who has actually tried the trunk build has stopped seeing the problem, so I'm marking this as FIXED. That means fixed on *trunk* only so far.
Comment 191 r0polach 2009-03-10 01:45:30 PDT
It would be nice if someone identify the code that fixes this issue
and backports it to 3.0.x or 3.1 (3.5) so users can enjoy it before
4.0 is released (years?)
Comment 192 Henrik Skupin (:whimboo) 2009-03-10 03:06:43 PDT
(In reply to comment #191)
> It would be nice if someone identify the code that fixes this issue
> and backports it to 3.0.x or 3.1 (3.5) so users can enjoy it before
> 4.0 is released (years?)

That will be handled in bug 406646. The patch there is waiting for approval for 1.9.1 checkin.
Comment 193 Neil Deakin (away until Oct 3) 2009-03-28 05:29:11 PDT
*** Bug 485574 has been marked as a duplicate of this bug. ***
Comment 194 Daniel Holbert [:dholbert] 2009-04-20 10:01:40 PDT
(In reply to comment #192)
FWIW, the patch in bug 406646 has now landed on the 1.9.1 & 1.9.0 branches, as noted on that bug.  Assuming all goes well, that means this should be fixed in Firefox 3.5b4 and in Firefox 3.0.10.  (It should also be fixed in the "latest-mozilla1.9.*" nightly builds, available at http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ )
Comment 195 robbertvandendoorn 2009-04-29 15:37:18 PDT
Today Firefox 3.0.10 was installed by Ubuntu's Automatic Updates.

After two hours of working with Firefox 3.0.10 it opened a new windows when I clicked with the right mouse button. So, the bug is still present in Firefox 3.0.10.
Comment 196 Daniel Holbert [:dholbert] 2009-04-29 15:41:11 PDT
Sorry -- 3.0.10 was actually converted into a security release with just 2 security-related bugfixes and nothing else.  This bug's fix should now be in Firefox 3.0.11.
Comment 197 Kevin Brosnan 2009-06-02 11:00:10 PDT
*** Bug 495985 has been marked as a duplicate of this bug. ***
Comment 198 robbertvandendoorn 2009-06-16 11:20:38 PDT
This bug still ISN'T fixed. I updated Firefox to version 3.0.11 as soon as it was available through Ubuntus Update Manager (at the 13th of June). The same day I already encountered this bug and today I saw it happen again. So, the bug is still present in Firefox 3.0.11.
Comment 199 Henrik Skupin (:whimboo) 2009-06-30 15:27:47 PDT
*** Bug 501492 has been marked as a duplicate of this bug. ***
Comment 200 Henrik Skupin (:whimboo) 2009-06-30 15:29:54 PDT
Daniel, we get more reports from users with 3.0.11 which report that this problem is not fixed. Seems like the fix on bug 406646 hasn't fixed it completely.
Comment 201 Daniel Holbert [:dholbert] 2009-06-30 16:16:29 PDT
That's sad :-/

For anyone who's still hitting this bug in Firefox 3.0.11 and beyond -- are the activated items always the first entry in the list, or are they still apparently randomly selected from the available options?  (If it's always the first entry, I'd suspect that these remaining issues are due to the mechanism suggested in comment 96 - unintentional minimal cursor movement during the click)
Comment 202 alarma 2009-06-30 16:24:54 PDT
As for Bug 501492, it's not always the first entry, but it's not being randomly selected each time - looks like it used some constant offset.
Comment 203 Henrik Skupin (:whimboo) 2009-06-30 16:25:40 PDT
Given by the last report I have duped to this bug it was the exit item of the file menu.

While looking at the amount of comments should we better file a new bug or reuse one of the latest duped for Firefox 3.0.x?
Comment 204 Daniel Holbert [:dholbert] 2009-06-30 17:26:57 PDT
Disregard comment 199 - 203... they refer to Bug 501492, which was previously marked as a dupe but actually looks unrelated.

So, with the exception of comment 198, this bug here still appears to be (mostly?) fixed.
Comment 205 Thomas B 2009-06-30 21:29:16 PDT
Confirming the behavior, while less frequent, on my 3.0.11. The item selected is somewhat deterministic, as before:

Imagine the menu that was last popped up. You right click to open a new context menu. That right click will launch the item that would be under your cursor had the the old (now "closed") menu stayed up.

Frequency has dropped off considerably for me. Used to be at 40-60% of my trials. I just tried 40 times to replicate, could not replicate once. I've seen it 2 to 3 times in as many weeks.
Comment 206 Shad Sterling 2014-06-03 20:41:43 PDT
I'm seeing this behavior occasionally (and unpredictably) in Firefox 29.0.1 on Mac OS X 10.9.3.  It seems to be selecting the item under the mouse pointer, but often happens too fast to be sure.  It does not depend on weather the mouse is above the menu when the menu appears (not bug #626418), or on the menu appearing slowly (not bug #406646).
Comment 207 Shad Sterling 2014-06-03 20:48:37 PDT
> It seems to be selecting the item under the mouse pointer,

Not necessarily under the mouse pointer, maybe just horizontally aligned with the mouse pointer.  It seems to happen several times in a row, then not happen for quite a while, and right now it's not happening so I can't try to watch for that detail.  I'll try to remember to test it next time it starts happening.

Usually, holding down the mouse button prevents the selection until I release the button.  The new thing today that made me look for this bug was that holding down the mouse button did not prevent selection.
Comment 208 Daniel Holbert [:dholbert] 2014-06-03 21:47:14 PDT
Please file a new bug on the behavior you're seeing. This bug has been closed for ~5 years, so if you're seeing something like this bug, it's virtually certain to be different (e.g. a new regression).

(This bug also has > 200 comments, which makes it a particularly bad place for continued discussion, given the backlog of history that would need to be read for anyone picking up on new work items here.)

Feel free to post a link to your new bug here, though, if you think they're related. Thanks!
Comment 209 Toothbrush 2015-06-10 12:19:33 PDT
@ShadSterling, See bug #1173482.
Comment 210 Shad Sterling 2015-06-10 13:34:02 PDT
@Toothbrush, how is that related?

Note You need to log in before you can comment on or make changes to this bug.