We want to ship some DevTools features as extensions. A big part of our userbase is using the DevTools dark theme (especially DevEdition), so panel icons need to be able to work adapt to both dark and light themes – preferably aligned with our photon icon designs which are all monochrome.

The easiest fix would be to enable context paint for the use case of panel icons. If we don't do this, we can not effectively experiment with new panels side-loaded as extensions.

Jaws, since bug 1379464, has our stance on enabling context paint for more use cases changed?

jwatt: Your thoughts here?

(In reply to :Harald Kirschner :digitarald from comment #1)

Jaws, since bug 1379464, has our stance on enabling context paint for more use cases changed?

Are these extensions signed by Mozilla? Extensions signed by Mozilla should have access to -moz-context-properties and related CSS properties. We didn't expand this to other extensions due to webcompat worries.

Are these extensions signed by Mozilla?

No, they are created and signed by externals teams that we collaborate with.

We didn't expand this to other extensions due to webcompat worries.

In case of devtools icons, Chrome DevTools panels don't have icons, also for extensions so the webcompat risk is zero.

:jaws, given my last comment, would be easy to switch on for devtools icons coming from extensions

I don't think it would be easy. When we allow this, we don't know what context the image is being used in. We don't know if this is for a toolbar button in the browser or a panel icon in DevTools. Redirecting needinfo to kmag for webextension background and heycam for webcompat background.

I don't think it would be too hard to figure out the context of the image load when we're making that decision.

I'm personally OK with this. But, I also don't really have an objection to allowing extension images to use context paint everywhere. So it's really more a question for the people who have to maintain the context paint code.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #3)

Are these extensions signed by Mozilla? Extensions signed by Mozilla should have access to -moz-context-properties and related CSS properties.

That's not strictly true. We added the exception for any extensions with IDs ending in @mozilla.com or @mozilla.org, regardless of signing status, since we restrict the users who can create extensions with those IDs on AMO.

Though, at this point, checking for the "mozillaAddons" permission would probably be a better solution. shrug

So it's really more a question for the people who have to maintain the context paint code.

Thank you. I am assuming this is jwatt, from Sean's initial ni?.

See bug 1394579 for my feelings about exposing context-* to extensions in general. That said, if we need to expose it to fix existing issues, then I guess we need to expose it. Do we?

Considering the discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1394579#c5, this seems to be a strategic addon-ecosystem question; do we want this non-standard feature (and others), which will potentially change in the future, exposed to extensions – a place where we can do outreach to extensions when we decide to deprecate stuff?

Andreas, what are your thoughts?

Redirecting to the WebExtensions PM, Philipp.

My take is that we should be very careful in exposing non-standard features to WebExtensions. While it is true that there is a deprecation strategy and means to reach out to affected developers, the WebExtensions API is meant to provide stable APIs. I'd prefer if we could work towards standardizing and implementing what is necessary to provide this feature to content, at which time extensions could make use of it.

As far as I understand DevTools extensions have not been a focus of standardizations, but mostly alignment. The audience is small and is part of an ongoing partnership in this case. We are looking into pre-loading this extension in DevEdition for example, starting with experiments.

My take is that we should be very careful in exposing non-standard features to WebExtensions.

Agreed, careful consideration is important. Just for this bug specifically, what would be the verdict?

Sorry this dropped off my radar. I've given the various bugs connected to this one another read and it seems to me that:

• There are reasons we would not want to enable context-fill generally. svg params seems to be the alternative, though it is still an unofficial draft
• Enabling context-fill for extensions would be a workaround for the meanwhile. One futher restriction would be to only enable it for privileged extensions

I think we should extend devtools.panels.create to take more than just a string for the icon. It could be an array modeled similar to theme_icons from browser_action. This doesn't require us to enable context-fill which does not seem to have a future in web content, would allow us to wait for svg params, and solves the use case of having different themes, even if more limited than what context-fill could provide.

Does this solve the use case for you?