1811128 - Lower quality icon is shown (scaled from 19 to 16) when "browser_action" lists both "16" and "19"

Status: VERIFIED FIXED

(WebExtensions :: Frontend, defect, P1)

Description

[tophf]

Attachment: extension.zip

Steps to reproduce:

1. install an extension that specifies both "16" and "19" icons in its "browser_action"
2. pin its icon using the Unified extensions UI

Actual results:

The icon is smudged because the image for 19px was scaled down to 16px.

Expected results:

The icon is clear and crisp when the image for 16px is used.

Comment 1

[tophf]

Regressed in 108: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=650b8a7c958514f3357acfb4a7342a5d14f58537&tochange=963d3b67f5243687fcb5bc122a22a536caa9a9fd

As to why this is a problem, it's because extension authors want to specify both "16" and "19" (as well as "32" and "38") to support various browser modifications that may use different icon sizes in their UI. Some browsers may even make it configurable by the user.

Comment 2

[tophf]

Attachment: good.png - expected result

Comment 3

[tophf]

Attachment: bad.png - observed result

Comment 4

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (111.0a1/20230119163652), Beta (110.0b3/20230119185824) and Release (109.0/20230112150232) under Windows 10 x64 and Ubuntu 16.04 LTS.

Once the extension is pinned to the toolbar, the icon is indeed smudged. For further details, see the attached screenshot.

Comment 5

[Alex Cornestean]

Attachment: 2023-01-20_09h47_45.png

Comment 6

[tophf]

BTW the problem is not limited to just "19", but "32" is also problematic. It looks like Firefox now chooses the biggest icon regardless of the display's dpi. If you rename "19" to "32" in the attached extension's manifest.json you'll see Firefox incorrectly shows the "32" icon, whereas on a single-density display the correct choice is "16", just as it was previously.

Comment 7

[Gregory Pappas [:gregp]]

I'm unable to reproduce this on my end. Could you run mozregression to see when this started happening?

Edit: Nevermind, I see the problem now.

Comment 8

[tophf]

The mozregression range is in comment 1.

Comment 9

[Gregory Pappas [:gregp]]

Last good revision: f9bb8bffa11e11c730bcefc548ee3a374902f838
First bad revision: 31f51c0e8a5c8b320c02cd9772c51419e9474a2c

Comment 10

[tophf]

The old code was using 16/32/16/32,
but the new code uses 16/32/32/64:

• if (gUnifiedExtensionsEnabled) {

•  return `
  

•    ${getStyle("menupanel-image", icon16)}
  

•    ${getStyle("menupanel-image-2x", icon32)}
  

•    ${getStyle("toolbar-image", icon32)}
  

•    ${getStyle("toolbar-image-2x", icon64)}
  

•  `;
  

• }
• return ${getStyle("menupanel-image", icon16)} ${getStyle("menupanel-image-2x", icon32)} ${getStyle("toolbar-image", icon16)} ${getStyle("toolbar-image-2x", icon32)};

Comment 11

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

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

:willdurand, since you are the author of the regressor, bug 1798324, could you take a look? Also, could you set the severity field?

For more information, please visit auto_nag documentation.

Comment 12

[William Durand [:willdurand]]

According to searchfox, we use 32/64px icons for both the toolbar and the menupanel. This is because we need "bigger" icons in the extensions panel.

Comment 13

[tophf]

Maybe srcset attribute could help. Regardless of the method, for a N-pixel single-density image the proper solution is to use a N-pixel source icon.

Comment 14

[Gregory Pappas [:gregp]]

You can work around the issue by using SVG.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/icons#svg

Comment 15

[William Durand [:willdurand]]

Attachment: Bug 1811128 - Use 16/32px extension icons in toolbars. r?rpl!,dao!

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11266428de1b
Use 16/32px extension icons in toolbars. r=rpl,dao

Comment 17

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/11266428de1b

Comment 18

[Alex Cornestean]

Verified as Fixed on the latest Nightly (111.0a1/20230130214413). Tested on Windows 10 x64 and Ubuntu 16.04 LTS.

The pinned to toolbar icon is no longer smudged and looks sharper. For further details, see the attached screenshot depicting the icon before the fix (upper part of the image) and the icon after the fix (lower part of the image).

Comment 19

[Alex Cornestean]

Attachment: 2023-01-31_09h32_41.png

Comment 20

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

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

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

For more information, please visit auto_nag documentation.