Closed Bug 29401 Opened 26 years ago Closed 18 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: 18 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.