1786564 - Extension sidebar themed background missing [web accessible resources]

Status: VERIFIED FIXED

(WebExtensions :: Frontend, defect, P1)

Description

[Andreas Wagner [:TheOne] [use NI]]

Attachment: Before

In 105, the extension sidebar background is no longer styled according to the installed theme.

STR:

1. Install TreeStyleTab https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/
2. Go to its preferences, under Appearance select the "Proton" style
3. Install the official Firefox Alpenglow theme https://addons.mozilla.org/en-US/firefox/addon/firefox-alpenglow/
4. Open the TreeStyleTab sidebar

Expected results:

Themed background color, see before image.

Actual results:

Solid light-grey background color, see after image.

Comment 1

[Andreas Wagner [:TheOne] [use NI]]

Attachment: After

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1773115

:mixedpuppy, since you are the author of the regressor, bug 1773115, could you take a look?
For more information, please visit auto_nag documentation.

Comment 3

[Shane Caraveo (:mixedpuppy)]

It appears to style with other themes, like https://addons.mozilla.org/en-US/firefox/addon/plum-torte

It is accessing an image from alpenglow to figure out a color. We'll have to decide what we want to do about addons accessing theme resources like that, but for now I think it's low priority.

Comment 4

[Shane Caraveo (:mixedpuppy)]

for reference: https://github.com/piroor/treestyletab/blob/604ae86d9d81e33fce9b215f687795312c7610b9/webextensions/common/browser-theme.js#L58-L82

Comment 5

[Rob Wu [:robwu]]

(In reply to Shane Caraveo (:mixedpuppy) from comment #3)

It appears to style with other themes, like https://addons.mozilla.org/en-US/firefox/addon/plum-torte

It is accessing an image from alpenglow to figure out a color. We'll have to decide what we want to do about addons accessing theme resources like that, but for now I think it's low priority.

That looks like a reasonable use case for accessing (third-party) theme images from an extension.
I already identified the discrepancy between the theme.getCurrent and theme.update API in bug 1618563. Relevant part copied from https://bugzilla.mozilla.org/show_bug.cgi?id=1618563#c2 is:

The definition of the theme.Theme type (i.e. the parameter passed to theme.update and returned by theme.getCurrent) is here: https://searchfox.org/mozilla-central/rev/13b081a62d3f3e3e3120f95564529257b0bf451c/toolkit/components/extensions/schemas/theme.json#85,90,95,99

The ImageDataOrExtensionURL means that the value should be a data-URL or a relative URL.

This issue could be fixed by either ensuring that theme.getCurrent() returns relative URLs,
or by relaxing the type to support absolute moz-extension:-URLs.

If absolute moz-extension:-URLs were to be supported, we also need to account for the fact that a moz-extension:-URLs can point to another extension. At least initially, I would reject moz-extension:-URLs from other extensions until there is demand for the ability to read and modify a theme from another extension. If we do need to support themes from other extensions, then we need to apply logic similar to what we have for the favIconUrl property in the browser.search.get API.

So... do we want to go down the route of converting to data:-URLs? If yes, then we would have to relax the data:-URL validation to permit other (image) types besides PNG/JPG (bug 1491790).

An alternative way to solve this specific use case is to allow extensions with the "theme" permission to load non-web-accessible theme resources. I can imagine the logic getting too complicated, so a more general fix may be more desirable.

Comment 6

[Rob Wu [:robwu]]

Updating regressed-by. The two bugs were resolved by one patch stack that landed together*, but the first in the stack looks like the most likely cause of the regression.

• https://hg.mozilla.org/integration/autoland/pushloghtml?changeset=1aa5ec22f47a1aeccb4b0a1ff678d03b3cf26185

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Hi Rob, is this something we're planning to address in Fx105 before it goes to RC in a couple weeks?

Comment 8

[Rob Wu [:robwu]]

After discussing this bug today, we decided to go for the following approach:

• When a moz-extension to moz-extension request is blocked (i.e. this logic does not cover requests from web content),
• and the requesting extension has the "theme" permission,
• and the receiving extension is a static theme *,
• and the requested resource is an image (e.g. image file extension, or even the registered images in the manifest.json file),
• allow the load to proceed.

* The above logic would solve the issue for common cases. It does not fix the bug for dynamic themes, because we did not want to dynamically change the set of extension-accessible content at runtime in response to browser.theme.update calls from the source extension.

Assigning to Shane, Luca said that he can pick it up if Shane cannot get to it.

Comment 9

[Taddes Korris [:taddes]]

Hey [:mixedpuppy], just checking to see if there are any updates on this and if he have some hope of pushing a bug in the next few days. Thanks!

Comment 10

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1786564 allow access to static theme resources in extensions

Comment 11

[Rob Wu [:robwu]]

Patch is about to land. We'll request an uplift after that.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/52d0781d2e1f
allow access to static theme resources in extensions r=rpl,necko-reviewers,dragana

Comment 13

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/52d0781d2e1f

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:mixedpuppy, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox105 to wontfix.

For more information, please visit auto_nag documentation.

Comment 15

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 9293388 [details]
Bug 1786564 allow access to static theme resources in extensions

Beta/Release Uplift Approval Request

• User impact if declined: A feature of addons allows them to query the current theme so they can retheme themselves to be similar to the browser. Sometimes this involves access to e.g. images in a theme extension. This regression prevents that use case, resulting in e.g. sidebar addons like tab managers being unable to match the browser theme. Depending on how well an addon is written it should recover, however this could otherwise result in additional breakage in an addon.

I am not aware of normally visible UI on android that would have a highly visible affect that users would see, thus I am unsure if android is affected in any meaningful way.

• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Steps are in the bug but this is the simple version

1. install tree style tab
2. install alpenglow theme

expected:
tree style tab sidebar matches alpenglow theme
actual:
tree style tab remains themed per prior theme

• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): I've chosen medium because it is c++ code, however the change in minimal
• String changes made/needed: none
• Is Android affected?: Unknown

