Closed Bug 1757797 Opened 2 years ago Closed 2 years ago

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

Categories

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

All
Windows 10
defect

Tracking

()

VERIFIED FIXED
101 Branch
Accessibility Severity s2
Tracking Status
firefox98 --- wontfix
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- verified

People

(Reporter: phorea, Assigned: emilio)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 files)

Attached image 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

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

Whiteboard: [access-s2]

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.

Flags: needinfo?(dao+bmo)

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

Severity: S4 → S3
Component: Tabbed Browser → Theme
Flags: needinfo?(dao+bmo) → needinfo?(petruta.rasa)
Priority: -- → P3
Summary: [win][HCM] Tabs summary is not visible with HCM#2 → [win][HCM] Tooltip text is not visible with HCM#2

(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.

Flags: needinfo?(petruta.rasa)

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?

Flags: needinfo?(emilio)
Component: Theme → Themes
Product: Firefox → Toolkit

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?

Flags: needinfo?(emilio) → needinfo?(dao+bmo)

(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.

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

Flags: needinfo?(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.

Thanks, Emilio.

Severity: S3 → --
Component: Themes → Widget: Win32
Flags: needinfo?(dao+bmo)
Priority: P3 → --
Product: Toolkit → Core
Severity: -- → S3
Priority: -- → P2
Flags: needinfo?(emilio)

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.

Assignee: nobody → emilio
Status: NEW → ASSIGNED

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

No

Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/98474ebab1ef
Don't use native tooltip drawing on Windows. r=dao,cmartin
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch

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

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.

Flags: needinfo?(emilio)

Probably not, but please correct as needed.

Flags: needinfo?(emilio)
Flags: qe-verify+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Accessibility Severity: --- → s2
Whiteboard: [access-s2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: