2001318 - Some SVG pageAction icons have a poor contrast due to built-in CSS filter

Status: NEW

(WebExtensions :: Frontend, defect, P3)

Description

[Giulio B]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0

Steps to reproduce:

My V2 manifest extension has the following page action defined in the manifest:

  "page_action": {
    "default_icon": {
      "48": "icons/light/my-extension.svg",
      "128": "icons/light/my-extension.svg"
    },
    "default_title": "my-extension unavailable on this site."
  }

Which works correctly.

If I try to update it to another SVG icon from my extension with:

  browser.pageAction.show(tabId);
  browser.pageAction.setIcon({
    tabId: tabId,
    path: `icons/light/myextension-ok.svg`,
  });

The icon does not update.

Instead, if I try to update it with a PNG icon, without changing anything else:

  browser.pageAction.show(tabId);
  browser.pageAction.setIcon({
    tabId: tabId,
    path: `icons/light/32/myextension-ok.png`,
  });

The icon does get updated. If I switch everything to browserAction instead, and use the SVG icon, it works in both cases.

Actual results:

The Icon does not update with the newly set one.

Expected results:

The icon should have updated.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

I could not reproduce the issue on the latest Release (145.0.1/20251118022223), Beta (146.0b6/20251121110812) nor Nightly (147.0a1/20251123211459) under Windows 11 and Ubuntu 24.10.

I’ve modified an extension to have a pageAction with a SVG icon, which works correctly on the page I tested on, as you also observed/mentioned in Comment 0.

Using the script to update the icon to another SVG icon or to a PNG icon also works correctly on my end.

Comment 3

[Giulio B]

Hello,
thanks for testing. These are the files that reproduce the bug for me: png and svg, and the offending code where just swapping from svg to png makes it display the expected behavior.

Comment 4

[Alex Cornestean]

Hello !

I tried again using those specific icons from Comment 3.

I used a random SVG icon to check if the pageAction is displayed initially as expected (it is) and then updated the icon via the snippets from Comment 0 to the icons linked in Comment 3. Still no issues on my end.

Do note that I used the resources from the main branch of your GH. The links in Comment 3 give 404 errors when I access them. But I presume that should not matter.

Comment 5

[Tomislav Jovanovic :zombie]

Could you please provide the test extension so we could try to reproduce?

Comment 6

[Giulio B]

Hello,
thank you for following up on this and apologies about the links to the deleted branch.

I've created a branch with the expected behavior using PNGs bugzilla-2001318-png and one just changing it to SVGs bugzilla-2001318-svg.

In both cases these are the testing instructions:

• clone the repository and checkout the branch
• cd extension
• npm install
• make test-package
• the built extension zip will be in ../dist
• install the extension
• visit the test website

In the case of SVGs, an icon appears, but it seems the default one from the manifest. In the case of PNGs, it seems to correctly display the success icon (the -ok.ong one).

I'm also attaching the built zipfiles for convenience.

Comment 7

[Giulio B]

Attachment: extension-test-svg.zip

Comment 8

[Giulio B]

Attachment: repro-extension-png.zip

Comment 9

[Giulio B]

Attachment: repro-extension-svg.zip

Comment 10

[Giulio B]

repro-extension-png.zip and repro-extension-svg.zip are the built packages with only png to svg change that exhibits the different behavior in my 145.0.1 on mac aarch64

Comment 11

[Alex Cornestean]

I re-tested using the attached extensions. Tested on Firefox 145.0.2 (20251124145406) on Windows 11 and macOS 11.3.1, both x64 architecture. No issues with displaying the pageAction or updating it.

I also tried the below STR on the latest Android Nightly (147.0a1/20251125204654) ARM64-v8a (since aarch64, according to some research I did, seems to be the 64-bit execution state for the ARM64-v8a architecture) in case the architecture mattered (because it was specified that the issue occurred on an aarch64 mac). But I could not reproduce the issue either under these conditions.

I did the following:

SVG extension

1. Installed the extensions via about:debugging
2. Accessed https://testapp.nym.re/
3. pageAction is displayed and shows webcat-ok.svg
4. Attempted updating pageAction icon via script from Comment 0 to webcat-error both SVG and PNG versions
5. Updating was successful

**PNG extension **

1. Installed the extensions via about:debugging
2. Accessed https://testapp.nym.re/
3. pageAction is displayed and shows webcat-ok.png
4. Attempted updating pageAction icon via script from Comment 0 to webcat-error both SVG and PNG versions
5. Updating was successful

