Closed Bug 1666964 Opened 4 years ago Closed 4 years ago

bad default paper size

Categories

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

Firefox 82
Unspecified
Linux
defect

Tracking

()

RESOLVED FIXED
83 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox81 --- disabled
firefox82 + fixed
firefox83 --- fixed

People

(Reporter: karlt, Assigned: nordzilla)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [print2020_v82])

Attachments

(1 file)

  1. mozregression --launch 12b9a9eaa01028206062824f2e585ad1862cf188 --repo autoland
  2. Hamburger
  3. Print
  4. "Esc" and go to 2 as necessary to see print overlay contents.
  5. "Print using the system dialog"
    ("More settings" works if you have a new enough revision.)
  6. Page Setup

Expected:
Paper size: A4.

Actual:
Paper size: na_letter.

Last good revision: 6de217c870da1bca0141ab610eb46b9aec91b840
First bad revision: 12b9a9eaa01028206062824f2e585ad1862cf188

[Tracking Requested - why for this release]:
Regression in prominent Shirley feature.

There is a workaround to manually set the paper size, but the bug is hidden behind "More settings", so most users will get bad print results before searching for that.

Flags: needinfo?(sfoster)

Why would you expect it to choose A4 over Letter?
(Serious question. I'm trying to figure out when we should pick which paper size as default.)

Whiteboard: [print2020_v82]

(In reply to Karl Tomlinson (:karlt) from comment #0)

Last good revision: 6de217c870da1bca0141ab610eb46b9aec91b840
First bad revision: 12b9a9eaa01028206062824f2e585ad1862cf188

Link for convinience for others wanting to see the actual changes (it's a single commit):

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6de217c870da1bca0141ab610eb46b9aec91b840&tochange=12b9a9eaa01028206062824f2e585ad1862cf188

I see this incorrect defaulting to Letter on my Ubuntu 20.04 machine with print.tab_modal.enabled = true (it does not happen if I switch it to false).

nsIPrinter.paperList returns the following from the printer, in this order:

  • na_index-3x5_3x5in
  • na_monarch_3.875x7.5in
  • na_number-10_4.125x9.5in
  • iso_a6_105x148mm
  • iso_dl_110x220mm
  • iso_a5_148x210mm
  • iso_c5_162x229mm
  • iso_b5_176x250mm
  • na_executive_7.25x10.5in
  • iso_a4_210x297mm
  • na_letter_8.5x11in
  • na_foolscap_8.5x13in
  • na_oficio_8.5x13.4in
  • na_legal_8.5x14in

nsIPrinter.createDefaultSettings() returns na_letter_8.5x11in as the default paper size, despite me buying this printer in the UK.

That's...not great. Especially as Karl points out since the paper size in collapsed in the "More Settings" section.

This will basically occur to Linux users in locales that prefer metric paper sizes when there isn't a saved paper size for the printer in their prefs. So it will happen when people:

  • update to Firefox 82, due to bug 968753 changing the print pref paths on Linux
  • use a printer for the first time
    • including when they install Firefox for the first time
    • including when they use the printer with a new profile

I haven't got to digging into exactly why the default paper size appears to respect the locale prior to bug 1660527, but presumably it's due to some GTK setup API that we're using that does that magic under the hood. It would be good to figure out exactly what that API does in this regard to replicate it for consistency.

Passing CUPS_MEDIA_FLAGS_READY when we call cupsGetDestMediaDefault would presumably help for printers that support media sensing, but I'm guessing that's a minority of printers.

Maybe just having nsPrinterCUPS::DefaultSettings() get the full list of printers and switch the default from Letter to A4 if both are supported and the system locale is not en-US or en-CA (or something) would be sufficient. Or less bad.

Priority: -- → P2

I should mention the following from my about:support:

Application Settings
Requested Locales: ["en-GB"]
Available Locales: ["en-GB", "en-US"]
App Locales: ["en-GB", "en-US"]
Regional Preferences: ["en-GB"]
Default Locale: "en-GB"

Operating System
System Locales: ["en-GB"]
Regional Preferences: ["en-GB"]

Curiously, when printing to the same printer on Mac, cupsGetDestMediaDefault does return the default as iso_a4_210x297mm.

Component: Printing → Printing: Setup
Product: Toolkit → Core

(In reply to Blake Winton (:bwinton) (:☕️) from comment #2)

Why would you expect it to choose A4 over Letter?
(Serious question. I'm trying to figure out when we should pick which paper size as default.)

http://localhost:631/printers/ shows only one printer.
Following the link for that has

Defaults:	job-sheets=none, none media=iso_a4_210x297mm sides=one-sided

This is the same printer selected by default in both Firefox and system dialogs (as expected), but the defaults for the other printers have also regressed from A4 to na_letter.

To check that /etc/papersize was not used, I changed its contents to "letter", systemctl restart cups.service, and ran STR with last good revision. All printers, including "Print to File", were still defaulting to A4.

I also have

% locale LC_PAPER
297
210
UTF-8

but i don't know how to change that:

% LC_PAPER=C locale LC_PAPER
297
210
ANSI_X3.4-1968

Erik, I seem to remember you mentioning encountering one CUPS API returing the correct thing, but another not. Is there a bug on that? Or can you note what you know here? Even better if you can come up with a patch! ;-)

Flags: needinfo?(sfoster) → needinfo?(enordin)

At the time of https://bugzilla.mozilla.org/show_bug.cgi?id=147419#c85, the default came from gtk_paper_size_new() from the locale.

Since https://hg.mozilla.org/mozilla-central/rev/45a665ae8dc7e96651ad15bfd002a4ca13f04191, the paper size comes from the GtkPageSetup. I guess something might now be overriding the paper size on that?

I've been thinking on this and trying to think of what you might be referring to, jwatt.
I will keep thinking on it, but I'm not coming up with anything right now.

Flags: needinfo?(enordin)

Sorry, I misremembered. It was Hiro. See for example bug 1664009 comment 17 and 18, and bug 1663503 comment 23.

Flags: needinfo?(hikezoe.birchill)
Severity: -- → S3

This is bit annoying. As I said in bug 1664009 comment 17, cupsGetDestMediaDefault doesn't work properly at least on Ubuntu 20.20, but it seems to work pretty fine on Mac as I said in bug 1664009 comment 18 (whereas cupsFindDestDefault doesn't work on Mac). So probably we need ifdefs there.

An additional note I noticed is that GTK+ also queries "media-default" value via ippBlahBlah functions which is an equivalent way with calling cupsFindDestDefault with "media" (which is used in Chrome).

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
Flags: needinfo?(hikezoe.birchill)
Assignee: hikezoe.birchill → enordin

cupsGetDestMediaDefault seems to not be returning the correct defaults,
so this patch retrieves the default media through the IPP attribute
instead, in hopes that this will provide more accurate defaults.

I uploaded a patch that changes the retrieval of the default media to use the IPP attribute instead of cupsGetDestMediaDefault.

jwatt, maybe you want to try pulling the changes down locally and testing that this retrieves the expected paper size for your printers now?

Flags: needinfo?(jwatt)
Attachment #9177790 - Attachment description: Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt → Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt,hiro

I did try the patch. It's pretty close. :) On my ubuntu 20.20 the default paper size of a printer is "om_postcard-borderless_100x148mm", it's border-less one. but unfortunately with the patch the default paper size is "100 x 148 mm" instead of the borderless one.

Note that on the system dialog, the paper sizes are translated, in my case, both are translated "ハガキ". :/ it's hard to tell whether it's correct in the system dialog. :/

Hmm, interesting. Even with CUPS_MEDIA_FLAGS_EXACT, the correct one isn't picked up. And I also noticed that on Chrome there is no distinction between borderless and non-borderless, there is a single entry for "Postcard". So it's not a big deal, I guess?

Hmmm. I'm trying to think of what else we might be able to try. If the IPP attribute isn't able to correctly distinguish the borderless aspect, I'm not sure what else we can do. Thinking...

Attachment #9177790 - Attachment description: Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt,hiro → Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt
Attachment #9177790 - Attachment description: Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt → Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt,hiro
Pushed by enordin@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/e84353b84ec9 Retrieve Printer Default Media Through IPP Attribute r=hiro

https://phabricator.services.mozilla.com/D91376?id=344256 finds the desired paper size to show "210 x 297 mm" in the Firefox overlay, thanks, and seems to pass that through to the system dialog, which shows A4.

Thank you, Karl for the quick confirmation. (I am seeing you looks like on PTO though)

Flags: needinfo?(jwatt)
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch

Comment on attachment 9177790 [details]
Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt,hiro

Beta/Release Uplift Approval Request

  • User impact if declined: Most Linux users will end up printing to the wrong page size the first time they print to a printer after updating to v82.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky):
  • String changes made/needed:
Attachment #9177790 - Flags: approval-mozilla-beta?

Comment on attachment 9177790 [details]
Bug 1666964 - Retrieve Printer Default Media Through IPP Attribute r=jwatt,hiro

approved for 82.0b4

Attachment #9177790 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: