Open Bug 1596050 Opened 4 months ago Updated 3 months ago

Text selection while Windows High Contrast is running becomes invisible in Firefox

Categories

(Core :: Layout: Text and Fonts, defect, P1)

defect

Tracking

()

People

(Reporter: stommepoes, Assigned: emilio)

Details

(Keywords: access, leave-open, Whiteboard: [access-p1])

Attachments

(3 files)

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

Steps to reproduce:

  1. Turn on Windows High Contrast (Windows 10, 8, 7, XP, doesn't matter):
    On Windows, activate the High Contrast setting using the Alt+Shift+PrtScn shortcut, or access it via the Access Settings (Windows Key + U, or via Start Menu → Settings → Ease of Access). It does not matter which theme is chosen.
  2. Open Firefox and view a web page which uses CSS ::selection properties to set a custom selection highlight. For example, https://www.smashingmagazine.com/2019/11/newspapers-teach-web-design
  3. Select some text, either with the mouse or by using caret navigation (Shift+arrows).
  4. Observe the selected text.
  5. Perform the above steps in another browser which supports WHC (Edge, IE11).
  6. Observe the selected text.

Actual results:

No selection highlight is seen in Firefox.
Selection highlight is seen in other WHC-supporting browsers (Edge, IE11), albeit with the WHC selection colours and not those of the site.

Expected results:

A selection highlight should be visible in Firefox.

Note: the URL visible in the screenshots does not have complete test results. I am waiting access back to my server.

A github bug which described this bug: https://github.com/csstools/sanitize.css/issues/173

Component: Untriaged → Layout: Text and Fonts
Product: Firefox → Core

It looks like there's code in widget/windows to detect if High Contrast mode is on. Perhaps we should just be ignoring any CSS-specified ::selection colors in this case -- :Jamie, WDYT?

Flags: needinfo?(jteh)

So, this should be happening already, due to the "ignored_when_colors_disabled" stuff. The issue in that case is that we'd end up with the inherited color, I guess, which is not what we want in this case.

So maybe we need a check for that before computing the ::selection style...

Assignee: nobody → emilio
Status: UNCONFIRMED → NEW
Ever confirmed: true

This was a follow-up from the backplate stuff which I requested but didn't
happen.

Keywords: leave-open
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2a60597c2972
Centralize logic to ignore document colors. r=jfkthame
Flags: needinfo?(jteh)
Keywords: access
Whiteboard: [access-p1]
Attachment #9108990 - Attachment description: Bug 1596050 - When ignoring document colors, ignore ::selection styles altogether. r=jamie → Bug 1596050 - When ignoring document colors, ignore ::selection styles altogether. r=morgan
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6c09d8b07585
When ignoring document colors, ignore ::selection styles altogether. r=morgan
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/eab89fc5733a
When ignoring document colors, ignore ::selection styles altogether. r=morgan
You need to log in before you can comment on or make changes to this bug.