Skip to content

Bug 2044354 Updated Containers colors#44409

Open
rebloor wants to merge 5 commits into
mdn:mainfrom
rebloor:Bug-2044354-Update-the-Containers-colors
Open

Bug 2044354 Updated Containers colors#44409
rebloor wants to merge 5 commits into
mdn:mainfrom
rebloor:Bug-2044354-Update-the-Containers-colors

Conversation

@rebloor

@rebloor rebloor commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

Description

Addresses the dev-docs-needed requirements for Bug 2044354 "Update the Containers colors" with:

  • a release note
  • updates to the color lists in contextualidentity, contextualidentities.create and contextualidentities.update.

Also contains some miscellaneous edits.

@rebloor rebloor requested review from Rob--W and bacharakis June 10, 2026 18:15
@rebloor rebloor self-assigned this Jun 10, 2026
@rebloor rebloor requested review from a team as code owners June 10, 2026 18:15
@rebloor rebloor added the Content:WebExt WebExtensions docs label Jun 10, 2026
@rebloor rebloor requested review from dipikabh and removed request for a team June 10, 2026 18:15
@github-actions github-actions Bot added Content:Firefox Content in the Mozilla/Firefox subtree size/m [PR only] 51-500 LoC changed labels Jun 10, 2026
@rebloor

rebloor commented Jun 10, 2026

Copy link
Copy Markdown
Contributor Author

@Rob--W, should we sort the color and icon name lists alphabetically?

@github-actions

Copy link
Copy Markdown
Contributor

This pull request has merge conflicts that must be resolved before it can be merged.

@github-actions github-actions Bot added the merge conflicts 🚧 [PR only] label Jun 11, 2026
@github-actions github-actions Bot removed the merge conflicts 🚧 [PR only] label Jun 11, 2026
- "gray"
- "violet"

