Closed Bug 1717873 Opened 2 years ago Closed 1 year ago

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

Categories

(Core :: Layout, defect)

x86_64
Windows 10
defect

Tracking

()

VERIFIED FIXED
92 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- wontfix
firefox90 --- disabled
firefox91 + wontfix
firefox92 --- verified

People

(Reporter: d2ogilvi, Assigned: emilio)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [hcm-2021-h2][access-s3])

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:

  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.

Attached image email screenshot 1.png
Flags: needinfo?(emilio)
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Blocks: hcm
Status: UNCONFIRMED → NEW
Component: Theme → Layout
Ever confirmed: true
Flags: needinfo?(emilio)
Product: Thunderbird → Core
Version: Thunderbird 91 → unspecified
Attached file 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?

Flags: needinfo?(mreschenberg)

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 😀

Flags: needinfo?(mreschenberg)
Severity: -- → S3
Blocks: 1716349
Assignee: nobody → emilio
Flags: needinfo?(emilio)

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.

It's just needless indirection.

Depends on D120677

This will come handy in the next patch.

Depends on D120678

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

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/68b2122a86a9
Move link color styles to ua.css. r=morgan
Pushed by ealvarez@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

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.

Status: RESOLVED → VERIFIED

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.

Keywords: access
Whiteboard: [hcm-2021-h2][access-s3]
You need to log in before you can comment on or make changes to this bug.