1715783 - Black on black printing occurs with custom colors set in preferences and "High Contrast Black" color scheme in Windows 7 or 10

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[David Ogilvie]

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

Steps to reproduce:

1. Set Windows 7 or Windows 10 color scheme to "High Contrast Black".
2. Start Thunderbird.
3. Go to Tools > Options
4. In right pane, scroll down to "Colors..." button and click on it.
5. Set Text Color to white.
6. Set background colour to black.
7. Set "unvisited link color" to green.
8. Set "Visited link color" to yellow.
9. Set "Override the colors specified by the content with my selections above" to either "Only with High Contrast Themes" or "Always"
10. Open an email with text and links.
11. Press ctrl+p to print the email.

Actual results:

Headers appear as black text on a black background.
Links appear very faint, was link color is supposed to be most visible on a black background, not on white paper.
Text in previous emails in the thread appear as black text on a black background.
If "Override the colors specified by the content with my selections above" is set to "Always" and a standard Windows oolor scheme is used, then the black-on-black text described above is white-on-white instead.

Expected results:

The printout should look the same as the email when viewed with a standard Windows color scheme.
The solution to the issue is to save the user's current setting for "Override the colors specified by the content with my selections above" then setting the "Override the colors specified by the content with my selections above" to "Never" before performing the printing pass Once the printing is finished, the original setting for "Override the colors specified by the content with my selections above" should be reinstated.

Comment 1

[Thomas D. (:thomas8)]

Attachment: Screenshot 1: Black on black header printout (and custom colors still used)

Confirming exactly as described on 78.11.0 (32-bit), Win10.

Comment 2

[Thomas D. (:thomas8)]

These color settings always confuse me, but I believe that black-on-black for printout should never happen, and as it happens only to a random portion of the message, this does look like a bug. Not sure about the link colors how they should print, but probably just always printing standard colors (whatever that is) would be good enough.

Richard?

Comment 3

[Richard Marti (:Paenglab)]

Attachment: 1715783-print-background.patch

This is a beast! The colours aren't really settable by CSS. Somehow the print preparation uses a on the fly generated about:PreferenceStyleSheet that uses some colours, the link colours, that are set in the prefs. In our CSS only the header background colours are defined. And this background colours are on High Contrast (it doesn't need to be HC, only setting to Always is enough) used also when Print backgrounds is disabled!! With normal colour mode this defined background colours are only used when Print backgrounds is set.

My patch only fixes the background colour issue. The link colours aren't settable through CSS.

Comment 4

[Alessandro Castellani [:aleca]]

Does this happen also with Firefox?
Maybe this is something that should be fixed in the toolkit if it affects Firefox as well.

Comment 5

[David Ogilvie]

It does affect firefox as well. It may be something that's in the toolkit, common code to both TB and FF.

Comment 6

[Alessandro Castellani [:aleca]]

Pinging Emilio to see if he knows who we can redirect this bug to.

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1715783 - Do not backplate using a background-color that isn't drawn due to print settings. r=morgan

When printing, we lighten backgrounds and darken colors, unless color-adjust:
exact is used. So with the current backplating logic we might end up using a dark
system color background for a backplate, but then darkening the test, ending up
in both more ink being used, and the text being unreadable.

We don't have a great test story for these but I can try...

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9cff2072c592
Do not backplate using a background-color that isn't drawn due to print settings. r=morgan

Comment 9

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/9cff2072c592

Comment 10

[Emilio Cobos Álvarez [:emilio]]

I just realized that my fix isn't quite perfect, and that there's some more work to do for form controls...

Comment 11

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 1715783 - Use nsCSSRendering::DetermineBackgroundColor in backplate color computation. r=morgan

This is more correct as it takes care about falling back to white as needed in
printing mode.

This is still not perfect because themed frames still get black-on-black text.

I'm not super-sure what's the right way to fix that, will
file a follow-up for that. In particular, when you have a themed
button, we use the system colors (i.e., black) to paint
it, but nsLayoutUtils::DarkenColorIfNeeded doesn't know it
and darkens the text color anyways.

Easiest fix is just not use the system colors when
printing, but that feels not-amazing...

Comment 12

[David Ogilvie]

That might feel non-amzing, but to would likely be the easiest solution. Printing doesn't need to know about the Windows colour scheme... it should just assume standard colors and generate the print according to that scheme. Just a thought...

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Yeah, that's what I ended up doing in bug 1717245. It's not super-duper-great, but it is indeed the simpler solution.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b4e4f16482fe
Use nsCSSRendering::DetermineBackgroundColor in backplate color computation. r=morgan

Comment 15

[Atila Butkovits]

Backed out for causing failures at backplate-bg-image-006.html.

Backout link: https://hg.mozilla.org/integration/autoland/rev/56468f3987acfa2575aa6dcd64739a8adba7c6c0

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=LxBdKq1dQGO7QM5lRxI4GA.0&revision=b4e4f16482fe83abebdf70ca4f947c331b33244d&searchStr=windows10-32-qr%2Cdebug%2Creftests%2Ctest-windows10-32-qr%2Fdebug-reftest-e10s%2Cr3

Failure log: https://treeherder.mozilla.org/logviewer?job_id=343417895&repo=autoland&lineNumber=20713

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7fbc470c2f9f
Use nsCSSRendering::DetermineBackgroundColor in backplate color computation. r=morgan

Comment 17

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/7fbc470c2f9f

Comment 18

[David Ogilvie]

Attachment: email screenshot 1.png

Comment 19

[David Ogilvie]

Attachment: preview screenshot 1.png

Comment 20

[David Ogilvie]

Thanks so much for getting the printing to work in FF and TB!

There's just one small item that isn't quite right yet when printing in TB, and it may or may not be something that can be fixed easily.

Note in attachment "email screenshot 1" an email where there are multiple levels of back-and-forth between sender and recipient. Note the vertical lines showing the thread levels, some of which are white and some blue. This is fine on the screen, but notice in the print preview that the white lines don't show up. Ideally, the white lines should be black since they are being printed on white paper.

I realize this may be a hornet's nest, but thought I'd bring it to your attention anyway.

Thanks again for the great job at getting the text to print properly! This has been an issue since Netscape days.

Comment 21

[Emilio Cobos Álvarez [:emilio]]

No worries, happy to help! I don't know how the thread levels are drawn and I'm on my phone now, but it's probably worth a separate bug, should be fixable some way or another.

The email link could also have some more contrast...

Comment 22

[David Ogilvie]

Do you want me to submit a new bug on this, and a seperate one for the email link?

Comment 23

[Emilio Cobos Álvarez [:emilio]]

Yeah please do, feel free to cc me / ni? me so I dont forget to poke at it (on vacation now)

Comment 24

[Thomas D. (:thomas8)]

Awesome! - Thanks much Emilio for fixing this, and thanks Alex for inviting Emilio ;-)