Thread indentation lines sometimes invisible when printing if using "High Contrast Black" color scheme in Windows 10
Categories
(Core :: Layout, defect)
Tracking
()
People
(Reporter: d2ogilvi, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: [hcm-2021-h2])
Attachments
(7 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
- 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.
- Go to an email that contains a multi-level thread and open the email.
- 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.
Reporter | ||
Comment 1•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
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•3 years ago
|
||
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 😀
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
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.
Assignee | ||
Comment 5•3 years ago
|
||
It's just needless indirection.
Depends on D120677
Assignee | ||
Comment 6•3 years ago
|
||
This will come handy in the next patch.
Depends on D120678
Assignee | ||
Comment 7•3 years ago
|
||
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
Assignee | ||
Updated•3 years ago
|
Comment 10•3 years ago
|
||
bugherder |
Comment 11•3 years ago
|
||
bugherder |
Comment 13•3 years ago
|
||
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.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•1 year ago
|
Description
•