1865943 - The Address Bar suggestions' 3-dot-menu-button has a hover-styling that feels more "severe" than Firefox's other similar buttons/menus. (Its foreground/background fully flip between light/dark when hovered)

Status: RESOLVED WONTFIX

(Firefox :: Address Bar, defect, P5)

Description

[Daniel Holbert [:dholbert]]

STR:

1. Start Firefox with a fresh profile.
2. Type test search into the URL bar and hit enter, to do a Google Search.
3. Open a new tab and type test into the address bar.
4. Hover the suggestion for your previous test search query (shown with a little clock icon next to it)
5. Hover the 3-dot-menu-button for that address-bar suggestion (which appears at the right side of that entry when you're hovering the entry), and notice how the button changes.

ACTUAL RESULTS:

• The 3-dot-menu button initially renders with black dots over a light gray background.
• When hovered, it changes to white (or lightgray) dots over a black (or dark gray) background.
• Essentially, it feels like the foreground/background colors get swapped when you hover it, roughly.

EXPECTED RESULTS: For consistency with the rest of our UI...

• The dots probably shouldn't change color when hovered.
• The background should only get a little darker, not as severe of a light-to-dark change that it undergoes right now.

Other bits of our UI show "expected results" -- e.g. the buttons at the bottom of the address bar, the hamburger menu, the 3-dot menus for each theme on about:addons and for each open tab in Firefox view, and the 3-dot toolbar menus in DevTools.

I recognize that this menu is slightly different than those ones since it's in an area that's already darkened due to the row being hovered, but it feels like we still could make the hover styling a bit closer to the hover styling for our other 3-dot-menu buttons (and less severe than the full light-to-dark flip that it has now).

I'm using Firefox Nightly 122.0a1 (2023-11-21) on Ubuntu 22.04

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the bug (comparing this menu's hover-state to other similar menus)

Here's a screencast showing the hover state for the 3-dot-menu-button in question here, near the beginning of the screencast at around t=5s to t=8s (with the foreground/background colors swapping, essentially).

Then, to demonstrate the consistency issue, the screencast shows similar 3-dot-menu buttons in other parts of our UI, for which we just draw the background with a slightly darker color and don't change the foreground color (the color of the dots).

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast showing the same issue with dark theme

For completeness, here's a version of the screencast with our "dark" theme. The same consistency issue is present.

Comment 3

[Marco Bonardo [:mak]]

We could tone it down a little bit, but I must notice this is a button on a selected row that already has a shade of grey background, so the risk is for the effect (or the button border) to visually disappear.
I also don't think there's a spec for this very specific case of hover button on a selected row having lighter background. We'll ask our UX team members about it.

Comment 4

[Ryan Casey]

Marco is exactly correct here. The UX team, with guidance from A11y engineers, deviated from out normal hover patterns because this button appears in the highlighted row of a suggestion; a user cannot hover the dots menu in isolation without simultaneously hovering/selecting the search suggestion row. This fact, combined with a request by A11y to make it visually clear the button is being hovered over is what led us to the style deviation, which as the original designer on this project I stand behind. If we alter the hover state to the expected result stated above we lose the clear delineation A11y encouraged which can possible make it harder for some users to navigate the increasingly complex search suggestions in the drop-down. Unfortunately, I don't have the conversation with the A11y team, as it was a Slack thread that's been deleted.

Comment 5

[Dão Gottwald [:dao]]

Thanks Ryan. I also see no better way to handle this. Downgrading this further to P5 for now, but I think we might want to just close this as wontfix?

Comment 6

[Daniel Holbert [:dholbert]]

Thanks all! I'm fine with wontfix if this is working-as-designed/intended. I just filed since I noticed it as a visual inconsistency, but it sounds like there are intentional reasons for the inconsistency.