Community
Participate
Working Groups
A few issues I noticed with the new Orion drop-down menus: 1. When you open a menu, there are separate keyboard focus and mouse focus indicators, which can be moved independently. I found this strange -- I was expecting a single focus indicator, which can be controlled by either keyboard or cursor. 2. Hovering with the cursor over a submenu should (after a delay) open the submenu. 3. (In the banner's Settings menu only) Pressing ENTER to activate the selected item does not work. Also the "Keyboard Shortcuts" item does nothing when clicked.
Fixed #3 with http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=dbebdc62a52d8953d0f22ba8c61c8b9bca9763a7 Enter key had stopped working for all links in menus. (I regressed this at some point).
Regarding #1: there is actually separate behavior at play, because the hover state does not impact the focus. That is, if you open the menu, keyboard down to, say, the third item, hover over the first item, and hit the down arrow....you will move to the fourth item. So the focus state is important given current behavior. I'm using simple pseudoselectors to achieve this. I agree using the same indicator for both focus and hover looks pretty buggy/confusing. As an M1/simple fix, I have restyled the focus to use the row focus color we use in navigator. Fixed in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=24bd8d2df298a824e310f3674f8753e9a290e1d4 Ken and Mark agreed this was better, more intentional looking. However I think the real fix is to change the focus when you hover over an item. This is what dijit does. If you hover and then use the keyboard, the keyboard state wins over the hover, unless you change your hover to a new item. This means we can't just use the CSS :hover effect but need to write some js to manage mouseover/mouseout for the items. We would need to do this anyway to implement #2. So I'm moving this bug to M2 to deal with #1 and #2 at a later time.
I would also like to see us showing the text decoration (underline) when we unify the hover/focus behavior. Whether you are hovering or using the keyboard, the "current" item in the menu should show the underline if it's a link.
funny...bootstrap has this same issue...separate hover and focus. I checked because I know they have minimal js and try to do most things with just CSS. http://twitter.github.com/bootstrap/javascript.html#dropdowns Maybe we have a conceptual decision to make about being more dijit-like (more code) or keeping it simple (as long as the user understands it)
Mark, how much are 1 and 2 bugging you these days? Trying to separate the feeling of "it worked before with dijit" vs. "I just expect it to work this way." I'm inclined not to do them on the grounds that bootstrap doesn't, but if you still find this annoying I can look at it.
(In reply to comment #5) > Mark, how much are 1 and 2 bugging you these days? Trying to separate the > feeling of "it worked before with dijit" vs. "I just expect it to work this > way." I'm inclined not to do them on the grounds that bootstrap doesn't, > but if you still find this annoying I can look at it. I'm fine with leaving #1 as-is, but #2 still seems strange to me. (I'm having a hard time finding any menus-within-menus on the web to compare ours with, though. Maybe they're considered unwebby.) Regardless, neither of these is a big deal in my day-to-day use.
I'll keep this on the radar for RC1. (In reply to comment #6) > I'm fine with leaving #1 as-is, but #2 still seems strange to me. (I'm > having a hard time finding any menus-within-menus on the web to compare ours > with, though. Maybe they're considered unwebby.) They are considered bad design by at least Mark Otto. Here's what I first found on the subject when I was looking at dropdowns for Orion. They resisted putting it in and finally relented. https://github.com/twitter/bootstrap/issues/424 I'll revisit their current implementation as a gut check on user expectations, but will also look at some jquery plugins.
#3 has regressed again (tried in Chrome). So for example, click in Search text, type tab twice to move to User name field, type Enter to drop down the menu, use down arrow until "Settings" is highlighted. At this point, Enter key should select the "userSettings" link, but nothing happens. Please see the reccommended keyboard interactions for a menu button and menu: http://www.w3.org/WAI/PF/aria-practices/#menubutton http://www.w3.org/WAI/PF/aria-practices/#menu Particularly of note: "When a menu is open and focus is on a menu item in that open menu, then Enter or Space invokes that menu action (which may be to open a submenu)."
(In reply to comment #8) > #3 has regressed again (tried in Chrome). So for example, click in Search > text, type tab twice to move to User name field, type Enter to drop down the > menu, use down arrow until "Settings" is highlighted. At this point, Enter > key should select the "userSettings" link, but nothing happens. > > Please see the reccommended keyboard interactions for a menu button and menu: > http://www.w3.org/WAI/PF/aria-practices/#menubutton > http://www.w3.org/WAI/PF/aria-practices/#menu > > Particularly of note: > "When a menu is open and focus is on a menu item in that open menu, then > Enter or Space invokes that menu action (which may be to open a submenu)." I opened bug 403497 for this because it's higher priority.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
