1704299 - Proton design context menus fonts are not full black

Status: RESOLVED WONTFIX

(Firefox :: Menus, enhancement)

Description

[Marian]

Attachment: Images.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36

Steps to reproduce:

Noticed that fonts are different.
Compared the 'old right click' to the new one.
And the menu from the 3 lines.

Actual results:

The font color are not full black compared to old context menu.
Seams the pixels has more light on it.

Expected results:

To be full black color

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Menus' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Attachment: context menu text contrast.png

Compared the context menu on latest Nightly 89.0a1 with Figma spec, and indeed it should have a better text contrast, thus confirming.

Comment 3

[:Gijs (he/him)]

The light mode spec has background color #f9f9fb, foreground #15141a. This is exactly what I see in devtools for the menu. Please clarify how you think this isn't matching the spec.

Comment 4

[Petruta Horea [:phorea], Desktop Test Engineering (back on Sep 5th)]

Unfortunately Browser Toolbox is broken on Windows for me (I can only use it on OSX), so I couldn't verify the exact color codes.

The contrast I was referring to in the previous attachment, might be due to font style, weight or size. I do find the text in Figma spec more darker / contrasting better with the background.

Comment 5

[Marian]

The codes are like the @Gijs says.

Old menu: RGB 0, 0, 0 / HEX #00000
Proton menu: RGB 21, 20, 26 / HEX #15141A

Comment 6

[:Gijs (he/him)]

Attachment: 100% zoom comparison (implementation left, spec right)

So the comparison from QA has the spec much more zoomed in, which allows for more definition on the text. This is a like-with-like comparison, and although there is a subtle difference there in terms of foreground/background contrast, it is entirely due to anti-aliasing, and visual effects from the shadow / surrounding colours making the shades of grey look different to the human eye. (the shadow doesn't match, that is a known compromise we had to accept for technical reasons that aren't really related to this bug)

We're not going to change the anti-aliasing implementation on Windows to behave differently just to match the particular rendering that figma uses (which is all done with canvas, wasm and server-side C++ so very much not the same font rendering engine), and with 1 day to go in the nightly cycle, I don't think there's anything we can realistically do here.

Comment 7

[:Gijs (he/him)]

Going to resolve this per comment #6 as this matches the spec as best we can given the other constraints we have.

Comment 8

[Marian]

Your proposed context menu has disabled the RGB Anti-Aliasing and that is more bat that is now.

Comment 9

[Marian]

Not sure what has to do the the shadows, foreground and background and surrounding colours with the Text Color that sound be 0,0,0 and not other color. If in code is black 0,0,0 why is other color in the software. And what has to the the human eye if the other software that you capture the image and says is other color?

Comment 10

[Marian]

Even the background is not right: 249, 249, 251 on proton. Why is more blue?
On normal is: 235,235,235

Comment 11

[Marian]

Attachment: Untitled.png

If you don't remove the old one and not make this by default, I don't really care about this. But if you plan is to change it or make it by default, try to fix it.

Comment 12

[Marian]

I just saying that color values on the https://searchfox.org/mozilla-central/source/toolkit/themes/windows/global/global.css
Why is not: --menu-background-color: #F0F0F0; --menu-color: #000000;

Is not even matching the windows background and the text like the old one.
Not sure why all colors has more blue on them...