From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801 BuildID: 2001080110 The Composer context menu seems to contain hidden menu items that you can navigate to with arrow keys. The the current menu item loses higlight, but the next one is highlighted only after two or more arrow key presses. Reproducible: Always Steps to Reproduce: 1.Start composer 2.Open the context menu, you'll see "Paste", -, "Select All", -, "Discontinue Text Styles" and "Create Link..." 3.Press down arrow a number of times and see how menu items are highlighted. Actual Results: You have to press down arrow 5 times to select "Paste", 2 times to go to "Select All", 1 time to go to "Discontinue Text Styles", 1 time to go to "Create Link..." and 14 times to go back to "Paste" Expected Results: You should need to press down arrow 1 time to select "Paste", 1 time to go to "Select All", 1 time to go to "Discontinue Text Styles", 1 time to go to "Create Link..." and 1 time to go back to "Paste"

Confirming it with win98, build 2001081108 Marking as NEW and moving to XP Toolkit/Widgets: Menus

bug 94990 may be related

The EditorContextMenu.js toggles the menu items by setting the 'collapsed' attribute. In contrast, nsContextMenu.js directly sets style to 'display:none', and hidden menuitems are not part of the keyboard navigation. If setting collapsed=true should leave menuitems in the navigation sequence, then this is a content bug. If it shouldn't, then a menu bug. [And no, this doesn't have anything to do with bug 94990, since that is a very visible, recent regression. This keyboard quirk has been around for (at a minimum) weeks].

hidden maps to display:none. collapsed maps to visibility:collapse. This is a menu bug.

my question is why does the editor js set the collapsed attribute and not the hidden attribute? should both really do the same thing? hyatt, have you made any changes in this area regarding syntax recently?

If we are supposed to use "hidden" instead of "collapse", this is fixed very easily. I can take this bug.

Ooops! looks like I jumped the gun. The central issue is whether key navigation should skip over "collapsed" menuitems. Certainly seems like it should. If you want Composer to switch to using "hidden" instead of "collapsed", or you decide to not skip over collapsed items, file a separate bug on me or assign this one and I'll take care of that.

yeah, this is a toolkit bug in the key navigation code. we should do the same for collapsed as we do for hidden. dr was saying he was bored. here ya go, doc!

[spam] -> 0.9.5

[spam] dr@netscape.com's bugs subject to redistribution by chofmann. R!

back to -> pinkerton (who may still want to give this to someone else, but probably knows specifically what needs to be done).

i'll give it to jag!

I'll be happy to change Composer's menuitem hiding to use "hidden" rather than "collapsed" (I've done it in my tree), but we do want to fix the basic problem anyway, correct? So I'll hold off on the Composer fix to keep it as the test case.

-> 0.9.5

Mass-moving lower-priority 0.9.5 bugs off to 0.9.6 to make way for remaining 0.9.4/eMojo bugs, and MachV planning, performance and feature work. If you disagree with any of these targets, please let me know.

I don't see this on 2001100203. Arrowing down through the menu works as expected. (I do see the entire menu briefly when I press Escape. Anyone know if that's already been filed?)

cmanske changed the menu to use 'hidden' instead of 'collapsed' -> bug 100015 So, this bug is really about making the generic change to menu code to not walk through menu items that are visibility:collapsed. (p.s., Dean, I don't see that thing with Esc showing whole menu, but if you can reproduce it then file a bug for that).

Filed as bug 103069.

-> 0.9.7

Clearing milestone and setting nsbeta1 keyword for triage.

-> 1.0.1

nsbeta1- per Nav triage team, ->1.2

removing myself from the cc list