When enabling focus-follows-pointer in Win NT using TweakUI, context menus can be created using the right mouse button but they disappear when the pointer enters the menu. They otherwise persist until another mouse click occurs in the main window or the pointer leaves the current window, as expected. The shortcut keys can still be used to make use of the context menu while it is visible, i.e. B still does Back, but any menu item which does not have a shortcut is unusable.

--> future

I'll take this one, if you want.

Context menus should never, ever accept focus. Persistant little bug...

I have the same problem but under 98 with TweakUI, focus-follows-mouse.

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

Does this go all the way back to nsBoxFrame::HandleEvent(), or did I completely mess up walking back nsMenuPopupFrame::HandleEvent()? Damned inheritance.

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

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

I have found today that if you're incredibly fast you can manage to enter a context menu without it disappearing. The context menu from a link right-clicked arent available this way though.

That's not the whole problem. MS behavior is the menu stays up once it's up, until you click somewhere else (context menus) or move the mouse out of the menu (regular menus) Neither of these is working correctly in Mozilla when focus follows mouse is set. That's why context menus are unusable. This is (logically, if not technically) independent of the MS vs 4.x standard arguement. (Ha Ha!! Since when is 4.x a STANDARD?) I believe you'll find #54977 is a duplicate of this, but describes the problem in better detail.

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

I would like to mark this bug as critical because the inconvenience is comparable to having the browser crash every 15 minutes under normal use. Keyworks ui, mozilla0.9, and helpwanted should be added to expedite resolution. This is the single most annoying bug remaining in Mozilla for the people who use the registry X-Mouse feature. The inability to right click on a hypertext link getting the context menu and opening the link in a new window is the single thing that makes using IE appealing to me. I would fix this myself if I had a non-Unix (i.e. MS-Windows) development environment available, but unfortunately use of Outlook requires having an NT desktop at work. Netscape/Mozilla will not be qualified to replace IE on the Windows desktop until this bug is fixed. Nothing short of a development BLOCKER is substantially more important that this to those who are affected.

Saari, since you mentioned it, how would I make a context menu refuse focus?

You can try setting style to moz-user-focus: ignore, but in the case of context menus we probably need special code to check the window type and abort the focus sequence if the thing being focused is a popup. This is how it works on MacOS.

I could take a look at this on Windows, probably. I'll check out the WM_GETFOCUS and WM_ACTIVATE processing.

Is there any progress on this bug ? Its literally the only thing stopping me from using moz (for browsing) 100% of the time. Everyone using X-Mouse cant open links in new windows, view frame source etc etc making it pretty much unuseable for proper browsing. Echoing JAGeorge's words, cant this priority be marked up ?

There are some hacky work-arounds for using those context menus you can't enter. First, you can get the menu up using the right-mouse click as normal, and then step up and down the menu items using the cursor up and down keys - hit return to select an item. This is the method I prefer. Just don't move the pointer into the menu or it will disappear. The second, as has previously been mentioned, is that if you are moving down and right when you right click the menu, the pointer ends up inside the menu and you can click as normal. This only works because the menu doesn't change pointer focus if the pointer is inside it at creation time. Possibly a quick hack to the code to create the menu so that the mouse is inside the menu when it is created (probably just create the menu 1 pixel up and 1 pixel to the left of where it should be) might do it. This would allow you to use the menu as long as the pointer does not leave it. Neither of these suggestions should alleviate the need to fix this properly - the menu should not be causing a focus-change request. Pull down menus work properly, so why not this?

Actually, pull-down menus and menu lists only work properly if you click-and-drag. If you click - release - move mouse, the menu or menu list disappears.

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

Duh. I betcha this would work if we backed out bug 27364. Not a fix, for sure, but it would be a workaround. And addressing this bug would satisfy more people than the other one did.

Backing out bug 27364 would not fix the drop down menu problem, though it would kludge a fix for the completely unusable context menus. Wouldn't it be possible to simply NOT focus on menus when they pop up? Then focus can be applied if the right menu button is released ON the menu OR the left menu button is clicked ON the menu. This would make keeping the 27364 fix a meaningful thing to do instead of a pain in the neck.

Yes, just don't set focus. I don't know why X mouse is causing issues; sorry, I'm not a big linux guy. Does it want to set focus all the time? "You can try setting style to moz-user-focus: ignore, but in the case of context menus we probably need special code to check the window type and abort the focus sequence if the thing being focused is a popup. This is how it works on MacOS."

Hmmmm... seems I never got back to commenting on this. I remember looking at it but can't recall the exact results. I can probably take another shot, but not for at least a week.

Saari, you don't have to be a big Linux guy. This is a Windows bug.

x-mouse is a geek feature. if a mozilla-ite wants to own this and up the priority, be my guest (dean?). If it's on my plate, though, it's staying just how it is.

Oh, so now you're calling me a geek?! Just kiddin'. I don't use X-Mouse, but I'll take this one. There won't be a fix anytime soon, but I'll keep it on my radar.

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

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

OK, here's a weird one, and I'm hoping that someone else can duplicate this for me and it's not my mind. I'm using the modern skin and I find that if I move the mouse really slowly and enter the context menu from either the right side or the bottom, the context menu stays open. But it always closes coming in from the top or left. I wonder if it's the popup frame that's stealing focus?

