Fix 1822: Sync container colors with Firefox container settings

[nekno]

• I agree to license my code under the MPL 2.0 license.
• I rebased my work on top of the main branch.
• I ran npm test and all tests passed.
• I added test coverages if relevant.

Description

This PR fixes #1822, which captures the issue well.

Firefox allows 9 container colors, including a toolbar color that matches the current text color in light and dark modes.

The extension currently only supports 8 of those colors, omitting the toolbar color. That allows users to set a color in the Firefox container settings that doesn't appear or allow editing properly in the extension container settings.

This PR adds support for the toolbar color, to sync properly with the color names in the Firefox container settings.

I assume this issue has remained unresolved for ~6 years and marked Needs: Mozilla Central because, in lieu of hardcoding two identical collections across codebases, it would be best, architecturally, to expose the array of supported colors and icons on ContextualIdentityService in Firefox as the source of truth, and then consume those in the extension, so they would never be out-of-sync. There are also the separate requests to support more icons and any arbitrary RGB color.

Both of those changes would require a lot more support, so I figured it would be better to get this fixed first using the current approach, and those alternatives would be better taken on by a member of the project(s) rather than a random outside contributor.

If those alternatives are something you're looking for someone to take on, let me know.

Edit Panel Light Theme	Edit Panel Dark Theme

Type of change

Select all that apply.

• Bug fix
• New feature
• Major change (fix or feature that would cause existing functionality to work differently than in the current version)

Tag issues related to this pull request:

• Container with toolbar color got overridden when edited through the addon #1822

[nekno]

This seems to just be hardcoded to match the number of colors. Each color swatch is 32 x 32px, and the panel is 320px wide, so you can fit 10 colors in a row without compromising on minimum spacing/padding on anything.

This changes it from 8 to 9 so all colors fit on the same row, and the minimum spacing is still met.

[nekno]

This matches the Firefox stylesheet for the ContextualIdentity component.

[nekno]

This matches the toolbar color named in the Firefox container settings dialog.

[achernyakevich-sc]

@nekno As I could understand from you commit you just added support of toolbar color...

But maybe it is not a bug but it is the special intention of developers to give no chance to mislead users by providing possibility to select toolbar color so that on UI it will be undetectable that you have opened tab in container instead of default (no container)?

Be sure as anybody will select toolbar color for some container then it is just a matter of time that it will report issues like:

• something does not work as expected in default container - they just will not distinguish default and their toolbar's containers.
• container identification image is not visible for the menu like below - gray on gray really could be invisible.

I'm really not sure. Maybe we need ask somebody like @dannycolin.

[nekno]

@achernyakevich-sc — I don't know the history why the color is named toolbar, but there isn't an option to change it, as the extension must match the implementation used in the Firefox settings, where the name toolbar is used.

The color named toolbar isn't actually the background color of the toolbar, it's the primary text color of your current theme, and it matches the color of the line on top of the tab, which is controlled by code in Firefox.

I added screenshots to the description to show it rendered in context.

For the light theme it's #15141A:

For the dark theme it's #FBFBFE:

[achernyakevich-sc]

Then it looks reasonable. Thank you for your efforts.

[dannycolin]

Sorry for the late response.

There was some issues/limitations with the toolbar color that prevented it to be added in the list. See a previous PR: #2192

[nekno]

Thanks, @dannycolin, I didn't find that previous PR in my searching. I wish I would have!

It's funny that we came up with almost identical PRs independently, though I used currentColor to match Firefox, rather than --text-color-primary in the other PR.

In testing, I see your point still stands, that currentColor doesn't work with themes other than light/dark, either.

None of the colors in MAC are expressly themable, so despite the toolbar color responding specifically to the light/dark themes, it doesn't to be a requirement for a color to respond to a theme in order to be used in MAC. This missing color is, in fact, the only color that responds to the light/dark themes for contrast accessibility, and it's better than not that it at least does that much.

While I would love to follow your suggestion in the other PR and fix this upstream, the effort and knowledge required to add a custom color picker is much greater than what's required to fix this issue.

If you have any references on how to pull in an existing color picker and incorporate it into the experience, I'm willing to try, but I'm likely not the best person. I will be learning most of it from scratch and the juice is not likely worth the squeeze.

I ask honestly — must we suffer this issue another 5 years until someone with the requisite skills and knowledge finds the time?

[dannycolin]

the only color that responds to the light/dark themes for contrast accessibility

This isn't necessarily true because we can't control third-party themes.

If you have any references on how to pull in an existing color picker and incorporate it into the experience, I'm willing to try, but I'm likely not the best person. I will be learning most of it from scratch and the juice is not likely worth the squeeze.

This would be the best longterm solution but there are a lot of moving pieces. The mechanism needs to be implemented in Firefox itself. Plus, this change would have an impact on the webextension API so we could potentially break other people addons if their code expect hardcoded color values.

I'm not a big fan of adding more hardcoded colors but I can still ask folks at Mozilla if we couldn't find a short term solution. For example, we could align our color values with the new Tab Group feature which offers 9 predefined colors. It always offers variant of the color palette depending if the theme is set as a dark or light theme. In other words, this solution would be similar to your fix for the end-user but we'd be in control of the visual rendering which would avoid the pitfalls of using the toolbar color.

I'll keep you posted.