1852962 - Results Menu button has no distinct active state (it's the same as on hover)

Status: NEW

(Firefox :: Address Bar, defect, P5)

Description

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Attachment: rm issue

Notes

• Screencast attached;
• Suggesting S4 severity;

Found in

• Beta 118.0b8;

Affected versions

• Nightly 119.0a1;
• Beta 118.0b8;

Tested platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Affected platforms

• macOS 12;
• Windows 10;
• Ubuntu 22;

Unaffected platforms

• N/A;

Steps to reproduce

1. Launch Firefox.
2. Focus Address Bar.
3. Type any string in the Address Bar and submit the search.
4. Open a new tab and type the first few letters from the previously searched string.
5. Observe the results menu.
6. Hover over the result menu button.
7. Click on the result menu button.

Expected result

• Hover and Click states should have different behaviours.

Actual result

• Hover and Click states have the same behaviour.

Regression range

• Not a regression.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

:oardelean, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[Mandy Cheang [:mcheang][she/her]]

Dao, can you check with UX and a11y on the different colours to use for hover and active state of the result menu button?

Comment 3

[Josh Berman]

This is not a bug. According to the original specs, the icon button's hover/active state are the same.

https://www.figma.com/file/nERGz7C1gVcpQrGTkZefH2/Enriched-Suggestions-Design-Framework?type=design&node-id=957%3A10802&mode=design&t=eMFKY4d5gKwKHGjx-1

I don't think we need an active state outside the existence of the context menu that appears in the active state. Going to ask a11y for thoughts as well.

Comment 4

[Anna Yeddi [:ayeddi]]

(In reply to Josh Berman from comment #3)

This is not a bug. According to the original specs, the icon button's hover/active state are the same.

https://www.figma.com/file/nERGz7C1gVcpQrGTkZefH2/Enriched-Suggestions-Design-Framework?type=design&node-id=957%3A10802&mode=design&t=eMFKY4d5gKwKHGjx-1

I don't think we need an active state outside the existence of the context menu that appears in the active state. Going to ask a11y for thoughts as well.

The active state is kind of a gray area under the WCAG 2.1 Success criterion 1.4.11 Non-text contrast, since it is a state of a control, but it is not explicitly mentioned in the "state" definition.

Since the result of a click is the menu shown, it is not a blocker for sure. But we ideally want to have a distinct :active state communicated to a user. In the past we've settled for active state being the same as non-hover (see: links in HCM), if similar would be an easy fix, that would work in this (menubutton) case.