1373851 - Show that a WebExtension has called theme.update

Status: NEW

(WebExtensions :: Themes, enhancement, P3)

Description

[Andy McKay]

You can enable a theme by going to about:addons, or the customise menu. However a  WebExtension can then call theme.update() and change the appearance. Returning to about:addons or the customise menu gives the user no idea that the theme has changed.

Perhaps we should show something about that.

Comment 1

[Markus Jaritz [:designakt] (UX)]

(In reply to Andy McKay [:andym] from comment #0)
> You can enable a theme by going to about:addons, or the customise menu.
> However a  WebExtension can then call theme.update() and change the
> appearance. Returning to about:addons or the customise menu gives the user
> no idea that the theme has changed.
> 
> Perhaps we should show something about that.

Why can extensions do that? And why is that change not reflected in the UI?

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Markus Jaritz [:designakt] (UX) from comment #1)
> (In reply to Andy McKay [:andym] from comment #0)
> > You can enable a theme by going to about:addons, or the customise menu.
> > However a  WebExtension can then call theme.update() and change the
> > appearance. Returning to about:addons or the customise menu gives the user
> > no idea that the theme has changed.
> > 
> > Perhaps we should show something about that.
> 
> Why can extensions do that?

Extensions now have access to the theming API. One motivation may be to theme certain aspects of the browser relative to the state of the add-on (for example Web Of Trust could theme the toolbars 'green' on a "trusted" site). Another motivation may be to have a theme that changes based on the weather and time of day.

> And why is that change not reflected in the UI?

This bug is on file to reflect these changes in the UI. As for why, simply because priorities and deadlines.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #2)
> > And why is that change not reflected in the UI?
> 
> This bug is on file to reflect these changes in the UI. As for why, simply
> because priorities and deadlines.

The other reason why we may not want to show it is because the theming API may be used by extensions that are not necessarily considered "themes". For example, an HTTPS-Everywhere-type extension may want to change the location bar to red on a site that is being accessed over HTTP. This extension may not be considered a "theme" but it would use the theming API.

It is also worth noting that this issue is not a regression introduced by the new Theming API. We also had this issue before with "complete themes" that had the power to do much more than lightweight themes, but appeared in the Extensions category of the Add-ons Manager.

Comment 4

[David Durst [:ddurst]]

I would think that even if an extension is not considered a "theme," the user should be able to understand what is changing their theme (either built-in or one they've explicitly chosen). In some cases, it's probably obvious -- but in cases where it's not, it could completely unknownable.

We've been discussing this lately in Add-ons because we need to start planning for the separation and presentation of static and dynamic themes in AMO, and defining what categorization an extension gets (for dynamic ones, specifically) impacts both AMO and whatever is shown in the UI.

It sounds like we need to get on the same page to make these changes (and I'd like to be able to coordinate this with bug 1369209, which has recently been re-requested).

Comment 5

[David Durst [:ddurst]]

(If ever I've wanted to edit a comment, it's here for "it could (be) completely unknow(n)able"... ugh)

Comment 7

[David Durst [:ddurst]]

Per bug 1451012 and our definition of themes (and dynamic themes), we need to show this on about:addons and Customize (perhaps this should be pulled up -- at least as a listing -- to about:preferences under "Appearance"?).

CCing Emanuela for our ongoing Jazz work.