After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745246 - mouse hover and keyboard focus identical
mouse hover and keyboard focus identical
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
theme
Depends on:
Blocks:
 
 
Reported: 2015-02-26 18:54 UTC by Matthias Clasen
Modified: 2015-03-17 14:48 UTC
See Also:
GNOME target: 3.16
GNOME version: ---


Attachments
theme: have a separate state for hover and focus (1.78 KB, patch)
2015-03-03 16:44 UTC, Jakub Steiner
committed Details | Review
theme: Style .active menu items instead of :focus/:hover (1.39 KB, patch)
2015-03-11 18:21 UTC, Florian Müllner
committed Details | Review
popupMenu: Use .selected class for active item (1.34 KB, patch)
2015-03-16 15:57 UTC, Florian Müllner
committed Details | Review

Description Matthias Clasen 2015-02-26 18:54:26 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 ?
Comment 1 Florian Müllner 2015-02-27 13:36:40 UTC
Almost certainly fallout from the popup patches in bug 744680.
Comment 2 Jakub Steiner 2015-03-03 16:44:03 UTC
Created attachment 298453 [details] [review]
theme: have a separate state for hover and focus
Comment 3 Jakub Steiner 2015-03-03 16:47:02 UTC
This separation of :hover and :focus has exposed an issue - when you hover with a mouse, sometimes items remain being focused afterwards...
Comment 4 Jakub Steiner 2015-03-03 17:49:59 UTC
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
Comment 5 Jakub Steiner 2015-03-03 18:14:30 UTC
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.
Comment 6 Matthias Clasen 2015-03-03 18:37:52 UTC
(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...
Comment 7 Matthias Clasen 2015-03-05 00:52:57 UTC
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.
Comment 8 Florian Müllner 2015-03-05 00:56:27 UTC
(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.
Comment 9 Matthias Clasen 2015-03-05 10:56:42 UTC
In retrospect, considering 1) - 4), it is probably better to go back to hover == focus in the menu.
Comment 10 Florian Müllner 2015-03-06 13:37:56 UTC
Or we could do what GTK+ does and make both set the other as well?
Comment 11 Florian Müllner 2015-03-11 18:21:50 UTC
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.
Comment 12 Florian Müllner 2015-03-11 18:23:22 UTC
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 ...
Comment 13 Jakub Steiner 2015-03-16 12:43:58 UTC
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.
Comment 14 Florian Müllner 2015-03-16 15:57:02 UTC
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 ...
Comment 15 Jakub Steiner 2015-03-17 14:15:16 UTC
YES!
Comment 16 Florian Müllner 2015-03-17 14:46:30 UTC
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