The value "toolbar" represents a theme-dependent color. Identities with color "toolbar" will be displayed in the same color as text in the toolbar (corresponding to the [theme key](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme#colors) `"toolbar_field_text"`).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wondered about the relevance of this deleted documentation note, and traced back the history of changes. This note was already obsolete over a year ago: https://bugzilla.mozilla.org/show_bug.cgi?id=2044354#c8

- "violet"

The value "toolbar" represents a theme-dependent color. Identities with color "toolbar" will be displayed in the same color as text in the toolbar (corresponding to the [theme key](/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme#colors) `"toolbar_field_text"`).
The legacy values `"turquoise"` and `"toolbar"` are accepted and resolve to `"cyan"` and `"gray"` respectively.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For extension developers seeking to update their extension and wishing to maintain compatibility with older Firefox versions, I think that it is worth clarifying the original set of colors before Firefox 153, clearly stating the aliases (being clear that the new name is in 153 but effectively referring to the same value as what carried the old name in 152-), as well as the colors that are 153+ only.

Since this is a Firefox-only API anyway I think that it would be OK to mention that information inline in the text here (instead of trying to shove everything in BCD).

Can you also recommend the use of https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities/getSupportedColors to look up colors? So the framing could be "this is the set of colors before 153, the colors changed in 153, and you can now look up the latest supported colors with getSupportedColors"

And let's expand the getSupportedColors article to state the original set of supported colors before the method was introduced. That helps developers with figuring out which colors to hardcode if the method is unavailable.

Perhaps it may even make sense to express the relevant information about supported colors in the getSupportedColors documentation and use that as the canonical reference for the definition of a valid color?

- : `string`. A hex code representing the color used for the identity. For example: `"#37adff"`.
- `icon`
- : `string`. The name of an icon for the identity. This will be shown in the URL bar for tabs belonging to this identity. The following values are valid:
- : `string`. The name of an icon for the identity. This icon is shown in the URL bar for tabs belonging to this identity. These values are valid:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you also find a way to reference the new getSupportedIcons here since we are at it? https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/contextualIdentities/getSupportedIcons

- : `string`. The name of the new identity. This name is displayed in the browser's UI, enabling users to open a new tab belonging to the identity. It also displays in the URL bar for tabs belonging to this identity.
- `color`
- : `string`. The color associated with the new identity. This will be used to highlight tabs belonging to this identity. You can supply any of the following values here:
- : `string`. The color associated with the new identity. This color is used to highlight tabs belonging to this identity. Accepts any of these values:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's point to getSupportedColors (or the contextual identity color type) for supported colors instead. As stated elsewhere, make sure that we clarify what colors are supported in which versions, so that developers can easily write extensions that do the right thing before and after the Firefox 153 change.


- `icon`
- : `string`. The name of an icon to display in the URL bar for tabs belonging to this identity. You can supply any of the following values here:
- : `string`. The name of an icon to display in the URL bar for tabs belonging to this identity. Accepts any of these values:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also refer to getSupporteedIcons here.

- : `string`. A new name for the identity. This name is displayed in the browser's UI, enabling users to open a new tab in the identity. It also displays in the URL bar for tabs belonging to this identity.
- `color` {{optional_inline}}
- : `string`. A new color for the identity. This will be used to highlight tabs belonging to this identity. You can supply any of the following values here:
- : `string`. A new color for the identity. This color is used to highlight tabs belonging to this identity. Accepts any of these values:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as in the create method applies here, refer to getSupportedColors and getSupportedIcons (and/or the type definition) for clarity.

- Adds the {{WebExtAPIRef("publicSuffix")}} API, enabling extensions to determine the registrable domain (eTLD+1) and public suffix of a hostname using the browser's built-in [Public Suffix List](https://publicsuffix.org/). The API provides three synchronous methods: {{WebExtAPIRef("publicSuffix.isKnownSuffix()")}}, {{WebExtAPIRef("publicSuffix.getKnownSuffix()")}}, and {{WebExtAPIRef("publicSuffix.getDomain()")}}. ([Firefox bug 1315558](https://bugzil.la/1315558))
- Extension content scripts can now read and modify constructed stylesheets in {{domxref("document.adoptedStyleSheets")}} and {{domxref("ShadowRoot.adoptedStyleSheets")}}, without `.wrappedJSObject`. ([Firefox bug 1751346](https://bugzil.la/1751346))
- Adds the {{WebExtAPIRef("contextualIdentities.getSupportedColors()")}} and {{WebExtAPIRef("contextualIdentities.getSupportedIcons()")}} methods to retrieve the colors and icons available for contextual identities (containers). ([Firefox bug 2044712](https://bugzil.la/2044712))
- The colors available for contextual identities (containers) are updated: `"turquoise"` is renamed to `"cyan"`, `"toolbar"` is renamed to `"gray"`, and the color `"violet"` added. The legacy names `"turquoise"` and `"toolbar"` are accepted for backward compatibility. See {{WebExtAPIRef("contextualIdentities.ContextualIdentity")}} for the full list of supported colors. ([Firefox bug 2044354](https://bugzil.la/2044354))

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to clearly relate these two changes (new methods to get supported colors, and the changes to colors)? If a developer only sees the change to color names, it may be tempting to update the extension to use different color names, but what I would really prefer is for them to use getSupportedColors if available.

I also noted elsewhere that getSupportedColors should be updated to mention what extension could use if the browser doesn't support the method yet; if that section is added you can change this sentence to point to getSupportedColors (or still keep the reference to the type, if it features the compatibility information and/or pointer to getSupportedColors).

@rebloor

rebloor commented Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

@Rob--W I believe I've addressed all your feedback. Sorry for not adding information about the note deletion.

@rebloor rebloor requested a review from Rob--W June 12, 2026 18:10

Returns the colors supported by the browser for contextual identities.

Prior to the availability of this method (Firefox 152 and earlier) these colors were supported:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make it more clear that this method should be preferred for looking up the colors where available? If it helps, you may mention for context that the colors have been stable and fixed for a long time, but that Firefox 153 introduces changes to colors and that the method offers a way to look up the current colors, and any colors added in the future.

The purpose I envision for this article is:

  • Immediately obvious what colors are supported.
  • Take-away that the method should be used to query available colors. The release notes already mention the use case (avoiding hardcoding), but that is missing from this article (avoiding harcoding is forward-compatible with any changes in the future).
  • Context what the colors were before this method was introduced.
  • Changes if any (e.g. rename, new). You currently use two separate lists. Is that the best way to show the information? Would a table be clearer? (this is a question, not a request to change from list to table, unless you think that it is a good way to present the information).

In the long term, what was supported in older versions become less relevant. In the short term, developers who want to update their extensions should be offered clear guidance on what to do.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Rob--W I played around with various ways of presenting the color change information and concluded that separate lists is the clearest option. I also realized that I've missed adding information to the working with contextual identities article, which I've now included. Hopefully, your other feedback is addressed, too.

@rebloor rebloor requested a review from Rob--W June 13, 2026 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Content:Firefox Content in the Mozilla/Firefox subtree Content:WebExt WebExtensions docs size/m [PR only] 51-500 LoC changed

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants