Closed Bug 1846225 Opened 2 years ago Closed 1 year ago

Add context fill for search one-off buttons

Categories

(WebExtensions :: Untriaged, enhancement)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1809958

People

(Reporter: aminomancer, Unassigned)

References

Details

Addons can provide SVG icons for browser actions, search one-off buttons, and other things to be displayed in the chrome. In the case of browser actions, it's possible to use fill="context-fill" to make the addon icon adaptive to the user's theme, because of the following rule:

.toolbarbutton-animatable-box,
.toolbarbutton-1 {
  color: inherit;
  -moz-context-properties: fill, fill-opacity;
  fill: var(--toolbarbutton-icon-fill);
}

Although it's intended for built-in toolbar buttons, it still does apply to extension-provided browser actions if the pref svg.context-properties.content.enabled is enabled. Browser actions also provide an ability to provide separate light and dark icons. So there are 2 pretty easy ways to make sure your addon's main action doesn't clash with the chrome theme.

Search one-off buttons (both in the urlbar results view and in the searchbar panel) don't currently provide a similar feature. Firefox sets an image property that's inherited down to the image as a src attribute, so you can't provide a dark favicon as well as a light favicon. Whatever you set as the favicon will be used invariably. And although you can use an SVG icon for this purpose, and it will work just fine, it won't inherit colors from the chrome.

If we added a similar rule like

.searchbar-engine-one-off-item {
  -moz-context-properties: fill;
  fill: currentColor;
}

Then addon developers could include fill="context-fill" in their favicons and have them automatically match the user's theme/color scheme, at least for users interested enough in a cohesive theme to flip that pref I mentioned (which is disabled by default). Also, I might file a bug to change this behavior so that moz-extension content can use context properties even if the pref is disabled. Since the need for context properties in web content is very different from the need for context properties in elements added by extensions to the browser chrome.

This would be a nice enhancement since, in my experience, search one-off buttons from addons tend to clash with the built-in search engine buttons. I'm not sure if there's any significant cost to adding a rule like that. My thinking is basically, if it works for browser action buttons, it couldn't hurt to apply it to search one-off buttons too.

Edit: It could also be resolved by providing a similar capability to provide light/dark versions of the engine icon. I imagine the problem with that is it would require new webextensions manifest keys. To support context properties may not be as immediately helpful since the behavior is currently behind a pref, but it's trivial to implement, and it seems like there are ways the benefits could be extended more to addons.

If Mozilla come up with a better mechanism than context-fill, we can change the code. If we allow third party add-ons to use the feature we'll never be able to replace it. That's always been the objection to extending this feature.

See bug 1394579 comment 4 and bug 1394579 comment 6 and bug 1394579 comment 14

that bug mentions bug 1404568 as the way to go.

We think this is something for the WebExtension team to decide on the best way of supporting it. Given comment 1 it sounds like it might be a wontfix for context-fill, but maybe different theme icons should be supported in other ways.

Component: Search → Untriaged
Product: Firefox → WebExtensions

We already want to provide light/dark icon support for extensions (though it hasn't been a priority). Would bug 1809958 be a duplicate, or do search engines have special considerations I'm not familiar with?

Closing as a duplicate of Bug 1809958 (the one mentioned by Tom in comment 3) given that it seems to be the approach we are going to prefer.

Status: NEW → RESOLVED
Closed: 1 year ago
Duplicate of bug: 1809958
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.