Closed Bug 50798 Opened 24 years ago Closed 23 years ago

context menus are unuseable when using x-mouse

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.8.1

People

(Reporter: thaynes, Assigned: mikepinkerton)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(2 files)

Why, I do believe I've nailed this. (said in a mock English accent)
1.92 KB, patch
Details | Diff | Splinter Review
Hrrmmm. How 'bout we all just ignore that first patch?
2.90 KB, patch
Details | Diff | Splinter Review 
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → 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.
Keywords: helpwanted
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.
Assignee: pinkerton → dean_tessman
Status: ASSIGNED → NEW
*** 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)
Keywords: patch, review
Target Milestone: Future → mozilla0.8
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
Status: NEW → ASSIGNED
Target Milestone: mozilla0.8 → 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.
Blocks: 16037
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.
Assignee: dean_tessman → pinkerton
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9 → mozilla0.8.1
Fixed in the same check-in as the bug 45108 fix.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
v
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: