Closed Bug 1672625 Opened 1 year ago Closed 1 year ago

Black and white printing prints in colour (color) on Linux

Categories

(Core :: Printing: Output, defect, P1)

Firefox 82
defect

Tracking

()

RESOLVED FIXED
84 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox82 --- wontfix
firefox83 --- fixed
firefox84 --- fixed

People

(Reporter: Smylers, Assigned: emilio, NeedInfo)

Details

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

Attachments

(1 file)

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

Steps to reproduce:

Told Firefox to print a page in black and white:

  1. Press Ctrl+P.
  2. In the print overlay that appears, change ‘Colour mode’ from ‘Colour’ to ‘Black and white’. The print preview at the left changes all the coloured parts to greyscale.
  3. Press the ‘Print’ button.

Actual results:

The web page appeared from my printer in colour.

Expected results:

It should've been in black and white.

This is my default printer on Ubuntu Mate: Canon MX475, using the official driver. Other applications print successfully in black and white, using the standard ‘Print’ dialog. As Firefox used to until recent, when the print preview window looked different to this and still used the system ‘Print' dialog.

Component: Untriaged → Printing: Output
Keywords: regression
Priority: -- → P1
Product: Firefox → Core
Summary: Black and white printing prints in colour (color) → Black and white printing prints in colour (color) on Linux
Whiteboard: [print2020_v82][old-ui+]
Flags: needinfo?(emilio)

Fun, so we're using gtk_print_settings_get_use_color and co. But as it turns out, that is only read by gtkprintoperation-win32. Hoorray: https://gitlab.gnome.org/search?utf8=%E2%9C%93&search=gtk_print_settings_get_use_color&group_id=8&project_id=665&scope=&search_code=true&snippets=false&repository_ref=master&nav_source=navbar

So we probably need to do something similar to what I'm doing for mac in bug 1670943.

(In reply to Smylers from comment #0)

Other applications print successfully in black and white, using the standard ‘Print’ dialog. As Firefox used to until recent, when the print preview window looked different to this and still used the system ‘Print' dialog.

This sounds like it's from the new print modal not the old UI using the system dialog?

(In reply to Julien Cristau [:jcristau] from comment #2)

This sounds like it's from the new print modal not the old UI using the system dialog?
Yes. Sorry, I didn't know the proper name for it.

Ah, okay. This isn't something we'll be able to fix for Firefox 82 then, particularly given that switching print.tab_modal.enabled isn't yet supported.

Whiteboard: [print2020_v82][old-ui+] → [print2020_v83][old-ui-]

(In reply to Jonathan Watt [:jwatt] from comment #4)

Ah, okay. This isn't something we'll be able to fix for Firefox 82 then, particularly given that switching print.tab_modal.enabled isn't yet supported.

I didn't specifically switch that, but I am running Beta; maybe that enabled it for me.

[And apologies for messing up the Markdown in my previous comment.]

(In reply to Smylers from comment #5)

(In reply to Jonathan Watt [:jwatt] from comment #4)

Ah, okay. This isn't something we'll be able to fix for Firefox 82 then, particularly given that switching print.tab_modal.enabled isn't yet supported.

I didn't specifically switch that, but I am running Beta; maybe that enabled it for me.

Yes, that explains, it's enabled for some portion of beta. Thanks for the followup :)

Ah, good to know, thanks. And no worried about the markdown thing or any confusion, we're just glad to have your report.

All Beta users get the new user interface for the first two weeks of beta, and half of them for Beta 82 have been getting the new user interface for the remaining two weeks. The user agent reported in comment 0 is Firefox 82 which is the current release version, which is why I thought we were dealing with Release here. But I guess your Beta just hasn't had its version number bump to report as Firefox 83 yet.

Assignee: nobody → emilio
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(emilio)

We do it in nsDeviceContextSpecG since that's what actually consumes the
settings. On GTK the options need to be prefixed by cups- for some
reason in order to work, so factor out a macro listing the options and
do the NSString / cups- prefixing in the platform specific places.

Severity: -- → S2
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4f179bf502ce
Make monochrome support on GTK work like on Mac. r=jfkthame
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 84 Branch

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Do we need to do something for Beta here or can this ride 84 to release?

Flags: needinfo?(emilio)

Comment on attachment 9183258 [details]
Bug 1672625 - Make monochrome support on GTK work like on Mac. r=jfkthame

Beta/Release Uplift Approval Request

  • User impact if declined: Printing in monochrome from the new UI doesn't work on Linux.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Try to print in monochrome from the new ui.
  • List of other uplifts needed: Bug 1670943
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Relatively simple, pref-gated change.
  • String changes made/needed: none
Flags: needinfo?(emilio)
Attachment #9183258 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9183258 [details]
Bug 1672625 - Make monochrome support on GTK work like on Mac. r=jfkthame

P1, fix for an obvious bug in our new print UI on Linux, approved for 83 beta 8, thanks.

Attachment #9183258 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
QA Whiteboard: [qa-triaged]

Hello, I came across this issue under macOS 10.15.7 and Windows 7 too. It seems that Ubuntu 20.04 is still affected with 84.0a1 (2020-11-09). The model of the printer is HP Officejet 6500 E710n-z. Should I file a new bug for macOS and Windows or they will be covered here too?

Flags: needinfo?(emilio)

Interesting, HP should be covered by this line, might be a printer-specific/driver issue...

Could you file a new bug? And if you could, could you paste the name of the printer driver you're using?

For example, on Linux that'd be going to http://localhost:631/printers/, then clicking on your printer, and then pasting the contents of the Driver: row, like:

Driver: Brother HL-4040CN - CUPS+Gutenprint v5.3.3 (color, 2-sided printing)

That should allow me to investigate it. Thank you Catalin!

Flags: needinfo?(emilio) → needinfo?(catalin.sasca)

Here's the filed issue Emilio, Bug 1676191. Please let me know if I can help with anything else.

Flags: needinfo?(catalin.sasca)

Hello Smylers!

Unfortunately we don't have access to a Cannon printer in order to verify if this issue is fixed or not. We tried to verify this by using our HP printer but those drivers seem to be still affected.

Could you help us by confirming that this issue is indeed fixed for you?

We would need a confirmation for both Nightly & Beta builds. You can get them from here: https://www.mozilla.org/en-US/firefox/channel/desktop/

Please note that on Firefox Beta, you need to manually enable the new print ui feature by following these steps:

  1. Access the about:config page.
  2. Search for print.tab_modal.enabled pref.
  3. Switch it's value to true.

Thank you very much!

Flags: needinfo?(Smylers)

Setting the qe-verify flag to - since we don't have access to a Cannon printer in order to verify this fix.

Flags: qe-verify+ → qe-verify-
You need to log in before you can comment on or make changes to this bug.