I can verify Dean Tessmann's experiment. I'm currently running build 2000121820 on Win NT SP 6a and the Orbit skin, and I can enter a popup menu from the right-hand-side or the bottom of the menu at a slow speed, but not from the top or left. Now that is extremely wierd. If I rush it, the popup disappears. Additionally, if the mouse is moving down and right when I right click, I can usually get the pointer the appear inside the popup window and use it normally.

That last behavior that you mentioned is what made me ponder if it's the popup's frame that's stealing focus. It happens because when you release the right button, it grabs the x and y to display the context menu at, which are both +2 pixels from the current position. But because the context menu is created at that time, you are able to move the pointer more than the 2 pixels down and to the right before the menu is displayed. So when the menu is actually displayed, your pointer is inside the menu.

Oh geez, how long has Mike been left out of this discussion? Adding him to the CC: list.

X-Mouse seems to activate windows with a WM_MOUSEACTIVATE message. I might have this tracked down to nsWindow::DealWithPopups(). (As an aside, the drop-down folder list in Outlook Express handles X-Mouse as well as we do. tee hee)

Adding keywords, setting milestone to something other than "Future". Because I needed the lParam from WndProc() in DealWithPopups(), I changed that function's parameters to include it. While I was at it, I added wParam. It's not needed now, but may be in the future. This is a very safe patch, as DealWithPopups is called only from within nsWindow.cpp, and it's Windows-specific. Two questions: 1. Does anyone see any problems with the call to ShouldRollupOnMouseWheelEvent() that I threw in there? It makes sense to me - if it's not going to roll up on the mouse wheeling, then it shouldn't roll up on X-Mouse, either. 2. Should the changes to DealWithPopups be propogated to the OS/2 code, for consistency?

cc: bryner for the mousewheel related question above ...

cc'ing Blake, 'cause I miss him.

Just to chime in for no good reason, this will occur on any version of Windows from 95 up and NT4.0 (base, no SP) up as well, as long as the X-mouse style tracking is active. I just confirmed this as well. And Tessman's guess about the opoup stealing focus is right. It's one of those feature-bugs in Windows where two objects can both have active focus. The mouse is moved, and focus falls on Mozilla since that's what's under the first new pixel to where the mouse is moved. Good luck to whoever gets to fix this. The code to handle window objects in Windows is rather buggy. (Windows' windows wilt and wither?)

Ummm, I guess I'll take that good luck wish, because I think I fixed it last night.

Yeah, ShouldRollupOnMousewheelEvent will give the right results, I think. The only thing I don't like is the naming, since this isn't a mousewheel event... perhaps we should rethink this API at some point.

ShouldIgnoreScrewedUpMouseEvents??

So now that Brian has given his OK to using the ShouldRollupOnMouseWheelEvent() call, I guess I'm looking for a review of this. And sorry about my last comment, Brian, I wasn't knocking the mouse wheel messages there. I was just expressing a little frustration with the time I spent last night tracking down how MS implemented X-Mouse. What about a name like GetRollupOnInternalActivation, GetRollupOnWheelAndXMouse, GetRollupOnNonUserEvents? I can't think of any short name for this one. Anyway, do you want to file a separate bug on this one and cc: me? I'll take care of making an actual patch after that, if you want.

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

* gives puppy dog eyes in hopes of attracting a reviewer *

Has anyone tried this patch on their build? Toby, perhaps you have?

'Fraid not at the moment - I don't have a Mozilla source tree set up at the moment to patch against. If nobody else can test this, I'll set up my NT build environment (most of my compiling work is done on AIX, Solaris and Linux). As far as the code goes, the patch looks sane enough :-)

I am going to test this patch sometime later today or early tomorrow. Watch this space ...

Applied patch on build 2001011514 Verified that it works fine. Requesting integration into tree.

is this patch going to be integrated into the tree ? It would be lovely to have this fixed.

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

If you right-click on an image that's a link, there's a duplicate access key between Save Link As and Save Image. Was this introduced by this bug?

Errr... ignore that last comment. Right words, wrong bug. Sorry for the spam.

This is mozilla0.8, and would love to get it off my plate. Unfortunately, nobody seems to want to review it ( * sniff * ). Any takers?

Hey rod, could you give an r= or advice on how to get one for dean's second patch? /be

->mozilla0.9

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

Okay, so I've been running with this patch and X-Mouse on Win2k for a few days. Probably want to resolve the ShouldRollupOn[somedescriptivename] issue, but can Dean get some r= loving on the second patch (and/or a suggestion for the right name)? bryner?

1) you don't use |inWParam| at all in DealWithPopups, so it doesn't need to be passed as a param. other than that, r=pink.

Yep, that's intentional. See my Jan 3 comment. I don't use it now, but since I'm now passing message information into DealWithPopups(), I thought it wouldn't hurt it put in wParam for potential future use.

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

sr=hyatt, but test the hell out of it first.

re: ShouldRollupOnMouseWheelEvent... it's probably OK to leave this name for now. I commented my call to it pretty heavily, and I'd hate to hold up this patch because we have to go through and change all occurrences of the name.

See my testing checklist for bug 45108, which included some testing with this patch checked in and x-mouse enabled. Specifically, look at items 3, 6, 8, 10, 11, and 12. I'm confident that this bug doesn't toast anything else. Plus it sounds like jrgm has been running with it without incident. I say check this mutha in!

taking back so i can land it.

Fixed in the same check-in as the bug 45108 fix.

v