1663503 - Menu > Print does not work properly on Nightly82.0a1 Ubuntu20.04 ("Preparing Preview" spins forever after "Error: Can't fetchPaperMargins")

Status: RESOLVED FIXED

(Toolkit :: Printing, defect, P1)

Description

[Alice0775 White]

Attachment: screenshot

STR:

1. Open any page e.g. https://www.wikipedia.org/
2. Menu > Print

Actual Results:
Menu > Print does not work. Loading spinner spin forever. See attached screenshot.

Browser console shows following error:

printing.preview_opened_tm - Cannot record the scalar in the current process.
Uncaught (in promise) Error: Can't fetchPaperMargins: undefined
    fetchPaperMargins chrome://global/content/print.js:685
    refreshSettings chrome://global/content/print.js:311
    init chrome://global/content/print.js:190
    async* chrome://global/content/print.js:45
    EventListener.handleEvent* chrome://global/content/print.js:42
print.js:685:13

Comment 1

[Alice0775 White]

Attachment: about:support

Comment 2

[Alice0775 White]

[Tracking Requested - why for this release]: Print preview does not work.

Comment 3

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=886855bf6308c64ad2c459a73ba63317a8960070&tochange=603459fd7f347a9f5b2fb9dc52ab058188dd48d8

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 5

[Jonathan Watt [:jwatt]]

Thanks, Alice!

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Looks like bug 1659757 is the regressor, isn't it?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

:sfoster, please see the error message in comment 0.

Comment 8

[Jonathan Watt [:jwatt]]

Oops, yes indeed. This couldn't possibly be bug 1653319. Thanks for catching that, Hiro.

Comment 10

[Mark Striemer [:mstriemer]]

Sam, do you mind looking into this?

Comment 11

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

I'll take a look, I suspect there's some exception not being caught, or we should be throwing one where we are not already.

Comment 12

[Jonathan Watt [:jwatt]]

Alice, which printer is selected in the preview window when this happens, and which paper size is selected? Are you able to provide a list of the paper sizes for this this printer (a screenshot may be easier than listing them manually)? That may require disabling the pref (as described in comment 26) to get to the old UI, or else using a different app to print. Whatever works.

Comment 13

[Alice0775 White]

Attachment: screenshot with new profile & toggle the pref

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

Alice, which printer is selected in the preview window when this happens, and which paper size is selected?

I tested with new profile. So, I did not select any printer and any paper size.

Are you able to provide a list of the paper sizes for this this printer (a screenshot may be easier than listing them manually)?
That may require disabling the pref (as described in comment 26) to get to the old UI, or else using a different app to print. Whatever works.

Set print.tab_modal.enabled=false, and I took a screenshot. See attached screenshot.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Hey Alice, would you mind trying the build in bug 1661157 comment 29? (I am totally unsure it will affect this or not)

Comment 15

[Alice0775 White]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #14)

Hey Alice, would you mind trying the build in bug 1661157 comment 29? (I am totally unsure it will affect this or not)

I can still reproduce the issue on the try-build.

Comment 16

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

The exception "Uncaught (in promise) Error: Can't fetchPaperMargins: undefined" means there was no 'paperName' setting for the current printer, and our fallback of using the first in the list of available paper sizes failed - presumably because the list was empty.

As the default printer is the one that produces the problem, the whole print UI fails to complete initializing meaning the use can't select another printer as a workaround.

Throwing that exception was there to catch exactly this scenario - it shouldn't be possible to have an empty paper list, but here we are. We don't don't have an easy way to check the available paper sizes from the browser console, so to confirm this hypothesis we'll either need a way to reproduce locally, or add some debugging/troubleshooting logging (and/or expose the PrintSettingsViewProxy on the global so we can at least reach it from the console.)

I'll prepare a patch we can land to get some more detail and help troubleshoot the issue.
If the printer is giving us bad data and there's no bug at the platform level, we may also need to be able to disable or remove a printer from the print destinations list.

Comment 17

[Alice0775 White]

I should mention I use VMware player and Virtual Printer.

Host OS: Windows10
Guest OS: Ubuntu20.04

I removed all virtual printers, then the print preview displays properly though destination drop down is "Save to PDF" only.

So it seems the new print preview would not handle Virtual printer properly.

Comment 18

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

(In reply to Alice0775 White from comment #17)

I should mention I use VMware player and Virtual Printer.
I removed all virtual printers, then the print preview displays properly though destination drop down is "Save to PDF" only.

Yeah thanks, that does help. I'm still be curious to know what state the different collections we use for the print UI are in. And we have run into a similar problem on other bugs. Patch incoming.

Comment 19

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

Attachment: Bug 1663503 - Add debug logging to help troubleshoot printer paper sizes. r?mstriemer

Comment 20

[Lee McFarland]

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

The exception "Uncaught (in promise) Error: Can't fetchPaperMargins: undefined" means there was no 'paperName' setting for the current printer, and our fallback of using the first in the list of available paper sizes failed - presumably because the list was empty.

As the default printer is the one that produces the problem, the whole print UI fails to complete initializing meaning the use can't select another printer as a workaround.

Throwing that exception was there to catch exactly this scenario - it shouldn't be possible to have an empty paper list, but here we are. We don't don't have an easy way to check the available paper sizes from the browser console, so to confirm this hypothesis we'll either need a way to reproduce locally, or add some debugging/troubleshooting logging (and/or expose the PrintSettingsViewProxy on the global so we can at least reach it from the console.)

I'll prepare a patch we can land to get some more detail and help troubleshoot the issue.
If the printer is giving us bad data and there's no bug at the platform level, we may also need to be able to disable or remove a printer from the print destinations list.

I might be misreading this comment - Is it being suggested a printer might be disabled or removed from access via firefox? Please consider that some printers, even a default printer may not always be accessible. My main printer, locally known as BigSquid, is available throughout the house. It is on a different system and LAN connected. Even a labtop makes used of it (as a default printer). Then being a laptop, that Ubuntu 16.04 system sometimes travels many miles away from the house LAN. While away, it might connect to some other WIFI for internet access - primarily using firefox. At that time, the default printer won't be available - I would probably use the 'print to file' printer. Since my default printer is BigSquid, while away, I of course select an alternate printer (print to file), from the print dialog that comes up (File->Print). I sure wouldn't want firefox to disable my ability to use my primary printer when I returned home - because it marked it 'disabled'.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

(In reply to Lee McFarland from comment #20)

I might be misreading this comment - Is it being suggested a printer might be disabled or removed from access via firefox? Please consider that some printers, even a default printer may not always be accessible. My main printer, locally known as BigSquid, is available throughout the house. It is on a different system and LAN connected. Even a labtop makes used of it (as a default printer). Then being a laptop, that Ubuntu 16.04 system sometimes travels many miles away from the house LAN. While away, it might connect to some other WIFI for internet access - primarily using firefox. At that time, the default printer won't be available - I would probably use the 'print to file' printer. Since my default printer is BigSquid, while away, I of course select an alternate printer (print to file), from the print dialog that comes up (File->Print). I sure wouldn't want firefox to disable my ability to use my primary printer when I returned home - because it marked it 'disabled'.

In such cases,

• the printer in your house will not appear in the list when you are not on the LAN in your house
• the printer will re-appear when you are on the LAN (i.e. you came back to home)

I believe this is what Sam is saying in comment 16.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

It looks to me that CUPS tries to find a possible paper size in cupsGetDestMediaDefault unless CUPS_MEDIA_FLAGS_EXACT is specified?

Comment 23

[Hiroyuki Ikezoe (:hiro)]

CUPS APIs are quite confusing.

From https://www.cups.org/doc/cupspm.html#media-size-options

CUPS_MEDIA_FLAGS_DEFAULT: Find the closest size supported by the printer.

So in my understanding, if cupsGetDestMediaDefault gets called with CUPS_MEDIA_FLAGS_DEFAULT, the function might return a slightly different size what the printer actually supports. On the other hand, cupsGetDestMediaByIndex returns all supported paper sizes even with CUPS_MEDIA_FLAGS_DEFAULT (I am reading the CUPS code at master, so it might be different on older revisions).

Anyways, to me using CUPS_MEDIA_FLAGS_DEFAULT looks quite flaky.
CCing Emily.

Comment 24

[Hiroyuki Ikezoe (:hiro)]

Do'h, looks like it was introduced by Erik. :)

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/40297c1bb09c
Add debug logging to help troubleshoot printer paper sizes. r=jaws

Comment 26

[Razvan Maries]

Backed out for perma failures.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&revision=2e9bfe12da5a4c2c1e9087392390fcdf700fc003&searchStr=bc&failure_classification_id=2

Logs:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315700274&repo=autoland&lineNumber=24430
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315700241&repo=autoland&lineNumber=27074

Backout: https://hg.mozilla.org/integration/autoland/rev/24b917577203190f0e1c0b21f6ffaf4d07f1e8f6

Comment 27

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

Thanks. I've not been able to repro locally, but assuming its the pref observer that is causing the leak, I think I have this fixed in https://treeherder.mozilla.org/#/jobs?repo=try&revision=3008f76bdda9e1769e24e7b7bd87d8fb225bc2ec

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d7d26615220c
Add debug logging to help troubleshoot printer paper sizes. r=jaws

Comment 29

[Alexandru Michis [:malexandru]]

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

Comment 30

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

We now have some debug logging you can enable in the latest nightlies by creating a print.debug pref in about:config, and setting it to true. You can filter the browser console output by "printUI:" to exclude all but those messages. :Alice0755, could you attach the output here? I'm particularly interested in the "settings" message when you reproduce this issue. That outputs an object, so you'll need to expand that before using "Export visible messages"

Comment 31

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

:eric, what else do you need to know from the reporter to track this down? See comment 17 where they say this is a virtual printer in a VMWare vm.

Comment 32

[Alice0775 White]

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

We now have some debug logging you can enable in the latest nightlies by creating a print.debug pref in about:config, and setting it to true. You can filter the browser console output by "printUI:" to exclude all but those messages. :Alice0755, could you attach the output here? I'm particularly interested in the "settings" message when you reproduce this issue. That outputs an object, so you'll need to expand that before using "Export visible messages"

printUI: availablePrinters:  
Array(6) [ "Mozilla Save to PDF", "CubePDF:5", "Fax:4", "JustSystems_PDF_():3", "Microsoft_Print_to_PDF:2", "Microsoft_XPS_Document_Writer:1" ]
print.js:189
printUI: defaultSystemPrinter:  
Object { name: "Microsoft_Print_to_PDF:2", value: "Microsoft_Print_to_PDF:2" }
print.js:190
printUI: currentPrinter name:  Microsoft_Print_to_PDF:2 print.js:335
printUI: settings: 
Object { isInitializedFromPrinter: true, paperSizeUnit: 0, startPageRange: 1, endPageRange: 1, edgeTop: 0, edgeLeft: 0, edgeBottom: 0, edgeRight: 0, marginTop: 0.5, marginLeft: 0.5, … }
print.js:336
printUI: settings.paperName:  <empty string> print.js:363
printUI: Available paper sizes:  
Object {  }
print.js:364

Comment 33

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

A couple of the console messages have arrays/objects which are truncated or collapsed in this output. Could you click the expand the ▶next to the "printUI: settings" and "printUI: Available paper sizes:" - thats where the meat of the information is. You can "copy object" and paste those directly in here.

(Maybe the debug logging should log a JSON string rather than the objects to avoid this in future)

Comment 34

[Alice0775 White]

"copy object" results of "printUI: settings"

{
  "isInitializedFromPrinter": true,
  "paperSizeUnit": 0,
  "startPageRange": 1,
  "endPageRange": 1,
  "edgeTop": 0,
  "edgeLeft": 0,
  "edgeBottom": 0,
  "edgeRight": 0,
  "marginTop": 0.5,
  "marginLeft": 0.5,
  "marginBottom": 0.5,
  "marginRight": 0.5,
  "unwriteableMarginTop": 0,
  "unwriteableMarginLeft": 0,
  "unwriteableMarginBottom": 0,
  "unwriteableMarginRight": 0,
  "scaling": 1,
  "printBGColors": false,
  "printBGImages": false,
  "printRange": 0,
  "title": "",
  "docURL": "",
  "headerStrLeft": "&T",
  "headerStrCenter": "",
  "headerStrRight": "&U",
  "footerStrLeft": "&PT",
  "footerStrCenter": "",
  "footerStrRight": "&D",
  "isCancelled": false,
  "saveOnCancel": true,
  "printSilent": false,
  "shrinkToFit": true,
  "showPrintProgress": true,
  "showMarginGuides": false,
  "paperName": "",
  "paperData": 0,
  "paperWidth": 0,
  "paperHeight": 0,
  "printReversed": false,
  "printInColor": true,
  "orientation": 0,
  "numCopies": 1,
  "printerName": "Microsoft_Print_to_PDF:2",
  "printToFile": false,
  "toFileName": "/home/fuku/Desktop/nightly/mozilla.pdf",
  "outputFormat": 0,
  "printPageDelay": 50,
  "duplex": 0,
  "isInitializedFromPrefs": true
}

"copy object" results of "printUI: Available paper sizes:"

{}

Comment 35

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

Here's the plan for this:

• Update the front-end code to handle the case that a printer has an empty paperList.
• Treat 0 paper sizes as a validation error in the form; disable the rest of the form and show a message like "We are having trouble getting a list of supported paper sizes from this printer. Please select another printer"

Bug 1662946 will track our investigation into why some printers report an empty paperList.

Comment 36

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

:shorlander, do you have any suggestions for the string we show if a printer reports 0 supported paper sizes (or is available, but unusable for some technical reason that the user is not likely to be able to resolve here and now)

Comment 37

[Lee McFarland]

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

Here's the plan for this:

• Update the front-end code to handle the case that a printer has an empty paperList.
• Treat 0 paper sizes as a validation error in the form; disable the rest of the form and show a message like "We are having trouble getting a list of supported paper sizes from this printer. Please select another printer"

Bug 1662946 will track our investigation into why some printers report an empty paperList.

If you are going to with a plan that removes printers from the selection list because they are showing an empty paperList or 0 paper sizes - is it possible all physical printers might get removed. The list probably won't go to zero in a Ubuntu (linux) environment because the 'print to file' printer may survive as the only possible choice.

Consider always allowing someone to make their selection from the system list of printers. In this way, those who get all their physical printers struck-off will continue having a way of printing directly from firefox.

Comment 38

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

New plan: We'll use the fallbackPaperList if the .paperList resolves to empty, as it seems most/all of the ocurances we've seen of this are recoverable and its just the paper sizes lookup which has failed.
There will be paper sizes in the fallbackPaperList which might not be supported by the users' printer - that's an acceptable risk in what is already an edge case, and something the user will need to manage.

So, no new strings needed. We can revive the "invalid printer" idea later if that becomes necessary.

Comment 39

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

Attachment: Bug 1663503 - Use the fallbackPaperList when a printer has 0 paper sizes. r?mstriemer

Comment 40

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fbaf0074074f
Use the fallbackPaperList when a printer has 0 paper sizes. r=mstriemer

Comment 41

[Cosmin Sabou [:CosminS]]

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

Comment 42

[Alice0775 White]

The problem is still reproduced on Nightly83.0a1(20201001094020) mozilla-central/rev/ba35799faec2ed9da469c2a7ade75398d9daf688.

Browser console shows the following error when press Ctrl+P :

printUI: Printer has empty paperList:  undefined print.js:971
Uncaught (in promise) TypeError: can't access property "marginTop", settingsToUpdate.customMargins is undefined
    getSettingsToUpdate chrome://global/content/print.js:454
    refreshSettings chrome://global/content/print.js:381
    init chrome://global/content/print.js:251
    async* chrome://global/content/print.js:85
    EventListener.handleEvent* chrome://global/content/print.js:82
print.js:454:7
    init chrome://global/content/print.js:289
    AsyncFunctionThrow self-hosted:693
    (Async: async)
    <anonymous> chrome://global/content/print.js:85
    (Async: EventListener.handleEvent)
    <anonymous> chrome://global/content/print.js:82

Comment 43

[Jonathan Watt [:jwatt]]

That build does include this bug's patch, but that error is different to the previous one. It looks like it's related to bug 1664570 which also just landed, so needinfo'ing Emma too in case she has any insight into this error.

Comment 44

[Emma Malysz]

It looks like we are hitting this before we initialize our custom margins value. The first time we getMarginPresets for the custom values, we will check if we have a value stored or else we default on the stored marginTop. I think it's safe if we add a null check, but I'll flag Sam for review on that.

Comment 45

[Emma Malysz]

Attachment: Bug 1663503, only update custom margins settings if it has been initialized

Comment 46

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f50537b7090
only update custom margins settings if it has been initialized r=sfoster

Comment 47

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

printUI: Printer has empty paperList:  undefined print.js:971
Uncaught (in promise) TypeError: can't access property "marginTop", settingsToUpdate.customMargins is undefined

The patch in attachment 9179046 [details] adds a null check for the custom margin values. Thanks for spotting that. The same patch clarifies the console warning about the 0 paper sizes thing. We still want a way to discover this case, but it gets handled by using the fallback paper list we use for the PDF print-to-file.

Comment 48

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/5f50537b7090

Comment 49

[Alice0775 White]

On Nightly83.0a1(20201003102335) mozilla-central/rev/7d7faf0b6d7a7ee76d6685a61f26b4c20a6e5d29,

Print preview display properly.
However, All controls UI(except "More settings", "Print using the system dialog..."link and [Cancel] button) are disabled. So I am able to select "Save to PDF".

Comment 50

[Julien Wajsberg [:julienw]]

(In reply to Alice0775 White from comment #49)

On Nightly83.0a1(20201003102335) mozilla-central/rev/7d7faf0b6d7a7ee76d6685a61f26b4c20a6e5d29,

Print preview display properly.
However, All controls UI(except "More settings", "Print using the system dialog..."link and [Cancel] button) are disabled. So I am able to select "Save to PDF".

Same problem here, and mozregression actually points to this bug with latest patch from Emma.
mozregression gave me this pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=1a6c4e6d3320f2e3a7dbd2a3c1a23b624f7d8ccb&tochange=5f50537b7090c188ef15ca31ade7c93b1ddf04d1

To be clear, for me this happens when a non-existing printer is selected (not sure how to describe it better). So that wouldn't be a big problem... except that once it's selected, the printer select dropdown is disabled too so we can't select another printer.

What I see here is that I get invalid (negative!) margin values, such as -1491308.13 in all 4 entries.

I also filed bug 1669207 related to the issue tht everything is disabled without a clear message.

Hey Emma, do you think you could have a second look? Thanks!

Comment 51

[Jonathan Watt [:jwatt]]

Julien, can you file a separate bug, please? This sounds like a potentially blocking issue, so we should be tracking this but can't do that against a closed bug.

Comment 52

[Jonathan Watt [:jwatt]]

Ah, never mind. From your latest comment on bug 1669207 I guess that should act as our bug.

Comment 53

[Julien Cristau [:jcristau]]

This bug has the leave-open keyword since comment 18 a few weeks ago. Is more work expected here?

Comment 54

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

This can be closed now that attachment 9179046 [details] has landed (comment #42)
We're tracking the bogus margin values issue in bug 1669207

Comment 55

[Emma Malysz]

The patch in bug 1669207 should fix the issues we were seeing in comment #42 and comment #49

Comment 56

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

Comment on attachment 9178008 [details]
Bug 1663503 - Use the fallbackPaperList when a printer has 0 paper sizes. r?mstriemer

Beta/Release Uplift Approval Request

• User impact if declined: Print UI is unusable if the selected printer (erroneously) reports no supported paper sizes.
• Is this code covered by automated tests?: Yes
• 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: Low
• Why is the change risky/not risky? (and alternatives if risky): We were already catching and reporting this error. This patch just uses the existing "Mozilla PDF Printer" code path to handle this case.
• String changes made/needed: None

Comment 57

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

Comment on attachment 9175073 [details]
Bug 1663503 - Add debug logging to help troubleshoot printer paper sizes. r?mstriemer

This patch is already present in 82

Comment 59

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

Comment on attachment 9179046 [details]
Bug 1663503, only update custom margins settings if it has been initialized

This patch won't apply and isn't applicable without the patch from bug 1664570.

Comment 60

[Julien Cristau [:jcristau]]

Comment on attachment 9178008 [details]
Bug 1663503 - Use the fallbackPaperList when a printer has 0 paper sizes. r?mstriemer

approved for 82.0b9

Comment 61

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/eb5df5498b17