Affected versions

• 83.0b5
• 84.0a1 (2020-10-28)

Affected platforms

• Windows 10
• Windows 7

Steps to reproduce

1. Launch Firefox
2. Make sure print.tab_modal.enabled is set on true
3. Hit CTRL + P on any page
4. Open the Destination dropdown
5. Select Microsoft xps document writer
6. Select Black and white option from Color mode section
7. Save the page and observe the content

Expected result

• The content is black and white or the color mode should be locked on color option from the start

Actual result

• The content is colored

Regression range

• First bad: 7342399037194f8436cd9c3e08da64ec0dbe41f2
• Last good: 32c459fb79fe7998bca6975e22871c043f8dbdbe
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=32c459fb79fe7
  998bca6975e22871c043f8dbdbe&tochange=7342399037194f8436cd9c3e08da64ec0dbe41f2
• Potential regressor: 1660857

Additional notes

• The color option is applied correctly if set as color mode

Suggested severity

• S3

The same issue is encountered with OneNote Destination (on Windows). It seems that the given black&white color option is ignored and prints in color.

The severity field is not set for this bug.
:mstriemer, could you have a look please?

For more information, please visit auto_nag documentation.

It looks like the frontend is sending the correct printInColor setting here.

Emilio, could this be related to the other black and white issues happening in bug 1676191?

No, not quite related (those are CUPS related)...

The issue Microsoft XPS Document Writer driver just doesn't support monochrome, but doesn't expose that to us the same way e.g. Microsoft Print to PDF does (which we handle properly, see bug 1661720).

Bob, Jonathan, do you have a strong opinion here? I think the best we could potentially do here is blocklisting / hardcode this (and probably other "to-PDF" printers which don't support monochrome but claim to).

That's obviously not amazing, but it might be a better experience for the user? Otherwise I think this is WONTFIX/INVALID unfortunately :/

Chrome supports printing in B&W to Microsoft Print to PDF/Micosoft XPS Document Writer. Are they perhaps converting the document to B&W before sending it to the printer? Somewhat interestingly if that's what they're doing, they don't provide an option for B&W for their own print to PDF.

So, Chromium has a bunch of XPS-specific code dealing with these Win32 APIs.

It still seems like what we do should be enough though, so this really needs more investigation.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

So, Chromium has a bunch of XPS-specific code dealing with these Win32 APIs.

It still seems like what we do should be enough though, so this really needs more investigation.

emilio, can you elaborate a bit more about this? (What do we do here, i.e. where should/would someone start poking to see what's going wrong?)

(in particular: I'm confused since in comment 4 it sounded like throwing up our hands might be all we could do, vs. in comment 6 it sounds like we have code that's supposed to already handle this in some way or another. :))

Yeah so I don't recall the specifics of what I saw, but looking now I see Chromium does some checks for XPS printers in particular:

• https://source.chromium.org/chromium/chromium/src/+/main:printing/print_settings_initializer_win.cc;l=91-95;drc=ee634e7ffff11e91cd811e2f38e08460c91c45ed

And also they have some sort of specialized XPS printing codepath that I don't know what is about:

• https://source.chromium.org/chromium/chromium/src/+/main:printing/backend/win_helper.cc;l=190;drc=b6e38123599226a5db37ecc6d72e087973439ae8

It seems we could do something like adding support to "only color" in the front-end / back-end (should be trivial), and then return that for XPS printers, assuming all drivers behave similarly. That would disable the black-and-white option on XPS printers, which seems acceptable?

:jwatt should this be an S3 based on QAs recommendation ?

Also was it confirmed the regressor on this was bug 1660857?

(In reply to Dianna Smith [:diannaS] from comment #10)

Also was it confirmed the regressor on this was bug 1660857?

Sort-of, but it never really worked. For print-preview, we have a "synthetic" force-black-and-white preview feature, which it turned out we were also activating for real-printing, by accident (see bug 1660857 comment 4), which was seriously affecting our print quality (see top part of attachment 9171939 [details]). Bug 1660857 fixed that by turning off the "synthetic" force-black-and-white code for actual-printing, which is how it was supposed to be working all along.

The expectation/assumption was that the printer/print-driver would natively handling the "print in black-and-white" request on its own; but in a few cases (e.g. the print drivers in this bug) that turned out not to be true. So for those printers, our synthetic black-and-white codepath was the only thing that was making the output black-and-white. So from that perspective, this is a regression from bug 1660857.

Going through old needinfos - I guess the hardcoded route is the only option if the printer driver is not giving correct information.
Although I guess we could then implement the monochrome ourselves.