1757797 - [win][HCM] Tooltip text is not visible with HCM#2

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[Petruta Horea [:phorea], Desktop Test Engineering]

Attachment: tabs summary.png

Note

• Reproduced only with Windows High Contrast #2 - default settings

Affected versions

• Firefox 98.0 RC
• Nightly 99.0a1

Affected platforms

• Windows 10 with High Contrast # 2

Steps to reproduce

1. Open Firefox when HC#2 is active
2. Open several tabs and hover them to see their summary
3. Hover all icons on toolbar

Expected result

• Tooltip text is readable in HCM

Actual result

• Text is not visible

Regression range

• Reproduced on a 77 build, so not a regression

Comment 1

[Eitan Isaacson [:eeejay]]

Since the tooltip text seems to be completely unreadable I am designating this as access-s2

Comment 2

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

The severity field for this bug is set to S4. However, the accessibility severity is higher, [access-s2].
:dao, could you consider increasing the severity?

For more information, please visit auto_nag documentation.

Comment 3

[Dão Gottwald [:dao]]

What tooltip colors do you get in other applications? Are we using the wrong background color here or the wrong text color?

Comment 4

[Petruta Horea [:phorea], Desktop Test Engineering]

(In reply to Dão Gottwald [::dao] from comment #3)

What tooltip colors do you get in other applications? Are we using the wrong background color here or the wrong text color?

Most apps have green text (the default text set for High Contrast # 2) for tooltips.
Comparing with High Contrast # 1, where the default text is yellow on black background, I think the wrong text color is used here. Every tooltip is affected, I've updated the description.

Comment 5

[Dão Gottwald [:dao]]

So we use -moz-default-appearance: tooltip; and color: InfoText; (see https://searchfox.org/mozilla-central/source/toolkit/themes/windows/global/tooltip.css) and we probably need to use color: windowtext; instead. Emilio, can you tell if there's still a case where we use the background-color: InfoBackground; fallback?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Hmm, according to https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor InfoText / InfoBackground are the right color pair to use... And the native tooltip drawing code basically just uses that, so I'm surprised this is happening.

What does the InfoBackground color compute to in that setup? Is it transparent? Or is it somehow black in both?

Comment 7

[Dão Gottwald [:dao]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

Hmm, according to https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getsyscolor InfoText / InfoBackground are the right color pair to use... And the native tooltip drawing code basically just uses that, so I'm surprised this is happening.

But note that the page says "Windows 10 or greater: This value is not supported."

What does the InfoBackground color compute to in that setup? Is it transparent? Or is it somehow black in both?

Hm, I think I've already upgraded to Win11 which has different high contrast themes, but I'll double check.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

I have a win10 machine, I can try to poke.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

The color computes to opaque yellow, so using appearance: none would fix the rendering. So this seems a bug in the windows native theme.

Comment 10

[Dão Gottwald [:dao]]

Thanks, Emilio.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1757797 - Don't use native tooltip drawing on Windows. r=dao!,cmartin!

This removes the rounded, native-looking tooltips on Windows 7, but I don't
think it's too concerning, let me know if you disagree. I'm not sure what's
our Windows 7 support status, but in any case this regression would be
relatively minimal.

On regular (non-HCM) Windows 10+ we just fill a rect with infobackground color
and so on, so there shouldn't be any effective behavior change.

On HCM we go through the themed codepath and fail catastrophically, so just
don't do it.

Comment 12

[Morgan Reschenberg [:morgan]]

Does this affect how we respond to OS font scaling at all?

Comment 13

[Emilio Cobos Álvarez (:emilio)]

No

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/98474ebab1ef
Don't use native tooltip drawing on Windows. r=dao,cmartin

Comment 15

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/98474ebab1ef

Comment 16

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

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 17

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 18

[Emilio Cobos Álvarez (:emilio)]

Probably not, but please correct as needed.

Comment 19

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this on Firefox 100.0(20220428192727) on Win10 64-bits. Verified as fixed on Firefox 101.0b7(20220515185854), Nightly 102.0a1(20220515214519) on Win10 64-bits.