1664009 - New print UI arbitrarily defaults to different paper sizes (for the same printer), seemingly at random

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

STR:

1. Start Firefox Nightly with a fresh profile, which I do like so (on Linux):

mkdir /tmp/foo123; firefox -no-remote -profile /tmp/foo123 https://www.example.org/

2. Ctrl+P to print the page shown (example.org)
3. Once you've got a preview up, hit "Esc" and then Ctrl+P again to bring up the preview again.
4. Repeat step 3 several times to see the preview several times.

EXPECTED RESULTS:
Consistent results, with a consistent choice of paper size.

ACTUAL RESULTS:
The preview uses one of two paper sizes, seemingly at random:

• 3x5 "photo" size
• 8.5x11 "US Letter size

Comment 1

[Daniel Holbert [:dholbert]]

(This feels like a P1. We don't want to arbitrarily be choosing a weird paper size as the occasional default, from one print operation to another.)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast

Comment 3

[Daniel Holbert [:dholbert]]

See attached screencast:

• 0:02: First print operation, we choose US-Letter
• 0:09: Second print operation, we choose a 3x5 photo size.
• 0:13: I click into the page size dropdown to show the available options (not very many!)
• 0:23: Third print operation: we choose 3x5 photo size again
• 0:26: I click into the page size dropdown to show the available options (more now! Still not the full list though; e.g. no US-letter option)

I'm using Nightly 82.0a1 (2020-09-09) (64-bit) on Ubuntu 20.04 (Linux).

It looks like part of the problem is that we're reporting a different set of available page sizes on different print operations, as shown at 0:13 and 0:26. And I guess we're picking among the options that we get back, and if we don't see US-Letter, we fail over to this 3x5 size for some reason?

Anyway - the inconsistent sizes seems to be the real problem.

Comment 4

[Daniel Holbert [:dholbert]]

Emily, do you know if this is a known issue, or what might be going on here?

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: larger/complete (?) paper list that's shown when 8.5x11 gets selected as the default

BTW my screencast didn't show the paper list from when 8.5x11 is chosen as the default. Here's a screenshot showing that list -- note that it's a much larger list than the lists that came up in the screencast (when Nightly picked the 3x5 size for me). It's large enough that it overflows the dropdown area and needs a scrollbar.

Comment 6

[Daniel Holbert [:dholbert]]

(I filed bug 1664017 on the fact that we're showing symbolic-looking paper names here, too.)

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #3)

It looks like part of the problem is that we're reporting a different set of available page sizes on different print operations [...] I guess we're picking among the options that we get back, and if we don't see US-Letter, we fail over to this 3x5 size for some reason?

Turns out this varying-paper-options thing isn't the explanation (though it is obviously a bug in and of itself). I've hit this small-page-size issue a few times, in a case where the Page Sizes dropdown does include the US-letter size (and what looks like all the other sizes as well - a list as long as the one shown in comment 5).

So, I have another observation/theory: it looks like the smaller arbitrarily-chosen paper-size here is called oe_photo-l_3.5x5in and is consistently the last paper size in the list of options (because they're sorted alphabetically)[1]. So: maybe our pick-the-best-paper-size algorithm is just failing sometimes and just chooses the last option?

[1] It's last in the list, aside from its _borderless variant which is listed after it, which I'm assuming we exclude for other reasons.

Comment 8

[Jonathan Watt [:jwatt]]

FWIW the default size should be coming from a call to nsIPrinter.createDefaultSettings(), which calls through to nsPrintSettings::InitWithInitializer. The initializer object passed to that comes from nsPrinterCUPS::DefaultSettings. That gets the default media (paper) via the call to cupsGetDestMediaDefault().

Comment 9

[Jonathan Watt [:jwatt]]

[Hit Submit too soon.] I'm guessing in your case that cupsGetDestMediaDefault() isn't finding a default for your printer, and we return the default initialized struct.

Probably we should have a list of preferred paper sizes to go through in this case, preferring Letter for en_US/en_CA if available, or else A4 if available, etc.

Comment 10

[Jonathan Watt [:jwatt]]

NI'ing Jonathan in case he wants to express an opinion on what that list should look like.

Comment 11

[Jonathan Kew [:jfkthame]]

Is this connected at all to the code at https://searchfox.org/mozilla-central/rev/8a0745cd346f0cfb89ae71690babbf7bff706113/toolkit/components/printing/content/print.js#298-300 that tries to "take the first paper size" from a list that doesn't (AFAIK) have any particular order? I was meaning to look into the circumstances where we'd hit that, and whether we should be doing something more intelligent there.

IMO if we need to choose a default, we should probably search (by size, because names may vary) for the nearest available size to US Letter if the system locale is en-US or en-CA (maybe also Mexico -- is US Letter commonly used there?), and the nearest available size to A4 otherwise. A definition of "nearest" that just considers the sum of width-discrepancy plus height-discrepancy would probably work OK. (Alternatively, consider the difference in area. But I doubt it really matters which.)

Comment 12

[Daniel Holbert [:dholbert]]

I caught this in rr and watched what was going on in nsPrinterCUPS::DefaultSettings when we got US Letter vs. the small photo-size.

For the "good" US-Letter-default-size print-operations, cupsGetDestMediaDefault returned true.
For the "bad" small-photo-default-size print operation, cupsGetDestMediaDefault returned false.

So the issue is that (1) that API is failing for some reason (maybe this is unavoidable some of the time?), and (2) our fallback codepath is producing a silly result when that happens.

(This is all for the same printer, which in my case is a network Brother MFC-J6535DW named SoquelPrinter)

Comment 13

[Daniel Holbert [:dholbert]]

(In reply to Jonathan Kew (:jfkthame) from comment #11)

Is this connected at all to the code at print.js#298-300 that tries to "take the first paper size" from a list that doesn't (AFAIK) have any particular order?

You're absolutely right - this specifically happens when that code kicked in (which is, in turn, triggered by cupsGetDestMediaDefault having returned false per comment 8-9). I added some dump() logging to that case in print.js, and the logging only appeared in "bad" print operations (where we showed a small default paper size). And the Object.keys(PrintSettingsViewProxy.availablePaperSizes)[0]; lookup did indeed end up producing "oe_photo-l_3.5x5in" (the bizarre-seeming paper size that we end up using).

Comment 14

[Sam Foster [:sfoster] (he/him)]

Maybe one of these 2 issues should be a separate bug. We already sort the paper list by name, and yes the fallback is to simply pick the first entry in the list. So, there's a front-end patch to print.js we could write to fallback to the nearest size to A4 or letter as appropriate based on locale/region. We are already doing something similar to preserve the user's paper selection across printer changes, where the same/equivalent paper size might have a different name. There are edge cases where that might be the wrong outcome but it seems reasonable as a default.

There's another issue which is the inconsistent results from cupsGetDestMediaDefault (is this only with CUPS or are we seeing a similar issue on windows?). This seems to me to be a higher priority - unless it proves intractable or disproportionately difficult in which case the front-end fix should work for most people, most of the time.

Comment 15

[Jonathan Watt [:jwatt]]

(In reply to Daniel Holbert [:dholbert] from comment #12)

So the issue is that (1) that API is failing for some reason (maybe this is unavoidable some of the time?), and (2) our fallback codepath is producing a silly result when that happens.

Could this be a timeout issue (I know you've been getting very slow calls for some things)? I'm not sure why we pass CUPS_HTTP_DEFAULT to cupsGetDestMediaDefault given that we create an http_t below the call. Should we be creating that http_t earlier and passing that instead? Does using CUPS_HTTP_DEFAULT default to a shorter timeout? Can you shed light on this, Emily?

Comment 16

[Jonathan Watt [:jwatt]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #14)

So, there's a front-end patch to print.js we could write to fallback to the nearest size to A4 or letter as appropriate based on locale/region.

I feel like the platform code should be doing this anyway rather than returning junk.

Comment 17

[Hiroyuki Ikezoe (:hiro)]

Note that on my Ubuntu 20.04, cupsGetDestMediaDefault doesn't return the paper size set as default on http://localhost:631/printers. cupsFindDestDefault with "media" option does return the paper size.

Comment 18

[Hiroyuki Ikezoe (:hiro)]

An interesting observation on MacOS 10.14.6, cupsFindDestDefault returns a wrong paper size, whereas cupsGetDestMediaDefault returns the correct paper size in the System Preferences. I think that's why Erik used cupsGetDestMediaDefault. That said, cupsGetDestMediaDefault is not perfect, in the list in the System Preferences I can see A3 there and if I choose A3, then cupsGetDestMediaDefault returns na_letter_8.5x11in. There are several paper sizes in the System Preferences I don't see them in Firefox.

Comment 19

[Jonathan Kew [:jfkthame]]

The "Default paper size" in System Preferences doesn't seem to be related to what is actually available/supported by the chosen printer; AFAICT it's just a fixed list of common sizes. So if you choose A3 as the default in System Preferences, but then the selected destination in the Print UI is not a large-format printer, I would expect cupsGetDestMediaDefault for that destination to return something that's actually supported.

Comment 20

[Hiroyuki Ikezoe (:hiro)]

(In reply to Jonathan Kew (:jfkthame) from comment #19)

I would expect cupsGetDestMediaDefault for that destination to return something that's actually supported.

I also doubt it, see bug 1663503 comment 23.

Comment 21

[Emily McDonough [:alaskanemily]]

Looking at the code, cupsFindDestDefault just searches the IPP results. This won't be useful if the printer isn't reachable.

For cupsGetDestMediaDefault on OS X, it seems that CUPS does honor the system preferences paper size if the printer has the appropriate properties. For all CUPS platforms, if this paper size is not found in the printer's media list then CUPS will just use the first paper size in the list. We forward this value without catching this situation.

Comment 22

[Daniel Holbert [:dholbert]]

So, I have some good news, which I wish I'd noticed sooner: this doesn't seem to be reproducible anymore.

In fact, the last Nightly that reproduces it is the Nightly from the day I filed this (2020-09-09) (and I did confirm that I can still repro it with that old build). The next day's Nightly was fine, it turns out. I ran mozregression --find-fix, which gave me this as the narrowest-available fix range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=c8b4b1b607330678ad34854f46a8ff80b1f2caf6&tochange=cfcf3340e9940ae90e355e2b33274dd3a4d6eeef

That suggests that this was fixed by Bug 1661157. Would that make sense, Emily?

(Note -- for the purposes of my testing in this comment, "good" builds are just the ones that consistently show me the print preview using a US-Letter layout. Perhaps [?] there are still graceful-fallbacks that we need to add for cupsGetDestMediaDefault and/or the print.js code that was referenced in comment 13. But at least as far as the symptoms that I was seeing, this seems to be fixed, independently of those potential fixes.)

Comment 23

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #22)

That suggests that this was fixed by Bug 1661157. Would that make sense, Emily?

In particular: since this bug traced back to a cups API failure inside of nsPrinterCUPS::DefaultSettings() (per comment 12): perhaps the new mPrinterInfoMutex locking-stuff in that function is what helped here? (link to that piece of the patch: https://hg.mozilla.org/integration/autoland/rev/0060f1eee073#l1.26 )

Comment 24

[Emily McDonough [:alaskanemily]]

(In reply to Daniel Holbert [:dholbert] from comment #22)

That suggests that this was fixed by Bug 1661157. Would that make sense, Emily?

That would make sense, and explain why it was so inconsistent to reproduce.

Based on some testing that Erik and I did on OS X, there may be a very unlikely but related issue that could occur (which the patch I made for this bug would fix). I can make that into a different bug though, since it seems that's not what was causing the inconsistency.

Comment 25

[Daniel Holbert [:dholbert]]

Great. Let's call this one FIXED-by-bug 1661157 then.