2030650 - Firefox is printing in color even when choosing printing in black and white

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[David VANTYGHEM]

Attachment: Capture d’écran du 2026-04-09 13-38-31.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:149.0) Gecko/20100101 Firefox/149.0

Steps to reproduce:

I print a web page or a PDF with Firefox menu File - Print...
Then, I choose Black and White in the preview interface, choose to print the current page choose my printer (Brother HL-3170CDN) and click on Print button.

Actual results:

The preview is in black and white but the printed page is in color.

Expected results:

The printed page should be in black and white.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Printing: Output' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Daniel Holbert [:dholbert]]

Could you check if you get the same results from other programs (with the same printer)?

As I recall, the black and white setting is really just a flag that we pass to the printer, so it's possible the printer is ignoring it... (e.g. due to a bug in the printer driver)

Comment 3

[David VANTYGHEM]

When I print with Thunderbird, it works, I've got the problem only with Firefox, since a few days (after an update?).

Comment 4

[Daniel Holbert [:dholbert]]

Thanks. The most recent update would have been 149.0.2, in which I think the only clearly-print-related change was for bug 2026109; but that wouldn't have had any impact on print settings at all, let alone color-printing, so it's unlikely for that update to have been responsible for breaking this...

We've had older reports of this same sort of issue a few years back, in bug 1846816 -- but in that case at least, it likely wasn't a Firefox-specific bug because affected users observed that Chrome was also hitting the same problem.

I don't have a color printer available locally, so I can't directly investigate to try to confirm at the moment. (I do have a virtual "cups-PDF" software-printer installed, which supposedly supports color-or-monochrome printing, but everything I print to it always ends up producing a color PDF, regardless of that setting, no matter what program I use to print to it.)

Could you check a few things:
(1) Could you also try printing from a non-Mozilla program -- e.g. your PDF viewer (probably evince or papers) with a PDF that has color, like this one: https://www.adobe.com/support/products/enterprise/knowledgecenter/media/c4611_sample_explain.pdf

If that prints in color when you ask for black-and-white, then I think we can rule out a Firefox bug here.

But if that behaves as you expect (it respects your black-and-white print setting), my next questions would be:

(2) Are you running Firefox 149.0.2? (Help | About)

(3) Is your Thunderbird version 149.0.2 as well? (That's the latest release for thunderbird - and if you've got the same Thunderbird/Firefox release version, their print backends should essentially work the same, which would make your observation in comment 3 surprising...)

(3) Could you double-check that the content you're testing in Thunderbird actually has color elements to be printed? (note that background colors/images are suppressed if the "print backgrounds" checkbox is unchecked) One good testcase there would be the "Troubleshooting Information" built-in page, which has some blue links on the first page. (You can get there from Thunderbird's main "hamburger" menu, Help, Troubleshooting Information")

(4) Are you using the same built-in print-preview UI for both Firefox and Thunderbird? (i.e. you're not clicking through to "Print using System Dialog")

Also: if this really did just become broken recently, https://mozilla.github.io/mozregression/ is a tool that you can use to bisect among Firefox Nightly builds to see which one is the first-bad one (usually only requiring 5-10 trials through the magic of binary-search -- maybe a few more if we're able to bisect per-changeset builds on the first-bad day).

Comment 5

[David VANTYGHEM]

1. I printed https://www.adobe.com/support/products/enterprise/knowledgecenter/media/c4611_sample_explain.pdf with https://github.com/linuxmint/xreader/
   It's printed in black and white when I choose to print in black and white.

2. I'm using Mozilla for Linux Mint version 149.0.2 (64 bits).

3. I'm using Thunderbird for Linux Mint version 140.9.1esr (64 bits).

4. The "Troubleshooting Information" built-in page has blue links and blue tables background on the screen but there's no menu or icon to print it with Thunderbird.

5. In both cases, I use File - Print menu, then there's a preview where the page is displayed in black and white, then I click on Print button.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to David VANTYGHEM from comment #5)

I printed [...] with https://github.com/linuxmint/xreader/
It's printed in black and white when I choose to print in black and white.

OK, thanks. That increases the confidence that this is indeed a Firefox bug then (as compared to bug 1846816 where it seemed to be system-wide).

I'm using Thunderbird for Linux Mint version 140.9.1esr (64 bits).

Ah, OK. Then this might affect Thunderbird as well when you update to > 149, I guess.

The "Troubleshooting Information" built-in page has blue links and blue tables background on the screen but there's no menu or icon to print it with Thunderbird.

If you press Ctrl+P, it would give you a print dialog there. (But probably no need.)

In both cases, I use File - Print menu, then there's a preview where the page is displayed in black and white, then I click on Print button.

Thanks - that sounds like the same built-in print UI in Firefox and Thunderbird, then.

Comment 7

[Daniel Holbert [:dholbert]]

Given that this seems to be a recent regression (between 140 and 149 at least, based on your Thunderbird vs Firefox versions), that gives a bit of a possible regression window. Looking back in commits from the v140-149 timeframe, it's conceivable this could have been from bug 1985667 ("Simplify GTK CUPS monochrome implementation")... That landed in Firefox 144. Would you mind testing Nightly builds before/after that change landed, to see if that's where the issue appeared?

You can do that using mozregression if you're willing to install that tool: https://mozilla.github.io/mozregression/

With that installed, you would try this:

(launching build before bug 1985667's patch, suspecting "good"):
mozregression --launch 2025-09-06

(launching build after bug 1985667's patch, suspecting "bad"):
mozregression --launch 2025-09-07

Or if you'd prefer, you could download the first 2025-09-06 Nightly build vs. last 2025-09-07 build directly from FTP (and extract/launch them), but it's a few more steps and easier to mess up, so mozregression helps to simplify the process.

Either way, it'd be great to know whether each of those two builds is "good" vs "bad". Thanks!

Comment 8

[David VANTYGHEM]

I tried with CTRL-P in Thunderbird and B&W preview of "Troubleshooting Information" is printed in B&W.

Comment 9

[Daniel Holbert [:dholbert]]

Thanks! That confirms 140 is "good".

See request jn comment 7 which would potentially confirm the suspected patch that introduced this, if you don't mind...

Comment 10

[David Shin[:dshin]]

Hi, I unfortunately don't have a color printer to try and repro this.
It'd be great if you could try comment 7, or try to print with print.cups.monochrome-gtk-simple.enabled set to false, which was introduced in bug bug 1985667.

Comment 11

[David VANTYGHEM]

When I print in B&W with print.cups.monochrome-gtk-simple.enabled set to true, it's printed in color.
When I print in B&W with print.cups.monochrome-gtk-simple.enabled set to false, it's printed in black and white.

Comment 12

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 1985667, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2030650 - Keep applying setting whack-a-mole on CUPS monochrome. r=#layout

Comment 14

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1985667

Comment 15

[Emilio Cobos Álvarez [:emilio]]

A bit sad. This is technically a driver bug, because the CUPS setting would be nice to honor. But...

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a46e4e3a5a93
https://hg.mozilla.org/integration/autoland/rev/1069339d6762
Keep applying setting whack-a-mole on CUPS monochrome. r=layout-reviewers,dshin

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/5c4c95556ece
https://hg.mozilla.org/integration/autoland/rev/1d1882ae47a9
Revert "Bug 2030650 - Keep applying setting whack-a-mole on CUPS monochrome. r=layout-reviewers,dshin" build bustages in sPrinterCUPS.cpp

Comment 18

[Cristian Tuns]

Backed out for causing build bustages

• Backout link
• Push with failures
• Failure Log
• Failure line: ./../../../checkouts/gecko/widget/nsPrinterCUPS.cpp:X:23: error: no member named 'print_cups_monochrome_enabled' in namespace 'mozilla::StaticPrefs'

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b916db80d2d1
https://hg.mozilla.org/integration/autoland/rev/cffe0e35e76b
Keep applying setting whack-a-mole on CUPS monochrome. r=layout-reviewers,dshin,dholbert

Comment 20

[amarc]

https://hg.mozilla.org/mozilla-central/rev/cffe0e35e76b

Comment 21

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox151 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[Emilio Cobos Álvarez [:emilio]]

I'd rather let printing fixes ride the trains, there's always new surprises.