1517321 - The pinned-tab "mute" icon has fuzzy edges & noticeably different shape when tab is selected/foreground (in default theme)

Status: NEW

(Firefox :: Theme, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Visit some page that plays audio
  (e.g. visit https://www.youtube.com/watch?v=uGcjAKZ5TUk and click play)
 2. Pin the tab.
 3. Inspect the mute icon in the pinned tab.
 4. Switch tabs so that the pinned tab is in a background tab, and compare.

EXPECTED RESULTS:
Mute icon should have a consistent shape & crispness, regardless of whether it's foreground vs. background tab.

ACTUAL RESULTS:
If the pinned tab is the foreground tab, the mute icon's edges are noticeably fuzzy and its shape looks a bit different (it's stretched vertically) as compared to how it looks in a background tab.

NOTE: This is *only* an issue in the default theme (where the foreground vs. background tab color are different).  I get EXPECTED RESULTS in the "light" and "dark" included themes.  (I'm mentioning this for comparison -- but of course it doesn't help much, since users typically stick with the default.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot 1, showing the issue (default theme, foreground tab vs. background tab)

Here's a screenshot showing an audio-playing (mute) icon in a foreground vs. background pinned tab, in the default theme.

Notice the difference in their apparent height and the crispness of their edges.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot 2, showing "light" theme for comparison

Here's the "light" theme, for comparison.  The foreground tab has the exact same color as it does in the default theme, so you'd expect the mute icon to look the same as well -- but it looks much better/crisper.

My hope here is that we could make the default theme look how the light theme looks, for the mute icon on the foreground tab.

Comment 3

[Daniel Holbert [:dholbert]]

OK, I diagnosed this a bit further.

Here's the XUL element for the icon:
====
<xul:image xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" xbl:inherits="crashed,busy,soundplaying,soundplaying-scheduledremoval,pinned,muted,blocked,selected=visuallyselected,activemedia-blocked" xmlns:xbl="http://www.mozilla.org/xbl" anonid="overlay-icon" class="tab-icon-overlay" role="presentation" pinned="true" soundplaying="true" selected="true"/>
===


It image is provided with this rule:
.tab-icon-overlay[soundplaying] {
    list-style-image: url("chrome://browser/skin/tabbrowser/tab-audio-playing-small.svg");
}
Link: https://searchfox.org/mozilla-central/source/browser/themes/shared/tabbrowser/tab-audio-playing-small.svg


And that image's coloring is is specified via these two rules:
.tab-icon-overlay[soundplaying], .tab-icon-overlay[muted]:not([crashed]), .tab-icon-overlay[activemedia-blocked]:not([crashed]) {
    -moz-context-properties: fill;
    fill: currentColor;
}
tab {
    color: -moz-DialogText;
}

And if you look at the SVG itself, it looks like the "filled region" is the passed-in context property (-moz-DialogText in this case), and there's an outline which is invert(1) of that color.

The problem is that for my system theme, -moz-DiagogText is a dark grayish color, and invert(1) on a gray color is another gray color. :(  And the background happens to be gray, too.  So that's why this looks super fuzzy -- it's got a gray icon with a gray outline on a gray background.

Comment 4

[Daniel Holbert [:dholbert]]

In the extreme, this is worst with an exactly "halfway" gray color.  If you use Browser Toolbox to style this image with "color:#888" (simulating what would happen if we had that value for -moz-DialogText), then the icon's border and content end up pretty much the same color, which makes it look just like a weird gray blob.

The problem here is that the SVG relies on "invert(1)" to produce a highly-distinguishable "crisp accent" for the provided context color, and that's not a valid/reliable way to do that, when the color in question is a shade of gray.

It looks like this started in bug 1488617 which is where we started using currentColor here (rather than just using black & white, I think).  At least, I see this bug with:
  mozregression --launch 2018-09-06
...but I don't see the bug (i.e. I get a crisp icon) with:
  mozregression --launch 2018-09-04

...and that range includes bug 1488617.

ntim, do we really have to use currentColor here, for the default theme?  (Does it really make sense to use "-moz-DialogText" as the color of this icon?)

Comment 5

[Daniel Holbert [:dholbert]]

(BTW: I'm on Ubuntu 18.10 with the default "Yaru" theme, running Firefox Nightly 66.0a1 (2019-01-02))

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: icon with various "context-fill" colors manually specified (emulating different -moz-DialogText values)

For illustration, here's an edited version of the icon in question here, with various values for 'fill' (emulating various -moz-DialogText values that users might have).

On my system, we use this testcase's second-to-the-top fill color (i.e. that version is using my -moz-DialogText value of rgb(61, 61, 61)), and that makes for a noticeably fuzzier icon (particularly against a gray background color on an actual tab).  But the third, fourth, and fifth examples in this testcase are much worse, with more middleish-gray fill values; and it's conceivable that users could have these as their -moz-DialogText values and be hitting a more severe version of this issue as a result.

Comment 7

[Tim Nguyen :ntim]

(In reply to Daniel Holbert [:dholbert] from comment #4)
> ntim, do we really have to use currentColor here, for the default theme? 
> (Does it really make sense to use "-moz-DialogText" as the color of this
> icon?)

currentColor is the easiest way to get the icon to look correct in all possible configurations: high contrast/webextension themes/system themes/etc.

The previous way this was done was using brighttext attributes, but this didn't necessarily cover different high contrast/webextension themes properly, especially for selected vs. unselected tabs.

The text color however, holds a lot of precious information related to the theme and is automatically tuned regardless of the different themes you're using. While the brighttext attributes are based on the text color, there's no brighttext attribute giving information about the selected tab text color and adding one just for the tab audio icon would be overkill.

This invert(1) + currentColor trick was the simple thing I could find to deal with this issue.

Thinking of it, however, since what we want to do here is mask/clip the outline from the tab icon, we can maybe do this by using a mask directly behind the icon ? Or set the outline color to be the background color of the tab (although this is more tricky, as the background is the platform rendered titlebar, and not some CSS value).

Or maybe use a different SVG filter than invert ?

I'm not sure what's a good solution when it comes to performance here :/

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch in nightly 67, or potentially, in beta 66 for this.
I'm marking it fix-optional to remove it from weekly regression triage, since it has a priority assigned.