Comment 12

[Giulio B]

Hi, thanks for your attempts. I just realized the issue only occurs in the “dark” code path, specifically when the extension tries to use the dark icon for a dark theme. When I switch to the light theme, I can’t reproduce it there either. Sorry for not noticing this earlier.

Could you make one last attempt using a dark theme in Firefox to trigger the dark code path? I agree it’s probably too specific to be a Firefox bug and more likely an issue with a malformed image or something in my assets.

Comment 13

[Alex Cornestean]

Hello and thank you for this piece of info @Giulio !

Indeed, there is an issue when a dark theme is enabled, but not with updating the icons per se, but how the SVG icons are displayed/look when a dark theme is enabled.
I noticed that there is a slight visual difference with the icon when the script to update the icon is run i.e. the icon is updated but it doesn’t look much different from the default webcat-ok one. Note that I updated the icon to webcat-error.
PNG icons are still displayed correctly.

I tested the pageAction icon update with the following combinations (see screenshot):

1. dark theme + light webcat-error.svg – doesn’t display correctly
2. dark theme + dark webcat-error.svg – doesn’t display correctly
3. dark theme + light webcat-error.png – displayed correctly
4. dark theme + dark webcat-error.png – displayed correctly

Note that the default webcat-ok.svg icon doesn’t appear to be displayed correctly either from the get-go. The icon appears grey on the test site, but it should have been green.

The PNG extension, doesn’t exhibit the issue initially, the icon on the test site being green. Updating the icon to the PNG versions is done correctly, but when updating to the SVG versions of the icon, the issue appears.

Tested on the latest Release (145.0.2/20251124145406), Beta (146.0b8/20251126090434) and Nightly (147.0a1/20251126203239) under Windows 11 and Ubuntu 24.10.

For comparison, I tested the same scenarios on the extension I modified at the beginning of this investigation, and the results are the same as above. SVG icons fail to display properly when the dark theme is enabled, while PNG icons are ok.
I went even further and checked other SVG/PNG icons (not from the webcat bundle) with both the webcat extension and the extension I modified and the same issue occurs.

I’m confirming this issue as it does not seem to be a problem with the extension but with the browser.

Comment 14

[Alex Cornestean]

Attachment: dark_theme_svg-png.png

Comment 15

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

The severity field is not set for this bug.
:rpl, could you have a look please?

For more information, please visit BugBot documentation.

Comment 16

[Tomislav Jovanovic :zombie]

Hey Alex, could you please try to find a regression for this?

I don't have a range to suggest, but it might might be fairly old, from before Proton (~2021).

Comment 17

[Alex Cornestean]

Mozregression narrowed the issue to 2021-04-12 before not having enough data to bisect.

Pushlog: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=1d03336aafcfb8af4e39d61a52ff4983aaa4d007&tochange=b0d9f96ea571e00f4e0dbd78a089833a22ff2252

Searching through the pushlog, I found a potential regressor – Bug 1703889. Though since I’m not sure, I won’t set it as a regressor for now.

Comment 18

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Alex Cornestean from comment #17)

Mozregression narrowed the issue to 2021-04-12 before not having enough data to bisect.

Pushlog: https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=1d03336aafcfb8af4e39d61a52ff4983aaa4d007&tochange=b0d9f96ea571e00f4e0dbd78a089833a22ff2252

Searching through the pushlog, I found a potential regressor – Bug 1703889. Though since I’m not sure, I won’t set it as a regressor for now.

Hi Alex, thank you so much, that may not be the actual point where we got to the current behavior on the pageAction svg icons, but it did put me on the right track!

I managed to pin point the reason for the svg icon rendered with a filter applied on it to this part of urlbar-searchbar.css:

• https://searchfox.org/firefox-main/rev/7496c8515212669451d7e775a00c2be07da38ca5/browser/themes/shared/urlbar-searchbar.css#572-592

That seems to have been introduced from Bug 1859137 to fix what sounds like "kind of the opposite issue" hit by multiaccount-container extension's pageAction (where the icon was too dark and ending up not being really visible in dark mode).

I verified that as I was expecting commenting out the filter CSS rule makes the svg icons from the test extension attached to this issue to be rendered exactly like its png counterpart.

The filter is only applied to svg icons and only when the theme is explicitly dark or if the theme has both dark and light themes variants and the dark one is selected based on the operating system theme being set to dark, and so when the selected theme is light the filter isn't applied and the icon rendered as is also when it is an svg.

