case: click "file" (be careful to not move mouse after click) note "file" is not depressed, as it is if you move the pointer ~1 px move pointer to any item in the "file" menu move pointer directly to "edit" menu without passing over "file" (i.e., between "new" and "navigator" in the "new navigator window" menu item) note the "edit" menu does not open and the "file" menu does not close expected: the "file" menu should close and the "edit" menu should open, as it does with most menu systems (win 2k, gnome, kde, etc). this feels very similar to the "back" button not visibly depressing unless the mouse moved, but I can't find that bug at the moment.
observed on: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3+) Gecko/20010823
i think this is a dupe of other bugs but i'm not sure which.
Target Milestone: --- → Future
this has gotten worse. you don't even have to move the pointer very quickly at all. if this is a dupe, I can't find the original bug.
new menu owner
Assignee: pinkerton → hyatt
Status: UNCONFIRMED → NEW
Ever confirmed: true
sorry for the noise: this bug is now much harder to reproduce, but it *is* still there. I think the first two steps in my original test case still stand as a bug, but the rest of the test case barely ever happens, which is great. verified as "noticably better yet still not right so still NEW (yes, on the same machine/configuration)" on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020107
This works for me with a current linux trunk build. Please protest if it doesn't for you. Otherwise I'll resolve this bug as WFM soon.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME
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.