Menu > Print does not work properly on Nightly82.0a1 Ubuntu20.04 ("Preparing Preview" spins forever after "Error: Can't fetchPaperMargins")
Categories
(Toolkit :: Printing, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox-esr78 | --- | unaffected |
firefox80 | --- | unaffected |
firefox81 | + | disabled |
firefox82 | + | fixed |
firefox83 | + | fixed |
People
(Reporter: alice0775, Assigned: sfoster)
References
(Regression, )
Details
(Keywords: nightly-community, regression, Whiteboard: [print2020_v82][old-ui-])
Attachments
(6 files)
STR:
- Open any page e.g. https://www.wikipedia.org/
- 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
![]() |
Reporter | |
Comment 1•6 months ago
|
||
![]() |
Reporter | |
Comment 2•6 months ago
|
||
[Tracking Requested - why for this release]: Print preview does not work.
Updated•6 months ago
|
Updated•6 months ago
|
![]() |
Reporter | |
Comment 3•6 months ago
|
||
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=886855bf6308c64ad2c459a73ba63317a8960070&tochange=603459fd7f347a9f5b2fb9dc52ab058188dd48d8
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Comment 6•6 months ago
|
||
Looks like bug 1659757 is the regressor, isn't it?
Comment 8•6 months ago
|
||
Oops, yes indeed. This couldn't possibly be bug 1653319. Thanks for catching that, Hiro.
Updated•6 months ago
|
Updated•6 months ago
|
Assignee | ||
Comment 11•6 months ago
|
||
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.
Updated•6 months ago
|
Comment 12•6 months ago
|
||
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.
![]() |
Reporter | |
Comment 13•6 months ago
|
||
(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•6 months ago
|
||
Hey Alice, would you mind trying the build in bug 1661157 comment 29? (I am totally unsure it will affect this or not)
![]() |
Reporter | |
Comment 15•6 months ago
|
||
(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.
Updated•6 months ago
|
Updated•6 months ago
|
Assignee | ||
Comment 16•6 months ago
|
||
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.
![]() |
Reporter | |
Comment 17•6 months ago
|
||
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.
Assignee | ||
Comment 18•6 months ago
|
||
(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.
Assignee | ||
Comment 19•6 months ago
|
||
Comment 20•6 months ago
|
||
(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•6 months ago
|
||
(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•6 months ago
|
||
It looks to me that CUPS tries to find a possible paper size in cupsGetDestMediaDefault unless CUPS_MEDIA_FLAGS_EXACT is specified?
Comment 23•6 months ago
|
||
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•6 months ago
|
||
Do'h, looks like it was introduced by Erik. :)
Comment 25•6 months ago
|
||
Pushed by sfoster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/40297c1bb09c Add debug logging to help troubleshoot printer paper sizes. r=jaws
Comment 26•6 months ago
|
||
Backed out for perma failures.
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
Assignee | ||
Comment 27•6 months ago
|
||
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•6 months ago
|
||
Pushed by sfoster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d7d26615220c Add debug logging to help troubleshoot printer paper sizes. r=jaws
Comment 29•6 months ago
|
||
bugherder |
Assignee | ||
Comment 30•5 months ago
|
||
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"
Assignee | ||
Comment 31•5 months ago
|
||
: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.
![]() |
Reporter | |
Comment 32•5 months ago
|
||
(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 totrue
. 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
Assignee | ||
Comment 33•5 months ago
|
||
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)
![]() |
Reporter | |
Comment 34•5 months ago
|
||
"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:"
{}
Assignee | ||
Comment 35•5 months ago
|
||
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.
Assignee | ||
Comment 36•5 months ago
|
||
: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•5 months ago
|
||
(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.
Assignee | ||
Comment 38•5 months ago
|
||
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.
Assignee | ||
Comment 39•5 months ago
|
||
Updated•5 months ago
|
Comment 40•5 months ago
|
||
Pushed by sfoster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fbaf0074074f Use the fallbackPaperList when a printer has 0 paper sizes. r=mstriemer
Comment 41•5 months ago
|
||
bugherder |
![]() |
Reporter | |
Comment 42•5 months ago
|
||
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
Updated•5 months ago
|
Comment 43•5 months ago
|
||
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•5 months ago
|
||
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•5 months ago
|
||
Comment 46•5 months ago
|
||
Pushed by emalysz@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5f50537b7090 only update custom margins settings if it has been initialized r=sfoster
Assignee | ||
Comment 47•5 months ago
|
||
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•5 months ago
|
||
bugherder |
![]() |
Reporter | |
Comment 49•5 months ago
|
||
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•5 months ago
|
||
(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•5 months ago
|
||
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•5 months ago
|
||
Ah, never mind. From your latest comment on bug 1669207 I guess that should act as our bug.
Comment 53•5 months ago
|
||
This bug has the leave-open keyword since comment 18 a few weeks ago. Is more work expected here?
Assignee | ||
Comment 54•5 months ago
|
||
This can be closed now that attachment 9179046 [details] has landed (comment #42)
We're tracking the bogus margin values issue in bug 1669207
Updated•5 months ago
|
Comment 55•5 months ago
|
||
The patch in bug 1669207 should fix the issues we were seeing in comment #42 and comment #49
Assignee | ||
Comment 56•5 months ago
|
||
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
Assignee | ||
Updated•5 months ago
|
Assignee | ||
Comment 57•5 months ago
|
||
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
Assignee | ||
Comment 59•5 months ago
|
||
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•5 months ago
|
||
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•5 months ago
|
||
bugherderuplift |
Description
•