Closed Bug 1787930 Opened 5 months ago Closed 4 months ago

[HCM] Primary and secondary buttons look the same when either one is hovered

Categories

(Toolkit :: Themes, defect)

Desktop
Windows
defect

Tracking

()

RESOLVED FIXED
107 Branch
Tracking Status
firefox107 --- verified

People

(Reporter: ayeddi, Assigned: itiel_yn8)

References

Details

(Keywords: access, Whiteboard: [access-s3])

Attachments

(4 files)

STR:

  1. Activate High Contrast Theme (i.e. Night Sky on Windows OS or Increase Contrast on macOS)
  2. Open Manage Colors dialog under about:preferences > General > Colors
  3. Hover over the primary OK button, compare its appearance with the adjacent secondary Cancel button
  4. Hover over the secondary Cancel button, compare its appearance with the adjacent primary OK button.

Expected:

When either button is hovered, its hovered state is differentiable from the default appearance and it looks different than the adjacent non-hovered button:

  • For example, on Windows OS with "Night Sky" HCM theme enabled, when a primary button is hovered it has gray foreground and purple background while a secondary button retains yellow foreground and black background.

Actual:

When either button is hovered, its hovered state looks exactly as unhovered state of the adjacent button which makes it is hard to discern which button is, in fact, is hovered and will be activated on click, or if any button is hovered (especially for users with low vision and/or with cognitive difficulties):

  • On Windows OS with "Night Sky" HCM theme enabled, when a primary button is hovered both buttons have yellow foreground and black background - and vice versa
  • On macOS with Increased contrast with Dark theme, when a primary button is hovered both buttons have white foreground and dark gray background - and vice versa

It can be resolved by converting our primary and secondary button hover styles to use selected item colors:

  • SelectedItem for Selected Background
  • SelectedItemText for Selected Text / foreground
Whiteboard: [access-s3]
OS: Unspecified → Windows
Hardware: Unspecified → Desktop

I would like to work on this, but can you please run this by UX first? I remember there have been some disagreements around this topic before.

Flags: needinfo?(mreschenberg)
Flags: needinfo?(ayeddi)

Yes, we got approval on this from our design systems team (Jane and Jules).
Not sure if they have bugzilla accounts... looking

Flags: needinfo?(mreschenberg)
Flags: needinfo?(jwolf)
Flags: needinfo?(ayeddi)

While we're improving things here, how about making :hover:active show the inverted state of what's being suggested here for :hover? So SelectedItemText for background and SelectedItem for foreground?

:itiel I'm not familiar with that state combo/when it happens 😬 could you give me an example?

Flags: needinfo?(itiel_yn8)

Currently nothing changes in HCM in that state. The hovered state remains also when mousedown'ing a button.
STR is to enable HCM and mousedown any button in about:preferences. You'll see that the hovered state is the same as the mousedown state.

Flags: needinfo?(itiel_yn8) → needinfo?(mreschenberg)

:itiel, do edge or chrome currently have separate behaviour for this with HCM enabled?
I think what you're proposing is fine for buttons, though we should document it here

Flags: needinfo?(mreschenberg) → needinfo?(itiel_yn8)

(In reply to Morgan Reschenberg [:morgan] from comment #6)

:itiel, do edge or chrome currently have separate behaviour for this with HCM enabled?
I think what you're proposing is fine for buttons, though we should document it here

On Chrome there doesn't seem to be any hover effect, and on mousedown I faintly see the the usual ripple effect thingy.
On Edge the hover effect is the usual SelectedItem and SelectedItemText, and on mousedown the border changes to a certain non HCM-y color (the hover state's border is also a certain (different) non HCM-y color btw).

Flags: needinfo?(itiel_yn8)

This does look like what we discussed, I'm good to proceed with the option we outlined for the hover state.

Flags: needinfo?(jwolf)

(In reply to Itiel from comment #7)

(In reply to Morgan Reschenberg [:morgan] from comment #6)

:itiel, do edge or chrome currently have separate behaviour for this with HCM enabled?
I think what you're proposing is fine for buttons, though we should document it here

On Chrome there doesn't seem to be any hover effect, and on mousedown I faintly see the the usual ripple effect thingy.
On Edge the hover effect is the usual SelectedItem and SelectedItemText, and on mousedown the border changes to a certain non HCM-y color (the hover state's border is also a certain (different) non HCM-y color btw).

Sounds like we can do better :) I'm good with your proposal, happy to review and then update the wiki once it's in.

Assignee: nobody → itiel_yn8
Status: NEW → ASSIGNED
Attachment #9295002 - Attachment description: Bug 1787930 - Add SelectedItem / SelectedItem duo to hover and hover&active states on buttons r?morgan,gijs → Bug 1787930 - Add SelectedItem / SelectedItemText duo to hover and hover&active states on buttons r?morgan!,gijs

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dao+bmo)
Attachment #9295304 - Attachment description: Bug 1787930 - Apply the same changes everywhere else r?morgan!,gijs → Bug 1787930 - Correctly apply button hover and hover&active states in all of the in-content page r?morgan!,gijs
Pushed by itiel_yn8@walla.com:
https://hg.mozilla.org/integration/autoland/rev/9db72ddff199
Add SelectedItem / SelectedItemText duo to hover and hover&active states on buttons r=morgan,desktop-theme-reviewers,dao
https://hg.mozilla.org/integration/autoland/rev/aabddee50156
Correctly apply button hover and hover&active states in all of the in-content page r=morgan,desktop-theme-reviewers,dao
Pushed by itiel_yn8@walla.com:
https://hg.mozilla.org/integration/autoland/rev/589d7ef95a36
Apply the same changes to Reader mode toolbar buttons r=morgan
Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 107 Branch
Flags: needinfo?(dao+bmo) → qe-verify+

I was able to reproduce the issue on Win11 using Nightly build 106.0a1, verified as fixed on Win11 /Mac10.13 / Ubuntu 20.4 using Nightly build 107.0a1.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.