Closed Bug 404314 Opened 17 years ago Closed 16 years ago

when I click on a menu instead of click and hold it randomly selects a menu item and activates it

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: db48x, Assigned: enndeakin)

References

Details

(Keywords: dogfood, regression, Whiteboard: [fixed by bug 406646])

Attachments

(6 files)

workaround for phantom double-clicks
9.01 KB, patch
Details | Diff | Splinter Review
nsMenuPopupFrame.cpp assertion
42.27 KB, text/plain
Details
nsCSSFrameConstructor.cpp stack
54.58 KB, text/plain
Details
fix assertion and issue from comment 120 [checked in (comment 139)]
762 bytes, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
(no clue) lazy menugenerated attempt
4.36 KB, patch
Details | Diff | Splinter Review
bad hack to try make this happen more frequently
733 bytes, patch
Details | Diff | Splinter Review
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.
Flags: blocking1.9?
I can definitely confirm this. both bz and roc see the same thing, too.
Oh, and I haven't seen this in the windows nightlies, but that may only be because I use them so much less frequently.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
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. :/
Keywords: dogfood, regression
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?
Assignee: nobody → roc
Priority: P3 → P2
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.
For me, two-finger click can trigger the bug, but ctrl-click never does.
I can't reproduce this bug in any way, so I can't really comment on what's wrong.
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.
(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.
> 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'?
(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 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.
Ditto. When this happens to me I'm definitely not moving the mouse at all.
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.
I haven't seen this for a while. Are people still seeing it?
(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.
I wonder if I'm not seeing it anymore because the Mac build got faster.
I see it all the time too.
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.
Flags: blocking1.9+
Of course you need. This bug is about LINUX, so you need.
I *was* seeing it on Mac quite a lot.
Flags: tracking1.9+
Blocks: 422021
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.
Whiteboard: [cannot reproduce]
roc, have you been able to reproduce this bug on Linux?
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.
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...
Whiteboard: [cannot reproduce]
I'm still seeing random commands being executed on Linux as of a current nightly.
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
OK, it's quite possible that the same cause is causing both bugs.
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?
I actually see this in gedit as well.
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.
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).
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.
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.
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.
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.
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.
A slightly less conservative option would be to drop the "triggered context menu" condition --- that would fix other phantom double-click issues.
Keywords: qawanted
Whiteboard: [QA please see comment 36]
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.
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?
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.
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.
Ok. Did this bug ever trigger when you released the right button after holding it down for a while?
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...
Yeah, I guess that's hard with a mouse. It's easy with a trackpad.
Progress on this?
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.
(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?
I thought someone could just post a link to this bug there, but never mind, I'll register and post there.
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.
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.
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.
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.
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 :-).
I'll give it a whirl as I'm still getting the problem in beta 5. At what time will the nightly get built?
I think we can fix this in a 1.9.0.x release. Hard to reproduce. Moving to 1.9.0.x.
Flags: wanted1.9.0.x+
Flags: blocking1.9-
Flags: blocking1.9+
(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?
Flags: blocking1.9-
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.
You guys are aware this happens on the Mac build too, right? So it's not just the linux builds running in a VM.
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?
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.
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.
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.
ok, testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042404 Firefox/3.0b1 now.
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.
No, I reported this problem on linux.
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.
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!
(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)
(In reply to comment #70) > Daniel, reed, are you still seeing this on Linux? Yep, hit it at least twice yesterday. :(
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.
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
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
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.
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.
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)
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?
Sure, I can give that a shot.
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).
Perhaps you could help us come up with reliable steps to reproduce.
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.
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?
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.
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.
768MB @ 1,6Ghz
Mine is a Lenovo T60 Laptop Processor: 2.0GHz Core Duo Memory: 1 GB
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.
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
(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.
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.
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.
(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.)
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).
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.
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.
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.
Is the Bug 406646 related to this one? (or duplicate?)
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
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
(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.
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.
I don't use SnapLinks, but I have this bug. FYI I use only AdBlockPlus, Rikaichan and Ubuntu addons.
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.
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.
(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.
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.
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
mmm, thanks!!! Setting a breakpoint there would be *very* interesting. dbaron, dholbert --- can you try that?
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.
backtrace and backtrace full with nsMenuPopupFrame:230
backtrace and backtrace full in nsCSSFrameConstructor.cpp:7773
Attachment #350701 - Attachment mime type: application/octet-stream → text/plain
Neil, can you look at that nsMenuPopupFrame assert?
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.
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.
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
(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.
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.
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).
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.
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.
(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?
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.
(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?
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.
(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.
(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
Don't think that this patch will fix the original bug report, but it should help on Linux.
Assignee: roc → enndeakin
Status: NEW → ASSIGNED
Attachment #353441 - Flags: superreview?(roc)
Attachment #353441 - Flags: review?(roc)
(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.
Attachment #353441 - Flags: superreview?(roc)
Attachment #353441 - Flags: superreview+
Attachment #353441 - Flags: review?(roc)
Attachment #353441 - Flags: review+
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.
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.
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.
Checked this patch in. It seems like the patch may instead be the one for bug 406646.
Blocks: 406646
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).
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?
By turning of the "Assistive Technologies" on my acer aspire one the bug happens less frequently.
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(); } } }
Patrick, can you try the patch i attached? btw, what are you trying to workaround with the code you pasted?
(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)
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.
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.
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)
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.
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
Attachment #353441 - Attachment description: fix assertion and issue from comment 120 → fix assertion and issue from comment 120 [checked in (comment 139)]
(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.
(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.
(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.
> 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.
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.
OS: Linux → All
(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.
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...
(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)
OS: All → Linux
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?
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. ;)
Ok noted dave. Thanks for confirming. By the way, it opens up evolution even if the link clicked isn't an email address.
(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.
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.
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.
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.
(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.
Neil, can you try Marco's patch and see if you can reproduce?
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
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.
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...
Bookmark menu is reinitiated every time it is to be shown; the bookmarks are added to the menu. The other ones are more 'static'.
Still observed on Ubuntu 8.10 using Firefox 3.1b2. Using Dell Inspiron 6000, 1gb of RAM, 1.7ghz, using laptop touchpad.
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?
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...
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1-
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.
Flags: wanted1.9.0.x+
OS: Linux → All
Hardware: x86 → All
We can't block on this because we still have no idea how to reproduce/debug it :-(
Flags: wanted1.9.1+
(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/
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!
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!
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.
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.
I've been using the Minefield Build for 2 workdays now without seeing the issue reoccur.
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.
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.
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.
The bug seems to appear less frequently in Firefox v3.0.7, but unfortunately is still there.
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.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
No longer blocks: 406646
Depends on: 406646
Keywords: qawanted
Whiteboard: [QA please see comment 36] → [fixed by bug 406646][QA please see comment 36]
Target Milestone: --- → mozilla1.9.2a1
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?)
(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.
Whiteboard: [fixed by bug 406646][QA please see comment 36] → [fixed by bug 406646]
(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/ )
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.
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.
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.
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.
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)
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.
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?
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.
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.
Blocks: 488381
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).
> 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.
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!
@ShadSterling, See bug #1173482.
@Toothbrush, how is that related?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: