1705306 - Hard to tell that back and forward buttons are active

Status: RESOLVED INVALID

(Firefox :: Toolbars and Customization, defect, P5)

Description

[Asif Youssuff]

Noticed this a few days ago and soldiered on for a few days, trying to see if I would get used to it or if it was going to be improved.

Steps to reproduce:

1. Open Firefox
2. Go to any page
3. Go to any other page (same tab)
4. Look at the back and forward buttons in the toolbar

What happens:

The back and forward buttons are very thin, especially in comparison to the refresh icon and do not look sensitive to user input. They essentially look grayed out.

It is not an unexpected occurrence to need to see that the back button is disabled or insensitive to user input. I use containers, and there are times when a new tab is opened to ensure that a page opens in a new container segregated from the page it was opened from. That new tab has no back history or stack, and the correct action to get back to the originating tab is to go back to the tab the new page was opened from. I can do that very easily by using ctrl-shift-tab, but if I glance at the back button in the omnipresent toolbar, I am confused as to whether there is a back stack. The UI is not helping me be aware of what is happening here, and I instead need to mouse over the button in a mystery-meat-navigation kind of way to find out whether the control is sensitive to user input, instead of acting as an affordance.

Expected result:

Back and forward buttons should be easier to see that they are sensitive to user input. At times, it is even hard to see the difference between the icons even when there are no pages to move forward to (and the back button is active), making me unsure of whether I can use the button.

16:57.83 INFO: Narrowed integration regression window from [ca8aff82, 20cbe7fb] (3 builds) to [ca8aff82, f1601413] (2 builds) (~1 steps left)
16:57.83 INFO: No more integration revisions, bisection finished.
16:57.83 INFO: Last good revision: ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3
16:57.83 INFO: First bad revision: f160141317e9c764ac698e7dab08c36820e7e922
16:57.83 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ca8aff8285cadc7fb74b0f05676ebcd98b4f77d3&tochange=f160141317e9c764ac698e7dab08c36820e7e922

Comment 1

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

Set release status flags based on info from the regressing bug 1686527

Comment 2

[:Gijs (he/him)]

Sam, can you forward this to the right UX person?

Asif: on what platform/OS are you seeing this, and with what theme? Without any detail it's hard to know what you're talking about.

Comment 3

[Asif Youssuff]

Apologies, I am running Firefox on Linux with the Adwaita theme. I am running with a GNOME 3.38.5 session on Ubuntu 21.04.

Comment 4

[Sam Foster [:sfoster] (he/him)]

:Asif, would you be able to attach a screenshot so I know for sure we are looking at the same thing?

Comment 5

[Asif Youssuff]

Attachment: back active.png

Comment 6

[Asif Youssuff]

Attachment: all active.png

Comment 7

[Asif Youssuff]

Attachment: none active.png

Comment 8

[Asif Youssuff]

Sam, I attached some images. Hope they help.

Comment 9

[:Gijs (he/him)]

From the screenshots, the contrast ratio between the foreground enabled (#2e3436 from the screenshot) + disabled (#a8a8a8 from the screenshot) colours here is 5.32, which is WCAG AA standard even for being able to read small text (and the contrast would be larger when comparing enabled colour vs. background). The icons are bigger than some letters at the 18px sizing that WCAG consider "large" text (for which this contrast would pass at AAA standards).

I also expect that the colours on Linux may come at least in part from your OS theme, so it's not clear to me we could do much even if the colours were less contrastful.

On the whole, I just don't think there's a bug to be fixed here.

Comment 10

[Asif Youssuff]

Gijs, the icons look better to me now, and I suspect that it is due to bug 1705849 being fixed. I'm not sure why the computed contrast would measure this as easy to discern, but I don't think that is the intended purpose of computing contrast in the first place - sure, text or widgets set with this contrast ratio might be "readable", but I think the more salient question is whether it is both readable and different enough from the active state to not confuse the viewer of the widget.

I didn't say that the button was hard to see - it was simply hard to differentiate between the active and inactive states. I think the diagnosis of this as "invalid" is incorrect, because I think you were focused on the wrong problem - which I think is better left to user testing (like my report!) rather than a computed value of contrast.