Open Bug 1704347 Opened 8 months ago Updated 12 days ago

regression: it's less easy to distinguish the current tab since activation of proton

Categories

(Firefox :: Theme, defect, P2)

Firefox 89
defect

Tracking

()

Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- affected
firefox87 --- unaffected
firefox88 --- unaffected
firefox89 --- wontfix
firefox90 --- wontfix
firefox91 + wontfix
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox96 --- affected

People

(Reporter: foss, Unassigned, NeedInfo)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: access, regression, Whiteboard: [proton-tabs-bar] [priority:2c] [access-s2])

Attachments

(4 files)

Hello,

I'm Using Debian GNU/Linux 10 with the GTK3 built-in HighContrast theme.

I'm a low-vision person and sensible to contrast issue.

Steps to reproduce:
0) I don't reproduce this under Windows because on Windows Firefox doesn't currently apply properly the HighContrast theme (I'll fill a bug about this later).
(I don't have a mac to check)

  1. Set the HighContrast theme (on GNOME, I assume you should use GNOME Tweak, on the Mate desktop you can use mate-appearance-properties, for other desktop environment I don't know)
  2. Start Firefox Nightly

Result with Nightly with proton enabled:
The active tab has just a depth effect on it. With many tabs opened, I no longer can determine which tab is the active one.

Result before proton enabled:
A colored line appears on the top of the current tab which makes it really easy to distinguish.

Mozregression gives me this:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8aa1b80a8c6b66cccc2e37080fbf6197eee8d801&tochange=1716229005d8b97f305bd663b8bc8d3fec4a4f3a

Thanks in advance.

Regressed by: 1700109
Keywords: access
Whiteboard: [proton-tabs-bar]
See Also: → 1704131

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

Priority: -- → P2
Whiteboard: [proton-tabs-bar] → [proton-tabs-bar] [priority:2c]
Duplicate of this bug: 1704131

The other bug is older and has more info, this should not be duped.
Edit: This also seems to describe a different issue. bug 1704131 is about active/inactive windows not tabs.

Just to add that Alpenglow (dark) has the active button's border highlighted which is pretty much what's missing in Dark theme

Whiteboard: [proton-tabs-bar] [priority:2c] → [proton-tabs-bar] [priority:2c] [access-s2]
Duplicate of this bug: 1706400

Asa, can you please help assess if we're good per our accessibility goals here?

Flags: needinfo?(asa)

This is specially an issue with container tabs fwiw, because those have a highlight which before proton was on the active tab.

Especially on the dark theme - even without containers it's harder to find active tab if you have a lot of tabs opened. And with containers it's just crazy confusing.
This picture is from this thread:
https://www.reddit.com/r/firefox/comments/mwy4o8/my_biggest_complaint_about_proton_ui_is/
(350+ votes)

For me the most problematic thing is that devs repurposed line above tab to mean "this tab runs in a container". But right until this point only active tab had this "line". I will for sure have problems, because "muscle memory" will always cause me to thing I'm on tab with line above it :(

It would be better if they left container indicator below tab like it was before, or think of something else, but don't reuse style from active tab, and make it mean something completely different.

Duplicate of this bug: 1707307
Duplicate of this bug: 1707374

The last to dupes also show the problem with a dark theme especially in combination with containers.

(In reply to mikaka27 from comment #10)

For me the most problematic thing is that devs repurposed line above tab to mean "this tab runs in a container". But right until this point only active tab had this "line". I will for sure have problems, because "muscle memory" will always cause me to thing I'm on tab with line above it :(

It would be better if they left container indicator below tab like it was before, or think of something else, but don't reuse style from active tab, and make it mean something completely different.

That's exactly it. I have the same issue, and multiple times I've clicked on the current active tab and thought to myself "why isn't it changing?" only to realize that I was confusing my container tab for the active one, and changing to the already selected tab wouldn't do much...

Even a small change like moving the container indicator the bottom does wonders. As an example, I'll leave this userChrome.css modification by a user on reddit: https://old.reddit.com/r/FirefoxCSS/comments/mvrkrj/fix_container_mark_location_in_the_tab_bar/gvigcz3/

that said, there is a lot of discussion on userChrome right now, haha

Duplicate of this bug: 1707722
Duplicate of this bug: 1709342
Duplicate of this bug: 1707098

Several bugs reporting usability and accessibility issues with the new design and the parent issue is closed as 'wontfix' with no comment. Sorry to say so but I hope Proton's design problems really blow up once 89 is released publicly. I usually respect opinionated design but Mozilla's silence on Proton's design and its problems is cowardly and only supports the general suspicion that there is little reasoning behind the design decisions.

(In reply to Jan from comment #19)

Several bugs reporting usability and accessibility issues with the new design and the parent issue is closed as 'wontfix' with no comment. Sorry to say so but I hope Proton's design problems really blow up once 89 is released publicly. I usually respect opinionated design but Mozilla's silence on Proton's design and its problems is cowardly and only supports the general suspicion that there is little reasoning behind the design decisions.

Look better, the bug is not closed. It has been decided it will not be fixed for 89.

There is still room for improvement but we've been through a couple of rounds of design on this and the contrast meets our accessibility goals for 89.

Flags: needinfo?(asa)
Duplicate of this bug: 1712891
Duplicate of this bug: 1714056
Duplicate of this bug: 1713991

(In reply to Asa Dotzler [:asa] from comment #21)

There is still room for improvement but we've been through a couple of rounds of design on this and the contrast meets our accessibility goals for 89.

Contrast ratio between active/inactive tabs background colors is 1.14:1 for light mode, and 1.70:1 for dark mode, while WCAG requirement for active user interface components is 3:1 (AA).

Your accesibility goal is different than WCAG?

The reason for me to wrongly recognize the active tab is not about contrast ratio, but because the inactive tabs and the tabline have more similar color to the content part. The highlighted active tab is so different and disconnected / floating that my brain thinks it belongs to something else.

(In reply to lilydjwg from comment #26)

The reason for me to wrongly recognize the active tab is not about contrast ratio, but because the inactive tabs and the tabline have more similar color to the content part. The highlighted active tab is so different and disconnected / floating that my brain thinks it belongs to something else.

contrast makes sense, just for example, this theme fixes the issue for me (comparing to default dark theme): https://clck.ru/VG4FS
if active tab has different background color in tab menu, it is difficult to confuse active tab with inactive (but at the same time creates different problem: to determine what container the active tab belongs)

You could install Firefox Color. It allows you to customize the color of every part of the UI. I fixed the contrast issue with it.

https://color.firefox.com/

Duplicate of this bug: 1714758

This one causes issues for me as well, and I have fairly decent vision. It also affects System and Light themes.

I know there's an about:config option for these, but I assume that's temporary while users are migrated. Will there be a "Firefox Classic" theme that can be applied if people prefer the old appearance(s)? Do themes even support that sort of change?

This seems significantly more problematic using a light theme, and using containers. Here is how my system looks after the update, for example.

(In reply to manwithbundleofsticks from comment #33)

This seems significantly more problematic using a light theme, and using containers. Here is how my system looks after the update, for example.

Image of my tabs

Duplicate of this bug: 1716162
Duplicate of this bug: 1716522

[Tracking Requested - why for this release]: This seems to be a common accessible issue especially for people with poor vision or bad monitors.

(In reply to Stickman from comment #33)

This seems significantly more problematic using a light theme, and using containers. Here is how my system looks after the update, for example.

Yes, I first saw this with the Light theme and had a lot of trouble with it for the same reasons.

(In reply to Claude Gohier from comment #29)

You could install Firefox Color. It allows you to customize the color of every part of the UI. I fixed the contrast issue with it.

https://color.firefox.com/

While this extension looks great, it doesn't really fit my needs; I'm fairly happy with the defaults in everything except the current tab. With Firefox Color, it appears to have it's own "default", with no way to simply change one element; I would have to change ALL elements back to "system default" to accomplish what I want.

Definitely still struggling to distinguish current tab, several weeks later.

You can create a theme yourself, tweaking only the colors you want to change, except that the theme docs haven't been updated to proton yet so some guesses are needed.

(In reply to lilydjwg from comment #41)

You can create a theme yourself, tweaking only the colors you want to change, except that the theme docs haven't been updated to proton yet so some guesses are needed.

What I mean is, even when making my own theme, the "custom colors" has presets. The "advanced colors" allows me to select "firefox default", but changing a single value in the advanced colors applies all values in "custom colors".

Regardless, I think that the default behavior should be adjusted anyway. I don't think installing an Extension should be a requirement just to visually determine which tab is active (although I thank you for the suggestion to solve the problem until the bug is fixed).

(In reply to blakegearin from comment #43)

Marking as wontfix without comment again? Disappointing to say the least.

That is simply recording the fact that this bug won't be fixed in time for Firefox 90, it doesn't say anything about the bug itself (which stays open).

Duplicate of this bug: 1718805
Duplicate of this bug: 1713832
Duplicate of this bug: 1718805
Attached image real world example

Let's look at some real world example from my office.
From where I sit, I can't tell which tab is active. The monitor a bit up and it uses TN technology so looking at it from below makes everything a bit darker than it is.

Duplicate of this bug: 1723893

I'm not so sure if my bug is a duplicate of this bug. My bug was that selected tabs look the same as the active tab. There is a very slight difference in colour that I only found out about by using an eyedropper.

The colour of the active tab isn't relevant to my issue although I don't understand why Firefox isn't respecting my Windows setting to show colour in titlebars anymore.

(In reply to lilydjwg from comment #41)

You can create a theme yourself, tweaking only the colors you want to change, except that the theme docs haven't been updated to proton yet so some guesses are needed.

My bug 1704131 was incorrectly (my opinion) marked as dupe of this one. I don't have issue with the color choices (or lack thereof) or the contrast problems described here, so much as the tab is now a button and no longer a tab and thus is disconnected from the active content. A real, traditional tab, would be discernible as active even in black and white or any two color scheme.

Any idea how to restore a traditional Tab rather than have floating buttons?

Seems one can't edit a comment. As a correction to comment 55, my correct number is bug 1706400, not bug 1704131.

(In reply to adrien.monteleone from comment #55)

My bug 1704131 was incorrectly (my opinion) marked as dupe of this one. I don't have issue with the color choices (or lack thereof) or the contrast problems described here, so much as the tab is now a button and no longer a tab and thus is disconnected from the active content. A real, traditional tab, would be discernible as active even in black and white or any two color scheme.

Any idea how to restore a traditional Tab rather than have floating buttons?

This is a very good point. I am having trouble with the color theme, yes, but I would also be interested in getting real tabs back as that's also a major issue. I suspect this entire series is actually several related bugs that perhaps should be handled individually? I worry that nuance and the real issues are being confused by being in one single issue that technically isn't the same problem. The reporter's issue is a contrast issue in a particular theme, and the other people commenting have all sorts of additional complaints, and I'm worried the eventual solution will be "none of the above."

I could break out the tab-vs-button issue if it wouldn't just be re-merged. Thoughts?

(In reply to rcandres from comment #57)

(In reply to adrien.monteleone from comment #55)

My bug 1704131 was incorrectly (my opinion) marked as dupe of this one. I don't have issue with the color choices (or lack thereof) or the contrast problems described here, so much as the tab is now a button and no longer a tab and thus is disconnected from the active content. A real, traditional tab, would be discernible as active even in black and white or any two color scheme.

Any idea how to restore a traditional Tab rather than have floating buttons?

This is a very good point. I am having trouble with the color theme, yes, but I would also be interested in getting real tabs back as that's also a major issue. I suspect this entire series is actually several related bugs that perhaps should be handled individually? I worry that nuance and the real issues are being confused by being in one single issue that technically isn't the same problem. The reporter's issue is a contrast issue in a particular theme, and the other people commenting have all sorts of additional complaints, and I'm worried the eventual solution will be "none of the above."

I could break out the tab-vs-button issue if it wouldn't just be re-merged. Thoughts?

Sorry. I thought I had a correction note posted but I don't see it now. Mine was bug 1706400, which documents the tab-vs-button problem. (not bug 1704131, which is something else) 1706400 was incorrectly marked as a dupe. It just needs to be re-opened.

Duplicate of this bug: 1727983

I am the reporter of the #1727983 duplicate, and I would like to add that autistic people might also be affected by this change in design. Reading the bug history, I feel like disabled people are not much heard and consulted in the design process, which seems to be a major issue of concern for the disabled community.

As I stated on my dup report, I was not personally affected because I use containers for everything, but other autistic people, like a friend of mine who switched browser because of that, might have faced challenges, including the potential to be even harmful for us (i.e. cause a sensory crisis).

If possible, could I learn more about how design change decisions are made and if possible how to get involved so I could propose better mechanisms to prevent such changes before they happen? Considering that, of course it's an open source software and there is no obligations, but disabled people are a vulnerable group and when something don't work properly for us it's harder to seek alternatives, since not much people care about our needs (i.e., autistic people affected by this issue might also suffer with the way tabs work on Chrome, as they barely appear when you open a certain number, and we also struggle a lot with changes) and they will likely take much time to be fixed (not anyone's fault, but it's a fact that the whole society takes too much time to solve accessibility issues).

Thanks if anyone could point me a direction.

Flags: needinfo?(dao+bmo)
Duplicate of this bug: 1734885
Duplicate of this bug: 1735752
You need to log in before you can comment on or make changes to this bug.