Security

(public)

User Story

Spinning this off from bug 1388193.
The current -moz-context-properties mechanism (implemented across bug 1058040, bug 1350010 and bug 1360662) to allow embedding documents to set colors in SVG images isn't a great one to expose to the Web at large.
I don't really like that '-moz-context-properties' takes a list of properties, not least because it means that it's not a general solution for exposing properties to a sub-document/image. For example, at some point we may want to support exposing a property where an author may want to set one value to affect the embedding element, while also wanting to expose a different value for that same property to the embedded content. The '-moz-context-properties' mechanism doesn't allow for that since it only allows for one value.
The only proposal that seems to be significantly better than '-moz-context-properties' is the proposal that's been made on and off to the SVG WG over the years to add a mechanism to allow embedding documents to set CSS variables in embedded content. The latest incarnation of that proposal can be found at:
https://tabatkins.github.io/specs/svg-params/#setting
We should consider working out the issues in that draft and then implementing a first pass restricted to our frontend code and possibly WebExtensions.

I am confident that this feature is very attractive for web extension authors.
What's more, if we have an API to manipulate browserAction icon style, web extension authors easily create animating SVG icon there using transition. (I believe we should definitely have the API)
Web extension authors can, already today, create animating browserAction icon, but it's a bit tricky. I did release a proof-of-concept extension to show an animating browserAction icon [1] which is actually needs to set unique SVG via browserAction.setIcon() to make the animation happen.
[1] https://addons.mozilla.org/en-US/firefox/addon/animation-toggle-icon/

As a first step, simply allowing (non-Mozilla) extension authors to respond to changes to the browser theme via some sort of context-fill equivalent would a big win for extension authors and themers alike and something that would be worth prioritizing this year.

(In reply to Jonathan Watt [:jwatt] from comment #4)
> It probably makes more sense to set CSS environment variable[1] than CSS
> cascading variables. Of course the former are not yet implemented (bug 1462233),
> while the later are.
Follow-up: we do now have CSS Environment Variables implemented now, in case that ends up being the approach we want to take here. (Though: per last sentence of section 2 at https://drafts.csswg.org/css-env-1/#environment , we need to get any hypothetical variables standardized & listed there before we support them.)

You need to log in
before you can comment on or make changes to this bug.