Technically the extension should be able to set an svg icon for which the filter would be working better either unconditionally or specifically when the theme is dark, but it is not documented thought and so it is very likely that the extensions developer may not realize that until the issue in being hit (either by the extension developer or users reporting it to the extension developer).

Nonetheless, as part of the css rules I linked above there is a TODO inline comment related to the idea of removing the special filter and just let the SVG icons to use prefers-color-scheme to determine the right color scheme to use, and so before marking this as dev-doc-needed to clarify in the docs how to deal with this special behavior applied to the pageAction icon, it may be worth to double-check if we would prefer instead to remove the filter and document how to leverage the prefers-color-scheme technique in the extensions pageAction icons instead.

An additional reason for considering that is that the browserAction icons are not getting this filter applied, and so the extensions developers would need to handle browser and page action icons differently to better fit in dark themes, and I feel like it would be easier for developers if they could use a single techniques to ensure both their page and browser action icons fit well in dark themes.

Comment 19

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Emilio, this issue seems to be hit in dark mode by svg extensions' page action icons due to the filter we are applying to svg icons in the urlbar (see comment 18), I noticed the inline TODO comment you kindly left right above the rule (thank you so much for doing that!!!) and that made me wonder if instead of documenting the current special behavior only applied on the extensions' pageAction svg icons we may prefer to aim for removing the filter as mentioned in your TODO inline comment and document the prefers-color-scheme technique instead, and so I'm needinfo-ing you to gather your perspective about it.

Comment 20

[Giulio B]

Thanks for getting to the bottom of this! On my side, I was already detecting the current theme in the extension code and selecting the appropriate SVG variant accordingly. As you point out, this logic could instead be embedded directly in the SVG via prefers-color-scheme, which I didn’t expect to be supported in this context. If that becomes the recommended approach, it would simplify the extension code quite a bit.

This also made me think of Bug 1422143 (and maybe also Bug 1367042), which requests a manifest-level way to declare light/dark variants for pageAction icons (similar to what’s already possible for browserAction). If SVGs that automatically adapt using prefers-color-scheme are expected to work reliably, then extensions could just provide a single adaptive SVG rather than relying on separate manifest entries.

Comment 21

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

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

Comment 22

[Emilio Cobos Álvarez [:emilio]]

I think removing it is the right thing to do. But doing so might break some extensions. E.g. containers icon looks bad without the hack.

I sent https://github.com/mozilla/multi-account-containers/pull/2835 to fix it, but we might want to gate it behind a pref (you can do that with something like @media -moz-pref(...) { in the CSS itself), and run it on nightly for a bit to catch issues?

Comment 23

[Emilio Cobos Álvarez [:emilio]]

If you agree with that I'd be happy to write or review a patch, either way :)

Comment 24

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Emilio,
thanks for the quick confirmation, and for the pull request in the multi-account-containers demonstrating how that would be achieved in the SVG icon content.

I'm going to bring this issue back to the rest of the team to gather their perspective and get to a more detailed plan, in particular get some more thoughts around how extension would be transitioning from the current state to the final one we want to aim for (e.g. would it be possible to assess the impact on popular extensions that are not actively maintained anymore?) and determine the other tasks that would need to be coordinated along with changes in mozilla-central (e.g. docs and examples demonstrating the approach, comms to send to the developers to give them an heads up and some time to work on the changes they may need to apply etc.).

Comment 25

[Emilio Cobos Álvarez [:emilio]]

Yeah, the good thing is that the change is fairly trivial-ish (see the diff in that containers PR for an example). So for actively-maintained extensions I think it should be trivial-ish.

Comment 26

[Rob Wu [:robwu]]

While the direction of this bug is being discussed, here is a work-around for extension developers in the meantime.

Given the hack that caused this issue (selector containing [style*=".svg"] at https://searchfox.org/firefox-main/rev/911b3eec6c5e58a9a49e23aa105e49aa76e00f9c/browser/themes/shared/urlbar-searchbar.css#580), a work-around for extension developers could be to use a capital .SVG as file extension instead of lowercase .svg. Make sure to also rename the file to have capital .SVG! It is possible for it to work when debugging locally because some file systems are case insensitive, but that would not work when a xpi is generated (bug 1827656).

Comment 27

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

The severity field is not set for this bug.
:robwu, could you have a look please?

For more information, please visit BugBot documentation.

Comment 28

[Rob Wu [:robwu]]

We are going to move this CSS behind a pref, and if nothing breaks, we can eventually remove this CSS.