Open Bug 1668813 Opened 4 years ago Updated 3 years ago

On Ubuntu, the Color Mode dropdown is not locked to Black&White for B&W printers


(Core :: Printing: Setup, defect, P3)




Tracking Status
firefox-esr78 --- unaffected
firefox81 --- unaffected
firefox82 --- wontfix
firefox83 --- wontfix
firefox84 --- wontfix
firefox85 --- fix-optional


(Reporter: noni, Unassigned)


(Blocks 1 open bug, Regression)


(Keywords: regression, Whiteboard: [print2020][old-ui-] )


(1 file)

Attached image color_mode_drowdown

Affected versions

  • Latest 83.0a1
  • 82.0b6

Affected platforms

  • Ubuntu 18.04 & 20.04
  • Windows 7 x64

Steps to reproduce
Precondition: A black and white printer is available.

  1. Launch Firefox (make sure print.tab_modal.enabled is set on true).
  2. Open any page and hit Ctrl +P.
  3. Switch between destinations and select the printer.
  4. Observe the "Color mode" dropdown.

Expected result

  • The selection rectangle is locked on "Black and white" if the printer does not support color printing.

Actual result

  • The user is able to select Color printing.

Regression range

  • I think this is a recent regression, will follow`up on this matter asap.

Additional notes

  • Reproduced with a Kyocera ECOSYS P2135dn and a HP MFP M28a printers.
  • Unable to reproduce on Windows 10x64 and macOS 10.15.

Suggested severity

  • S3
Has Regression Range: --- → no
Has STR: --- → yes

We should be careful when fixing this. We've had the opposite problem, where people who have color printers have the option locked to "Black and White", and that's worse. It's a lot more annoying to have a valid option that should work (color printing) taken away than it is to be given the option to print in color to a printer the user should know doesn't support it, and have the printer output Black and White.

Interesting that this affects Windows. (I kind of expect this from CUPS given the number of bugs we've been encountering.)

Priority: -- → P2
QA Whiteboard: [qa-regression-triage]

Setting this to S3 based on comment #1 making this P2 - is it really P2? I wouldn't have been surprised to see this at P3 / S4 given the disclaimers...

Severity: -- → S3

Yeah, agreed. Also this is really the responsibility of the platform code to get right.

Component: Printing → Printing: Setup
Priority: P2 → P3
Product: Toolkit → Core
Regressed by: 1662518

Bug 1662518 couldn't have broken this for Window 7, which you reported is also affected in comment 0. Would you be able to find a separate regression range for that?

Emily, it seems like things worked in Ubuntu 18.04 and 20.04 before bug 1662518. Does the patch for that bug causing this regression make any sense to you?

Flags: needinfo?(emcdonough)
Flags: needinfo?(cornel.ionce)

Double checked and it seems that I`m unable to reproduce this anymore on Windows 7 x64 using latest Nightly and Fx 83.0b3 on the same machine.
The color mode is now locked on "Black & white":

Flags: needinfo?(cornel.ionce)


OS: All → Linux
Summary: Color mode dropdown is not locked for Black&White printers → On Ubuntu, the Color Mode dropdown is not locked to Black&White for B&W printers

I could believe that bug 1662518 could cause this. I'll take close look.

Whiteboard: [print2020_v83][old-ui-] → [print2020_v84][old-ui-]

On CUPS at least, we have kind of worked around questionable platform behavior by just allowing printing to color:

Without being able to reproduce this, right now I suspect this is that case. We are getting back an unexpected result from CUPS, and so we are defaulting to allowing color even though the printer doesn't support it.

It might be worth adding some level of debugging to what CUPS_PRINT_COLOR_MODE is returning for cases like this.

Flags: needinfo?(emcdonough)
Whiteboard: [print2020_v84][old-ui-] → [print2020_v86][old-ui-]
Whiteboard: [print2020_v86][old-ui-] → [print2020_v88][old-ui-]
Whiteboard: [print2020_v88][old-ui-] → [print2020][old-ui-]
You need to log in before you can comment on or make changes to this bug.