1692729 - Text gets weird subpixel-like colors on GitLab

Status: NEW

(Core :: Graphics: Text, defect)

Description

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: image.png

1. Open https://gitlab.com/wg1/jpeg-xl/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=
2. Click the Title textbox

Expected: No visual change for the text
Actual: It gets weird glitch

This is on Windows 10, and it happens with or without WebRender.

Comment 1

[Sotaro Ikeda [:sotaro]]

:jfkthame, can you comment to the bug?

Comment 2

[Jonathan Kew [:jfkthame]]

It looks like the Gitlab theme being used adds a text-shadow to the input field when focused, and this renders really poorly in combination with subpixel antialiasing and the light-on-dark colors involved.

Do you see similar issues with all Gitlab themes, or is this specific to one of them?

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: image.png

I think it also happens (but to a lesser extent) with the default light theme. (URL) See the new attachment where t and h gets red and blue lines. Chrome shows no visual change at all when clicked.

Comment 4

[Alice0775 White]

I can reproduce the issue on Windows10 with GitLab light and dark theme.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ed3ef7c26759e4a4187c65527e789ccb0fbf773d&tochange=1e5d1f957f717b896d5ffc5dcf96b70234bce8f0

Comment 5

[Kagami Rosylight [:saschanaz] (they/them)]

Oh, I can also confirm that this is a regression 👀

Comment 6

[Jonathan Kew [:jfkthame]]

They're using some Firefox-specific CSS rules such as

.form-control:-moz-focusring,
.search form:-moz-focusring {
 color:transparent;
 text-shadow:0 0 0 #fafafa
}

here, so it's not surprising behavior differs on Chrome.

FWIW, on macOS I see an apparent "thickening" of the text when focused, which I guess is the effect they're aiming for with the text-shadow, but it isn't using subpixel AA and there's no weird color effect. On Ubuntu, I do see a similar effect to the Windows issue although much less extreme; it's only clear that some ugly color fringing is happening if I enable magnification and look closely. This may be partly because I'm on a high-res screen where such artifacts are less obvious, but probably also because the subpixel AA there is much less intense than ClearType's.

(It does seem a bit surprising that they've gone to the trouble of including Firefox-specific CSS to implement this (questionable) effect, but don't seem to have anything comparable at all for Chrome -- they don't apply some different technique for "enhancing" the text of the focused control, just nothing.)

Comment 7

[Emilio Cobos Álvarez (:emilio)]

So this is an issue because we started unconditionally matching :-moz-focusring. Can we ask them to just remove that rule? It did nothing before.

This looks suspiciously close to the kind of workarounds people used to do to remove ::-moz-focus-inner ring on select, see bug 1580935. But that shouldn't be needed anymore.

An alternative for us would be to remove :-moz-focusring support, potentially, but that doesn't sound particularly risk-free.

Comment 8

[Jonathan Kew [:jfkthame]]

Attachment: simplified testcase

While it would help this particular case if we can get Gitlab to remove that styling, there's also the more general question of why we render the text so poorly here when these style rules are in effect.

One contributing factor seems to be that when the input element is focused, they apply opacity: 1 to the ::placeholder, which results in it switching from grayscale rendering to subpixel -- and hence liable to color fringing. With webrender and changing that opacity value to a bit less than 1.0, the text remains grayscale-only, which looks a little less weird. It still ends up rather blocky and ugly, however.

This simplified example has two <input>s with styling based on the gitlab case, but the second of them uses slightly-reduced opacity, so the difference can be seen. (Hover over each in turn, while looking closely at the text rendering.)

From the appearance of the grayscale hovered text in the second <input> here, it looks to me like when it is hovered (and so the text-shadow kicks in), we are losing track of the fact that the text is being drawn against a darker background. This shows up in that antialiasing pixels that should be darker than the nominal foreground color (i.e. partially blended with a dark background) suddenly become brighter instead, as if blended with a light background. Does our text-shadow painting just not know how to account for the background color?