1717873 - Thread indentation lines sometimes invisible when printing if using "High Contrast Black" color scheme in Windows 10

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[David Ogilvie]

Attachment: preview screenshot 1.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

1. Set Windows 10 color scheme to "High Contrast Black" (Settings > Ease of Access > High Contrast > Choose a scheme > High Contrast Black) can use left Alt+left+shift + PrtScr to toggle between High Contrast and standard color scheme.
2. Go to an email that contains a multi-level thread and open the email.
3. Bring email up in Print Perview (ctrl+p)

Actual results:

See "email screenshot 1" for what is on screen and "preview screenshot 1" for what is shown in print preview.

Note that vertical thread indentation lines are visible on the screen but are not always visible on print preview.

Expected results:

The thread indentation lines that are white should show up as black on the print preview screen.

Comment 1

[David Ogilvie]

Attachment: email screenshot 1.png

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Attachment: testcase

So this one seems not-quite-trivial to fix, because we don't auto-darken border colors, and we use system colors instead. As the system text color is white, then we paint white, which is pretty sadge.

Options:

• Don't force colors at all when printing: This would fix most of these, because pages are unlikely to use system colors for stuff like borders, but pages could still cause this effect with currentColor and the default text color or such, which is bad.

• Don't use the high-contrast system colors when printing at all. This seems a bit more preferrable, but then we need to figure out which system colors to use... Perhaps just the standins?

Morgan do you have thoughts?

Comment 3

[Morgan Reschenberg [:morgan]]

Ooh this is weird...
Do we have any support right now for things like forced-color-adjust / print-color-adjust? I ask because the latter mentions If user agents allow users to control [the color palette] of the document’s display, the user preference must be respected more strongly than the hint provided by print-color-adjust.. I wonder if (a) this means generally that user-made adjustments should always be rendered when printing and (b) if HCM falls into this category, since it's something the user has altered with intention. Do they intend for that alteration to extend to printing, though? I'd say probably not... What do you think?

Anyway, it sounds like, apart from respecting those (^) properties where implemented, we need to decide on a "default" behaviour, right?
I don't think we should get rid of all forced colors when printing, but since it seems right now that the HCM ones in particular are causing problems, maybe your second solution is the way to go. Using the standins sounds fine to me, I don't have any alternative suggestions 😀

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1717873 - Move link color styles to ua.css. r=morgan,#style

We expose these via CSS system colors, so this way we don't need to
rebuild the preference sheet when the link color is different.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1717873 - Remove some things that don't change per document from PreferenceSheet. r=morgan

It's just needless indirection.

Depends on D120677

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1717873 - Factor PreferenceSheet colors to its own struct. r=morgan

This will come handy in the next patch.

Depends on D120678

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1717873 - Print documents shouldn't use system colors when in hcm. r=morgan

Instead, use default colors.

Testing this properly requires writing test infrastructure for paged tests with
"print backgrounds" settings turned off, not sure if worth it.

Depends on D120679

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/68b2122a86a9
Move link color styles to ua.css. r=morgan

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e22605c20197
Remove some things that don't change per document from PreferenceSheet. r=morgan
https://hg.mozilla.org/integration/autoland/rev/dde0d94e689a
Factor PreferenceSheet colors to its own struct. r=morgan
https://hg.mozilla.org/integration/autoland/rev/7b4b180bf393
Print documents shouldn't use system colors when in hcm. r=morgan

Comment 10

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/68b2122a86a9

Comment 11

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/e22605c20197
https://hg.mozilla.org/mozilla-central/rev/dde0d94e689a
https://hg.mozilla.org/mozilla-central/rev/7b4b180bf393

Comment 13

[Daniel Bodea [:danibodea]]

I have verified this fix with the TC in comment 2 in Windows 10 with Nightly v92.0a1 from 2021-08-02.
Note: It is still reproducible in Beta v91.0b9.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

My understanding is that this isn't a new issue, but it became more visible due to macOS HCM support shipping in 91. Given where we are in the cycle, it's too late to uplift this to 91 at this point, but we'll leave it on the radar for ESR uplift still in the next cycle.