Closed Bug 29401 Opened 25 years ago Closed 16 years ago

First item in menu is deselected when holding down mousebutton

Categories

(Core :: XUL, defect, P3)

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

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: sicking, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: [nsbeta2-]) 

In build 2000-02-26-08 on Win98SE

Steps to reproduce:
1. Click on the View menu and hold down the button.
2. Move down to the "Toolbar" item, but be careful to cause only one "onMove"
   event

Actual resaults: The Toolbar item get selected but then deselected

Expected resaults: The Toolbar item should keep selected.

When the next "onMove" event is triggered the item is correctly selected again.
This can also be seen as a flicker if you press the mouse on the View menu and 
move slowly down.
wow, that sucks ;)
Status: NEW → ASSIGNED
Target Milestone: M15
I can't duplicate this with today's Win32 build (ID: 2000032808) running on NT.  
Is this specific to Win98, or is it not an issue anymore?
yes, i still see this.

i can see this on winNT, using 2000.03.30.09 opt comm bits. cannot see it on
linux, though.
OK, I see it now, but not all of the time.  It's easiest for me to reproduce 
when I go into the Toolbars submenu and either check or uncheck something, then 
go back into the View menu.  Perhaps it's something to do with one of the items 
in the Toolbars submenu thinking that it's still active?
i concur w/dean (forgot to add it above): the place where i see this is with
View > Toolbars...(most recently) Debug > Verification. perhaps it affects only
parent menus if they're the first ones listed in the menu?
that's my guess as well, though i never put it in here....good to know there 
might be some data to back that up.

Changing summary.
Summary: Menuitems are deselected when holding down mousebutton → First item in menu is deselected when holding down mousebutton if it has a submenu
adding myself to the cc: list
nsMenuPopupFrame::SetCurrentMenuItem is getting called in these cases, which 
calls mCurrentMenu->SelectMenu(PR_FALSE).
Something like this...

Check out the next 20 or so lines at 
http://lxr.mozilla.org/seamonkey/source/layout/xul/base/src/nsMenuFrame.cpp#318

When this behavior occurs, it looks like there's an extra NS_MOUSE_EXIT firing 
off.  The first is expected, and comes from the nsMenuFrame on the menu bar 
("View" in this case).  But the second one causes problems.  It gets all the way 
through into the "if (isMenuBar)" loop, and since the parent is active, the 
cancel variable is set to false.

Since cancel is PR_TRUE the "if" at line 331 get checked.  The first two 
conditions pass but the last one fails as mMenuOpen == PR_FALSE.  So the current 
menu item is removed at line 334.

This is what I can determine is happening.  Why, that's a question I haven't 
been able to answer yet.

Something else I noticed and to try is that when you get this flashing behavior, 
click on another application behind Mozilla.  The popup menu doesn't dismiss.
pushing off
Target Milestone: M15 → M17
*** Bug 37342 has been marked as a duplicate of this bug. ***
I looked at this in today's build (ID: 2000050208) and the "if it has a submenu" 
part of the summary doesn't hold anymore.  It can happen on any menu - Help, 
Bookmarks, etc.
[nsbeta2-]
Whiteboard: [nsbeta2-]
Mass-moving all nsbeta2- bugs to M20
Target Milestone: M17 → M20
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm
pushing off, we've got bigger fish to fry. marking helpwanted.
Keywords: helpwanted
Target Milestone: M20 → Future
Target Milestone: Future → mozilla1.0
I'm wondering if it's related to this behavior...

1. Edit > Preferences > Appearance > Fonts
2. Make sure Western is selected in Language Encoding and the menulist is closed
3. Click and hold on the Language Encoding menulist
4. Slowly drag down.

Expected Results:
Western is highlighed when the menulist drops down and dragging retains the
highlight.

Actual Results:
Western is highlighted when the menulist drops down but dragging sometimes
removes the highlight at one pixel and restores it at the next.

I can't reproduce it every time, which makes it sound even more like this bug.
My first impression is that dragging over the popup frame is causing the
selection to be lost.
I've seen this too.  It isn't specific to the first menu item... it seems to 
have more to do with timing than which menu item you're over.
new owner
Assignee: pinkerton → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.0.1
As Dean Tessman says, this can be reproduced help-menu which doesn't have any 
submenues
Summary: First item in menu is deselected when holding down mousebutton if it has a submenu → First item in menu is deselected when holding down mousebutton
I wonder if the fix for bug 120209 magically fixed this.
I'm still able to reproduce this, but it's a whole lot harder. It seems like 
you have to move the mouse over the first menuitem within a certain timeperiod 
now. To reproduce:

1. press the mousebutton on a menu
2. *quickly* move the mouse over the first menuitem (don't release the button)
3. stop moving the mouse

sometimes the menuitem is temporarily selected at step 2. but then deselected 
and remains unselected in step 3. However if you release the button after step 
3. the menuitem is activated.
This is easy to see in the bookmarks menu with sub-folders, and
there's a bug on it. Related, dunno if it's the same problem ?
That's bug 41766 btw.
I tried to reproduce this with my 1.7 final, but that doesn'ts eem to work.
Is this bug fixed or did I do something wrong?
I can still reproduce. It doesn't happen every time, but trying a few times I
can defenetly make it happen.
steps no longer precisely match, but I"m not seeing this SM winXP - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060130 SeaMonkey/1.0

does this still exist in unix?
Assignee: hyatt → nobody
Status: ASSIGNED → NEW
QA Contact: jrgmorrison → xptoolkit.menus
Tony do you see on linux?
(In reply to comment #29)
> Tony do you see on linux?

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008051201 SeaMonkey/2.0a1pre

No I don't.

-- Mozilla 1.0.1 is long past => resetting Target milestone.
Target Milestone: mozilla1.0.1 → ---
=> WFM then
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: xptoolkit.menus → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.