Icons often look wrong within extensions, I previously suggested adding the ability to query the theme to get if it is dark or light. It might be easier to define an SVG mask which the browser can colour whatever way it likes depending on the context it is placed. Similar to the mask-icon: https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_9_0.html#//apple_ref/doc/uid/TP40014305-CH9-SW20 We have the following issue for containers: https://github.com/mozilla/testpilot-containers/issues/464 The issue is we query using SDK that the theme is dark, however we then have an issue on Ubuntu's dark context menus.

If we've got bug 1329242, which I think mattw is close to landing, we won't be needing this I think?

No actually that bug only solves a theme of dark/light. The issue with the context menu is that it is always dark in Ubuntu. Unless that bug is going to pick the right icon for those themes. Providing a specific monochrome icon would also allow context menus to have a simpler icon.

Hi Jonathan, this has been added to the agenda for the August 1 WebExtensions APIs triage meeting. Let us know if you are able to attend! Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1l5zlSASqZAzzJGZhHtLWY1yaUwCKZiHXXGP1k_2W-TU/edit#

Hey Caitlin, I actually meant to close this solution off as it looks like Bug 1377302 will solve this. There might be room for discussing if this should be permitted in all extensions not just native as it seems other peoples extensions would benefit. However it would likely need the same standards approval as :heycam mentions here: https://bugzilla.mozilla.org/show_bug.cgi?id=1329242#c46 Should I close this?

Hey Jonathan, thanks for the info! My gut impulse is to leave this open for now and talk about standards approval at the triage meeting. I'll update the agenda to reference 1329242. Andy, please let me know if I'm off base

Sounds good.

I do see that the svg fill support was only done on @mozilla.org extension ids (which actually doesn't ensure it's a mozilla addon) via bug 1379464. jwatt: given your comment here: https://bugzilla.mozilla.org/show_bug.cgi?id=1379464#c3 and the ni here: https://bugzilla.mozilla.org/show_bug.cgi?id=1379464#c4 I'd like to get an answer on "1. Why would letting all WebExtensions access to context paint values be problematic?"

(In reply to Shane Caraveo (:mixedpuppy) from comment #7) > I'd like to get an answer on "1. Why would letting all WebExtensions access > to context paint values be problematic?" Because once a much larger audience of developers starts using the 'context-properties' property in extensions it's likely to become very difficult to get all those developers to stop using it and convert their code to some less crappy replacement for 'context-properties'. I'll talk with dbaron and heycam and see what they think.

:jwatt to be clear, the -moz-context-properties isn't exposed to extension authors for this to work, they are specifying an SVG in a manifest which uses the values fill="context-fill". Which from my understanding is already standard.

(In reply to Jonathan Kingston [:jkt] from comment #9) > :jwatt to be clear, the -moz-context-properties isn't exposed to extension > authors for this to work, they are specifying an SVG in a manifest which > uses the values fill="context-fill". Which from my understanding is already > standard. fill="context-fill" is standardized, but only for setting the color of SVG glyphs in SVG-in-OT from the text that references the OT font. It's not standardized for taking color from an image referencing element. Besides that, due to technical limitations (we can't know if the embedding code is "our"/"moco" code) we don't restrict the '-moz-context-properties'/'context-fill' mechanism based on the embedding side, but rather based on the embedded side. In other words the use of '-moz-context-properties' is unrestricted, so if we also allowed 'context-fill' to be used by any WebExtension then we effectively make the entire mechanism part of our WebExtensions API, which I don't want to do. Anyway, as I understand it from our IRC conversation you have fixed your pressing use-case in other ways. So although a mechanism like this would be something WebExtension authors (and Web developers) would like, for the moment I'm not prioritizing this.

I can understand not wanting to expose this as a WebAPI, but the fact is that an API for WebExtension APIs is much easier to warn users about, deprecate and change. For example: through extension signing we have a copy of every single extension and can warn those users. Without doing something here, we are starting to go down other rabbit holes like bug 1394579 as the same use case is recurring for other add-ons and external to Mozilla add-ons too.

Could we get back to the original issue? The whole thing with context-fill may be nice and something like this should become available at some point for more advanced use-cases (see https://bugzilla.mozilla.org/show_bug.cgi?id=1421329 for the current issue btw). The original request was for extension authors to simply provide a monochrome icon that the browser then can color any way it prefers. Unlike the whole SVG variable thing this has the benifit of being much easy-to-use for extension authors and that it is independent of the actual imaging format used (PNG!). As an extension developer I would expect something along the lines of "browser_action": { … "theme_icons": { { "light": "…", "dark": "…" "size": …, "type": "monochrome" }, … } } to be sufficent for specificing a simple monochrome icon (pure black or white) and have it look “native” in all themes. The browser can then add a color transformation matrix (RGBA) along the lines of: 0 0 0 0 textcolor.r 0 0 0 0 textcolor.g 0 0 0 0 textcolor.b 0 0 0 1 0 as an output filter of the icon and everybody will be happy. Sure this won't fix everything and more fancy stuff will still require the SVG-with-CSS-variable approach, but this provides a simple-to-use and, if I'm not mistaken, simple to implement approach that will work for most people “just wanted theme integration”. Is this something Mozilla devs can imagine imlementing in a more short-term kind of timescale?

Is the mask icon idea (a la Safari) worth reconsidering? Looks like the alternative would be bug 1421329 (passing CSS custom properties or, more likely, env() variables, to the embedded SVG image) but since it requires evolving a spec and probably implementing env() it will be far off. Are there open lines of communication with Chrome developers for discussing something they might want to use too?