Comment 16

[Shane Caraveo (:mixedpuppy)]

QE: I did forget a step in the beta request, refer to comment 0 for the full STR

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9293388 [details]
Bug 1786564 allow access to static theme resources in extensions

Fixes a user-facing regression in the common case. Approved for 105.0b9.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/c43df391999b

Comment 19

[Alex Cornestean]

Verified as Fixed on the latest Nightly (106.0a1/20220908213354) and Beta (105.0b9/20220908185813) under Windows 10 x64 and Ubuntu 16.04 LTS.

The background of the sidebar is now styled according to the installed theme, confirming the fix.

For further details, see the attached screenshots.

Comment 20

[Alex Cornestean]

Attachment: 2022-09-09_09h34_11.png

Comment 21

[Alex Cornestean]

Attachment: 2022-09-09_09h36_27.png

Comment 22

[Alex Cornestean]

Update:

It seems that the theme sidebar styling is not applied in Private Windows.

STR:

1. Install Tree Style Tab: https://addons.mozilla.org/en-US/firefox/addon/tree-style-tab/
2. Go to its preferences, under Appearance select the "Proton" style
3. Install, for example, this theme: https://addons.mozilla.org/en-US/firefox/addon/orchidestra/ OR this one https://addons.mozilla.org/en-US/firefox/addon/american-style-4th-of-july/
4. Notice that the styling of the sidebar is in accordance to the applied theme
5. Grant Tree Style Tab access to Private Windows
6. Open a Private Window
7. Open the Tree Style Tab sidebar in the Private Window
8. Notice the color of the sidebar background is a solid color instead of the theme styling as in the Normal Window

Both the latest Nightly (106.0a1/20220908213354) and Beta (105.0b9/20220908185813) are affected by this.

Latest Release (104.0.2/20220902153754) is not affected.

Comment 23

[Alex Cornestean]

Attachment: 2022-09-09_09h52_28.png

Comment 24

[Alex Cornestean]

Attachment: 2022-09-09_09h54_49.png

Comment 25

[Rob Wu [:robwu]]

Clearing ni; covered in bug 1790115.