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.

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

see also https://bugzilla.mozilla.org/show_bug.cgi?id=1703789

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

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

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.

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

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.

(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)

Is there a simple way to fix this contrast issue without installing stuff from third parties?

I would also like to point out the hundreds of people complain about this issue on Reddit:

https://www.reddit.com/r/firefox/comments/nqjjc9/for_someone_with_visual_issues_keratokonus_this/
https://www.reddit.com/r/firefox/comments/nqrqew/i_was_openminded_on_this_one_but_no_tab/
https://www.reddit.com/r/firefox/comments/nqh6sk/can_we_please_get_tab_differentiation_back/
https://www.reddit.com/r/firefox/comments/nqh2a8/why_in_the_name_of_god_would_they_get_rid_of_tabs/
https://www.reddit.com/r/firefox/comments/nqtzcn/can_we_discuss_actual_usability_and_accessibility/
https://www.reddit.com/r/firefox/comments/nqt1jt/firefox_thanks_for_the_dark_theme_but_i_cant_tell/

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/

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

[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).

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.

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.

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.

(In reply to Vladislav from comment #25)
...

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).
...

Using Firefox 95.0.2 (64-bit) (the about dialog box says 'up-to-date') in Dark Mode under Windows 10 the default active tab behavior is unacceptably subtle for even those such as myself who are acutely color or contrast sensitive when multiple tabs are present for the reasons best explained by Vladislav above.

The simplest temporary workaround so far has been to install "Simple Fox Theme", which is the ONLY add on I have found capable of making a stark contrast (Halloween Orange against Black) in active tab color, enabling 'at-a-glance' active tab visibility. Obviously this is a common need as this theme is trending despite the inexplicably huge non-descript orange swirl in the right upper title and menu bar.

Please consider making the active tab contrast dramatically higher (as in the Simple Fox Theme) by default, even for normally visioned persons such as myself. There is no need for subtlety in user interface.

Obviously not all bugs can be fixed, so focus has to be made on security, speed, and usability.
FF is now extremely complex and the list of critical bugs that have been fixed already is impressive.

However if there happened to be programmers interested in the user interface usability (such as this "wontfix" tab contrast issue), where they begin to gain knowledge and experience with this Open Source project and specifically FF User Interface design?

I'm sure there are many who might be inspired to improve the look and feel and usability that are not as interested in TLS or caching speed.
Please don't delete this as advocacy as it is a genuine question and expression of interest in helping. IMHO it is a usability issue right up there with page loading speed. Thanks in advance.

This joke of pushing to next version is hilarious and sad at the same time.

such as this "wontfix" tab contrast issue

This Bugzilla ticket is still open and was not wontfix'ed. Only the status for Firefox 96 was set to wontfix because the first release candiate of Firefox 96 was already built. Since there is no patch attached to this Bugzilla ticket and nothing landed in Firefox Nightly yet, it's simply not possible that something will change with the release of Firefox 96 in a few days. This status change doesn't say anything about a future change, it just reflects the reality - it's too late for Firefox 96.

