GNOME Bugzilla – Bug 745246
mouse hover and keyboard focus identical
Last modified: 2015-03-17 14:48:13 UTC
try this: open the menu hover the mouse over the volume slider hit down arrow twice what will happen if you now hit enter ?
Almost certainly fallout from the popup patches in bug 744680.
Created attachment 298453 [details] [review] theme: have a separate state for hover and focus
This separation of :hover and :focus has exposed an issue - when you hover with a mouse, sometimes items remain being focused afterwards...
Comment on attachment 298453 [details] [review] theme: have a separate state for hover and focus Attachment 298453 [details] pushed as 8a732d3 - theme: have a separate state for hover and focus
In retrospect I think dealing with both keyboard and mouse input at the same time is a little odd. Maybe both :focus and :hover should be the same, but whatever was the last input should have the last say. When I start pushing cursor keys I no longer need to see the hovered line and vice versa, when I resume using the mouse I no longer need to keep track of where my keyboard selection was.
(In reply to Jakub Steiner from comment #5) > In retrospect I think dealing with both keyboard and mouse input at the same > time is a little odd. Maybe both :focus and :hover should be the same, but > whatever was the last input should have the last say. When I start pushing > cursor keys I no longer need to see the hovered line and vice versa, when I > resume using the mouse I no longer need to keep track of where my keyboard > selection was. Well, thats just not how computers work... we get input events from keyboards and mice intermixed, and we can't just declare that 'invalid use'. And I doubt people will thank you for yanking their keyboard focus across the screen because they touched their mouse while typing...
ok, I see what you're saying now in the system status menu. The issues I see with hover and focus now: 1) in the status menu, some of the items appear to grab focus on hover, while others don't. Concretely, if I put the focus on one of the regular items, and then hover over one of the circular buttons, the focus indication remains where it was, but if I hover another regular item, the focus is moved to the item I hover 2) When moving the mouse pointer from a menu item over a separator, the hover is removed, temporarily 'uncovering' the focus, which is somewhat irritating since the blue is much stronger than the gray. It might be better if the strong blue was following the pointer and we used the subtle gray for focus. 3) The circular buttons still have hover == focus == blue. 4) In the calendar popup, we still have hover == focus == gray everywhere. 5) It is slightly odd I can put keyboard focus on the week numbers and day names - I assume this is so the screen reader can read them ? 6) In HighContrast, the focus indication on the section headings and in the calendar is basically invisible, and the hover indication on the clocks is much too weak. And again focus == hover == gray.
(In reply to Matthias Clasen from comment #7) > 5) It is slightly odd I can put keyboard focus on the week numbers and day > names - I assume this is so the screen reader can read them ? Yes, exactly.
In retrospect, considering 1) - 4), it is probably better to go back to hover == focus in the menu.
Or we could do what GTK+ does and make both set the other as well?
Created attachment 299119 [details] [review] theme: Style .active menu items instead of :focus/:hover The .active style class indicates the "active" menu item, which is generally the last hovered or focused one (whichever happened last). Styling that instead of :focus and :hover directly guarantees that only a single item will be selected at a time, which removes ambiguity and matches the behavior of GTK+ menus.
So here's another option we might want to consider - otherwise the bug should probably be closed, considering that separating :focus and :hover hasn't worked out and was reverted as of comment #9 ...
having a single class to replace :hover and :focus is workable, but perhaps calling it .selected would be better to avoid the potential confustion with :active.
Created attachment 299527 [details] [review] popupMenu: Use .selected class for active item Currently it uses .active, which matches the code more closely, but is confusingly close to :active; so .selected it is ...
YES!
Comment on attachment 299527 [details] [review] popupMenu: Use .selected class for active item Attachment 299527 [details] pushed as 8b6e566 - popupMenu: Use .selected class for active item