Extension Icons for Light/Dark/Custom Theme

[hanguokai]

A little related to issue-216. Besides the text color and background color of the BadgeText, the extension icon itself is also a problem to adapt to various themes (Light/Dark/Custom).

Current state, developers can set static extension icon or dynamic change it by setIcon(). But:

• Developers can't set different icons for different themes (at least in static way). So the icon is good for one theme, but may be illegible for another theme.
• Single icon with transparent background is difficult to adapt to different color themes, unless you fill the background with a solid color.
• To setIcon() dynamically, developers may need to know current background color of the browser toolbar to choose a color with sufficient contrast to draw the icon. Note: background color of browser toolbar may differ from the system theme, see this discussion.

[yankovichv]

I fully support it. However, it seems to me that it should be implemented as a browser-based JS API available for websites as well. The point is that all the problems from the list above are relevant for Favicons.

[hanguokai]

I think website favicon and extension icon are not exactly the same problem.

Here is a stackoverflow question for website favicon. There are several solution for it. For example, svg favicon with media query, <link> element with media attribute. At least, there is a no-JS solution for light/dart theme.

But these solutions do not apply to extensions. Extension icons are declared in manifest.json. And there is no window.matchMedia('xxx').addEventListener in extension service worker. There are also custom theme(extension theme) that can change toolbar color.

[dotproto]

Chromium is tracking a similar feature request in issue 893175. A Chromium engineer shared a link to a design doc we were considering in comment 19, but that effort is currently on hold.

@xeenon, @zombie, and @mukul-p, it might be worth taking a look at this and sharing feedback either on the doc or on a related issue.

[hanguokai]

I see the design doc. It is a static(declarative) way in manifest file. I think it solves 90% of the problems.

I think a runtime API should also be provided to solve dynamic problems, because developers can change icon by setIcon() method. For example adding two new apis below:

chrome.runtime.getTheme(); // return 'light' or 'dart' or background color
chrome.runtime.onThemeChanged.addListener(theme => changeIt()); // listener for theme changed

[carlosjeurissen]

We can draw some inspiration from ongoing discussion on how to handle this in PWA manifests, see:
w3c/manifest#758
w3c/manifest#975
w3c/image-resource#26

In general, going for a list of icons versus an object, like Mozilla did with theme_icons and PWA do with icons will give us more flexibility.

We can go for a syntax like this:

  "icons": [{
    "src": "/pwa-36.png",
    "sizes": "36x36",
    "media": "(prefers-color-scheme: dark)"
  }, {
    "src": "/pwa-adaptive-48.png",
    "sizes": "48x48",
    "purpose": "toolbar"
  }]

Or adding a color_scheme property. Which can be set to "light", "dark", and potentially "monospace" as many extension developers prefer to blend into the browsers design. This has the added benefit it's clear the browser will choose a dark-mode icon when the background of the browser team is a darker color even tho the OS is not using "dark mode".

[mixedpuppy]

Firefox implementation can be seen at e.g. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/action

[carlosjeurissen]

For best backwards compatibility, we can consider implementing the theme_icons property for action/page_action/browser_action as is currently implemented by Firefox:

"action": {
  "browser_style": true,
  "default_icon": {
    "16": "button/geo-16.png",
    "32": "button/geo-32.png"
  },
  "default_title": "Whereami?",
  "default_popup": "popup/geo.html",
  "theme_icons": [{
    "light": "icons/geo-16-light.png",
    "dark": "icons/geo-16.png",
    "size": 16
  }, {
    "light": "icons/geo-32-light.png",
    "dark": "icons/geo-32.png",
    "size": 32
  }]
}

default_icon would continue to work fine. While theme_icons would take priority over default_icon if present. light would be used when light text and icons are needed. For example, with a darker background or with dark mode theme. While dark would be used for light mode themes.

We can then move forward with more breaking changes in regard to icons for Manifest v4.

[hanguokai]

light would be used when light text and icons are needed. For example, with a darker background or with dark mode theme. While dark would be used for light mode themes.

I didn't know Firefox's theme_icons before. For me, it's counterintuitive. I prefer dark for icons used in dark theme and light for icons used in light theme.

[carlosjeurissen]

@hanguokai This would then be something we can fix once drafting MV4.

As for the API to update theme_icons, we can go for:

browser.action.setThemeIcons([{
    "light": "icons/geo-16-light.png",
    "dark": "icons/geo-16.png",
    "size": 16
  }, {
    "light": "icons/geo-32-light.png",
    "dark": "icons/geo-32.png",
    "size": 32
  }])

Calling this method would overwrite the theme_icons (if present) defined in the manifest file. If set to an empty array or null or undefined, resets the themeIcons to what has been defined in the manifest file or otherwise fallback to what is defined in 'default_icon'.

Currently in Firefox, setIcon will overwrite what is defined in theme_icons. Thus at least for MV2 and MV3 we seem to have to stick to this. This means setIcon would also overwrite setThemeIcons. This is not an issue considering developers can check the presence of setThemeIcons and use that instead of setIcon if present. Naturally setThemeIcons would overwrite the icon set by setIcon.

[xeenon]

The theme_icons key and browser.action.setThemeIcons sounds good to me for Safari.