(In reply to Sören Hentzschel from comment #71)
..

This Bugzilla ticket is still open and was not wontfix'ed. Only the status for Firefox 96 was set to wontfix because the first release candiate of Firefox 96 was already built. Since there is no patch attached to this Bugzilla ticket and nothing landed in Firefox Nightly yet, it's simply not possible that something will change with the release of Firefox 96 in a few days. This status change doesn't say anything about a future change, it just reflects the reality - it's too late for Firefox 96.

This is strangely comforting and disturbing. Comforting in that there is still hope that this issue may be fixed eventually.
But somewhat disturbing in that it seems like it would not be too difficult to change a few hexadecimal (or RGB) values in the Active Tab settings and be done with it! But coming from a Web development background probably doesn't accurately reflect app design processes. Nevertheless, I see others above are willing to learn and help in this. I consider myself able bodied, normal vision, and moderately tech savvy, but because I use a lot of tabs, sometimes the color and brightness contrast of the active tab is the crucial only clue to where I am in the interface. That contrast is lacking by default.

(In reply to design2 from comment #72)

(In reply to Sören Hentzschel from comment #71)
..

This Bugzilla ticket is still open and was not wontfix'ed. Only the status for Firefox 96 was set to wontfix because the first release candiate of Firefox 96 was already built. Since there is no patch attached to this Bugzilla ticket and nothing landed in Firefox Nightly yet, it's simply not possible that something will change with the release of Firefox 96 in a few days. This status change doesn't say anything about a future change, it just reflects the reality - it's too late for Firefox 96.

This is strangely comforting and disturbing. Comforting in that there is still hope that this issue may be fixed eventually.
But somewhat disturbing in that it seems like it would not be too difficult to change a few hexadecimal (or RGB) values in the Active Tab settings and be done with it! But coming from a Web development background probably doesn't accurately reflect app design processes. Nevertheless, I see others above are willing to learn and help in this. I consider myself able bodied, normal vision, and moderately tech savvy, but because I use a lot of tabs, sometimes the color and brightness contrast of the active tab is the crucial only clue to where I am in the interface. That contrast is lacking by default.

That's the strange part. To the best of my knowledge, it actually IS a few RGB values to change. It could even be patched by adding an official "Theme" with more contrast (or just changing the existing ones that have the low-contrast problem). My personal preference is for something like the old tab format, where it attached to the window and had a lit stripe too (for more visual changes than merely a color) which is more complex, but even that can be done by switching the user chromes, as shown by several github projects that attempt to fix this.

Perhaps it's officially a lower priority because you can download a theme or change the chromes, but to a new user or even a regular, non-power-user, it is a massive appearance issue that makes the browser look bad and might convince people to quit using Firefox.

I suspect it's a business decision, personally. Clearly some effort went into making the new appearance (even difficult to distinguish as it is), and I suspect that as a result the group that normally manages the UI doesn't want to switch it back (or even make a minor color change...? That part is odd). It strikes me as strange, though, because some degree of effort was put into changing it to this and I'm not sure why those people can't fix up the resulting issues it has caused.

I will also bring the Colorways themes into the discussion as well. That was a set of numerous additional "official" themes released in place of fixing this problem, with some degree of additional work to add that fancy introductory selector window, which to the best of my knowledge only appears once, ever!

Now, I'd personally consider those themes as being an actual fix, but they are stated as temporary and I expect that they will disappear any moment now. I can't even rule out their deletion from my existing system at any time even if I'm using one (say, I install another theme to try, it switches away from the Colorway theme, and then it's gone too). I also will not be able to use them on new/future installations of Firefox as, again, they are temporary. So, this was a "fad" project that took up development time from the very people who could fix this problem, and might even have helped, but it's going to be removed soon instead!

(In reply to rcandres from comment #73)
...

That's the strange part. To the best of my knowledge, it actually IS a few RGB values to change. It could even be patched by adding an official "Theme" with more contrast (or just changing the existing ones that have the low-contrast problem).
....
Now, I'd personally consider those themes as being an actual fix, but they are stated as temporary and I expect that they will disappear any moment now. I can't even rule out their deletion from my existing system at any time even if I'm using one...

Exactly! Time and again add ons/extensions become incompatible or removed from the latest iteration of FF.
My only additional comment is that almost NONE of the themes have high contrast and color contrast. The only one I found was Simple Theme but it has a strange huge orange logo on the right upper corner.

Ideally, one would be able to download a theme, then tweak only the items one wanted, and save that as a new theme. Using XML or JSON to remember the RGB values seems like it would be pretty trivial. The hard part would be creating the dialog to ask the user and display color wheels or swatches, but certainly these dialogs could be repurposed from elsewhere in the Open Source world.

I think it might be interesting to add some more info about bu #1727983 (marked as duplicate of this one) so it doesn't get lost along the interactions of this bug here.

The bugs are somewhat similar, but with different behaviors. While this bug here states that it's "less easy"[1] to distinguish the active tab, in #1727983 the main complain is that ALL TABS not in a container are really hard to distiguish from each other[2].

Furthermore, @dao / @asa, can this bug be moved to the Disability Access component, since this IS a user interface bug that affects the experience of people with disabilties (as seen in several comments of people of multiple disabilities)? I think with the proper categorization it will be visible enough to get some attention from the accessibility maintainers/developers.

[1] "Less easy" is not appropriate for it's an euphemism that seems to invalidate the struggle of some disabled people who find it really difficult to distinguish them. The proper word should be "HARDER". I'd suggest changing the bug's title.
[2] I'll attach he image from the other bug in the sequence.

The image showcasing the related bug marked as duplicate of this one.

Bug #1714766 was closed and the comment says it will be addressed in this ticket.

I want to make it clear that the other bug was about tab separators and this bug is about identifying the current active tab. Since that bug is now closed, I will address my concerns here. There was a comment posted recently saying:

Our focus however is going to be more about improving contrast vs the separation concern, as we think this will naturally resolve some of the same issues.

Higher contrast can help the active tab stand out, but we still need tab separators. One big issue I have with the current design is that it's impossible to identify the clickable area for pinned tabs. It's especially problematic because there is a small non-clickable gap between the pinned tabs and the regular tabs with no visible indicator where that gap is.

The old design was clear and unambiguous. I would like to see this level of clarity return. Because the other ticket is closed, I'm posting this here to make sure this concern is also addressed with whatever new design you are working on.

Severity was still not set here, but this looks like an S2 given the accessibility rating and the severity of duplicate or blocked bugs. Feel free to revert my change if you disagree.

If anyone who has severe difficulty to distinguish currently selected tab, you can install Firefox Color extension and change Tab Highlight Color like this.

In reply to Comment #82,

I'm aware of the extension. I do not personally consider this a "solution" as the level of customization is limited.

• The tab borders are extremely thin and nearly invisible, so I have to change the primary tab color. One of the main features of the old look was that the indicator was thick and clearly visible.
• The defaults are still nearly imperceptible in their differences. I have to fully customize, which is hard since I'm not an aesthetic person. The results work, but look bad.
• There is still no differentiation between non-selected tabs
• I can't (personally) figure out how to manage my created themes without creating a new one first.

Also, to me, the biggest issue is that it's an extension. It needs installation. Users need to know about and find it. It just feels "third party" and "unofficial" for all that it's made by the Firefox team. I'd be much happier if it were built into Firefox, probably in the theme menu.

I would agree with all the points - I've added the add-on just now but it's not a good solution.
Can I add a general point that designers across the board in software seem to be making interfaces harder and harder to use by removing the instinctive ability to distinguish GUI parts: buttons that used to be colourful are made monochrome, dividing indicators between sections removed, different things changed to be the same colour, or at times made rotationally similar. This is a real usability and productivity drag and extremely frustrating since both unnecessary and also absolutely flies in the face of what is natural for ordinary humans to find usable - people generally like colour and contrast, though the exact degree may vary; usually moderate colour and contrast is the best default.
d

Let me ensure i get it right.

You found out that problem is the low contrast ratio in both themes.
Your decision: change contrast ratio, to reach needed effect (users to be able to distinguish active/inactive tabs).
Your proposal: change contrast ratio from 1:1.14 to 1:1.17 (0.03 ratio points) for light theme, and from 1:1.7 to 1:2.22 (0.52 ratio points)

You get that this does not solves problem (considering your comments "Fail, but better"), but still propose it.

Correct me if I'm wrong?

(In reply to Vladislav from comment #86)

Correct me if I'm wrong?

The new design bolds the title of the active tab, a shape change which goes beyond color contrast as a signal.

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

(In reply to Vladislav from comment #86)

Correct me if I'm wrong?

The new design bolds the title of the active tab, a shape change which goes beyond color contrast as a signal.

I haven't even noticed it.
If we have many tabs, it causes tab title to shrink, so we see about 2-2.5 letters of the tab title.
Do you think making 2.5 letter bolder + increasing ratio to 0.03 ratio points (for light theme) is enough?

(In reply to Vladislav from comment #86)

You found out that problem is the low contrast ratio in both themes.
Your decision: change contrast ratio, to reach needed effect (users to be able to distinguish active/inactive tabs).
Your proposal: change contrast ratio from 1:1.14 to 1:1.17 (0.03 ratio points) for light theme, and from 1:1.7 to 1:2.22 (0.52 ratio points)

The proposal also includes updating the toolbar background to better link the active tab to it.

You get that this does not solves problem (considering your comments "Fail, but better"), but still propose it.

Sort of, yes. It's an improvement and the door isn't necessarily closed to further improvements down the road.

I'm not sure why the question even comes up, it's a no-brainer that reasonable contrast and colour should be the default in all things as it suits the most people. Developers had it right a decade ago. You have to remember you have things like sunshine falling on the screen at times, contrast is absolutely required. If nothing else, there could be a contrast slider so people can choose their own level but failing that just have a medium level of contrast in everything that needs to be distinguished.
d

Backed out changeset 0294fd3e0304 (Bug 1704347) for causing bc failures on browser_html_detail_view.js.
Backout link
Push with failures <--> bc1
Failure Log

(In reply to Vladislav from comment #88)

Do you think making 2.5 letter bolder + increasing ratio to 0.03 ratio points (for light theme) is enough?

Making a shape change absolutely is a significant improvement. Is it all we can do? No, we can do more and we will either leave this issue open or morph it to cover the work we have done and create a new issue where we can consider potential future work.

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

(In reply to Vladislav from comment #88)

Do you think making 2.5 letter bolder + increasing ratio to 0.03 ratio points (for light theme) is enough?

Making a shape change absolutely is a significant improvement. Is it all we can do? No, we can do more and we will either leave this issue open or morph it to cover the work we have done and create a new issue where we can consider potential future work.

This bug will be closed automatically once the patch has landed. Please file new bugs for further ideas, suggestions, or problems you see.

https://hg.mozilla.org/mozilla-central/rev/453ff691bcdf

Is this intentional? Looks a bit weird in dark mode imo. I'm not seeing anything else that's black in the whole theme, which makes these ones feel like errors if you didn't know better.

The urlbar is also barely distinguishable when not focused, not necessarily a huge issue but worth pointing out since it sounds like contrast was the motivation for these changes

(In reply to Pulsebot from comment #98)

Pushed by ctuns@mozilla.com:
https://hg.mozilla.org/mozilla-central/rev/453ff691bcdf
Implement revised toolbar and selected tab background colors, and make the
selected tab label bold. r=Itiel,sfoster

== Change summary for alert #36613 (as of Tue, 27 Dec 2022 13:42:00 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36613

There is only a limited time to fix the regression caused by this bug until soft freeze (January 12).

(In reply to Tom S [:evilpie] from comment #102)

There is only a limited time to fix the regression caused by this bug until soft freeze (January 12).

I'm aware. My current plan is to back this out from 110 Beta if Product and UX are still undecided about if and how we'll address the regressions.

Let's go ahead and back it out. Thanks Dao. We'll run the Diary Study and use that to determine the next iteration forward. Glad we got a chance to get feedback on this in Nightly first.

Backed out as per dao's request.

Backout link

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/7968ae37c117d4be0e81c8843cd1b2b283129791

(In reply to Sandor Molnar from comment #106)

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/7968ae37c117d4be0e81c8843cd1b2b283129791

== Change summary for alert #36706 (as of Mon, 09 Jan 2023 13:21:34 GMT) ==

Regressions:

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36706

(In reply to Sandor Molnar from comment #106)

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/7968ae37c117d4be0e81c8843cd1b2b283129791

== Change summary for alert #36722 (as of Thu, 12 Jan 2023 10:36:04 GMT) ==

Regressions:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=36722

(In reply to Ray Fambro from comment #104)

Let's go ahead and back it out. Thanks Dao. We'll run the Diary Study and use that to determine the next iteration forward. Glad we got a chance to get feedback on this in Nightly first.

Following to see if there's a decision about moving this forward.

Hello -- I've transitioned this work over to our A11y PM team. Asa and/or Kim should be able to prioritize the path forward here accordingly.

Asa put this as #1 on a "top 100" list of papercuts and enhancements he recently drafted. I need to check with A11y engineering and another PM to make sure this is: a) still scoped and prioritized correctly against all the other items in the queue and b) not going to be solved by a different product team's H2 work. Will update here as soon as I have the info on how we're proceeding.

Confirmed: this is #1 on our list of a11y fixes.
Related: some of our a11y customers have deliberately chosen to stick with an older version of Fx so that they can continue to use previously available a11y options. However, they are being forced to upgrade as other software/AT in their a11y toolbox deprecates support for older Fx versions. In other words, there is a definite risk of losing a11y customers, and we need to address this with some urgency. (example: https://connect.mozilla.org/t5/discussions/what-s-the-status-of-post-proton-accessibility/m-p/34393/highlight/true#M12540)

solution to current tab visibility

What exactly is the "solution" in your screenshot? The blue line? It's always helpful to add a comment instead of just posting images without any explanation. Such a line would conflict with the colored line of containers in Firefox.

(In reply to Sören Hentzschel from comment #116)

What exactly is the "solution" in your screenshot? The blue line? It's always helpful to add a comment instead of just posting images without any explanation. Such a line would conflict with the colored line of containers in Firefox.

Current tab visibility has much more priority than those called containers, it would be intuitive to mark the current tab with a solid blue line, and add small colored circles or squares to mark used containers.

(In reply to Sören Hentzschel from comment #116)

I recall that even KDE Plasma desktop had the same problem of how to make the current selected tab much more visible, and they finished by marking the current tab with a colored line that matches the theme's color.
https://invent.kde.org/plasma/breeze/-/merge_requests/76

(In reply to med medin from comment #117)

(In reply to Sören Hentzschel from comment #116)

What exactly is the "solution" in your screenshot? The blue line? It's always helpful to add a comment instead of just posting images without any explanation. Such a line would conflict with the colored line of containers in Firefox.

Current tab visibility has much more priority than those called containers, it would be intuitive to mark the current tab with a solid blue line, and add small colored circles or squares to mark used containers.

I think this is correct. Containers aren't even a shipping feature, they're Nightly only. The overline or underline in tabs existed in the earlier Firefox theme and was a solid solution providing a pretty good indication of the active tab, though not necessarily defining the click/touch target boundaries very well.

I've been absent on this issue recently but have returned and will be working with our designers to improve this.

I think this is correct. Containers aren't even a shipping feature, they're Nightly only.

While it's true that they are disabled by default (but can be enabled via about:config) they are automatically enabled when certain add-ons are used, including some add-ons from Mozilla, like Firefox Multi-Account Containers and Facebook Container.