1662946 - Empty paper lists cause hangs firefox on Ubuntu 18.04/16.04 (Error: Can't fetchPaperMargins)

Status: VERIFIED FIXED

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

Description

[Lee McFarland]

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

Steps to reproduce:

Selected File then Print

Actual results:

The print preview is being prepared - it never happens.

Selecting File->print results in a hang condition. This totally stops the ability to print a webpage. I would consider it a high impact issue. It just started with build 20200902215721.
It is happening with Ubuntu 16.04. Print works correctly with Ubuntu 18.04 which suggests it is associated with the older CUPS and color print issue.

Expected results:

I should have been able to make selections in the print dialog which would result in a webpage print

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Maarten Brouwers]

While #1661361 somewhat solved the feedback issue at my side; it is now just showing the print dialog. While Firefox (MacOS (Catalina)) does not hang (I can visit other websites), the print dialog takes forever to populate ("Preparing Preview")? It is suggested in #1661361 that Firefox is at that time still collecting printer information; maybe that can be done in the background as soon as Firefox starts?

Comment 3

[Maarten Brouwers]

Attachment: screenshot with printerlist

list of printers that appears after the dialog finally stops loading (might be > 5 minutes), also includes remote printers

Comment 4

[Lee McFarland]

This morning using Firefox Nightly build 20200903094553 this bug is also totally hanging the print function in Ubuntu 18.04 as well as Ubuntu 16.04. When the bug was reported using build 20200902215721, print worked under Ubuntu 18.04.

Comment 5

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1662946 - Bail out from HTMLCanvasElement::CallPrintCallback is `mPrintState` has already destroyed. r?jwatt

Comment 6

[Phabricator Automation]

Comment on attachment 9173894 [details]
Bug 1662946 - Bail out from HTMLCanvasElement::CallPrintCallback is mPrintState has already destroyed. r?jwatt

Revision D89264 was moved to bug 1663053. Setting attachment 9173894 [details] to obsolete.

Comment 7

[Hiroyuki Ikezoe (:hiro)]

(In reply to Lee McFarland from comment #4)

This morning using Firefox Nightly build 20200903094553 this bug is also totally hanging the print function in Ubuntu 18.04 as well as Ubuntu 16.04. When the bug was reported using build 20200902215721, print worked under Ubuntu 18.04.

Then, something was regressed for Ubuntu 18.04.

Lee, can you please do mozregression to find out which commit caused the hang on Ubuntu 18.04? (And I think it's a different issue from what you've been seeing on Ubuntu 16.04).

Thanks!

Comment 8

[Lee McFarland]

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

(In reply to Lee McFarland from comment #4)

This morning using Firefox Nightly build 20200903094553 this bug is also totally hanging the print function in Ubuntu 18.04 as well as Ubuntu 16.04. When the bug was reported using build 20200902215721, print worked under Ubuntu 18.04.

Then, something was regressed for Ubuntu 18.04.

Lee, can you please do mozregression to find out which commit caused the hang on Ubuntu 18.04? (And I think it's a different issue from what you've been seeing on Ubuntu 16.04).

Thanks!

This will take some time. My Ubuntu 18.04 system has not previously had mozregression. As I attempt to install it I am presented with
mozregression requires Python '>=3.6' but the running Python is 2.7.17 If you can suggest how to get around this, I'll have another go at it tomorrow.

I can say build 20200902215721 was good on 18.04 and everything from build 20200902215721 on is bad.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

(In reply to Lee McFarland from comment #8)

This will take some time. My Ubuntu 18.04 system has not previously had mozregression. As I attempt to install it I am presented with
mozregression requires Python '>=3.6' but the running Python is 2.7.17 If you can suggest how to get around this, I'll have another go at it tomorrow.

Where was your mozregression got installed? In my case;

sudo apt install python3-pip
python3 -m pip install mozregression

Then mozregression was installed in ~/.local/bin/mozregression, then it can be launched properly.

python3 PATH_TO_MOZREGRESSION

might work.

Comment 10

[Lee McFarland]

(In reply to Lee McFarland from comment #8)

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

(In reply to Lee McFarland from comment #4)

This morning using Firefox Nightly build 20200903094553 this bug is also totally hanging the print function in Ubuntu 18.04 as well as Ubuntu 16.04. When the bug was reported using build 20200902215721, print worked under Ubuntu 18.04.

Then, something was regressed for Ubuntu 18.04.

Lee, can you please do mozregression to find out which commit caused the hang on Ubuntu 18.04? (And I think it's a different issue from what you've been seeing on Ubuntu 16.04).

Thanks!

This will take some time. My Ubuntu 18.04 system has not previously had mozregression. As I attempt to install it I am presented with
mozregression requires Python '>=3.6' but the running Python is 2.7.17 If you can suggest how to get around this, I'll have another go at it tomorrow.

I can say build 20200902215721 was good on 18.04 and everything from build 20200902215721 on is bad.

I got mozregression installed on my ubuntu 18.04, along with python3 etc. Now I'm getting some errors using it as follows:

python3 ./.local/bin/mozregression -g 2020-09-02 -b 2020-09-03
0:04.67 INFO: Got as far as we can go bisecting nightlies...
0:04.67 INFO: Last good revision: 85e7a3055098f2f8f8d7abc59d7f0d6215e47984 (2020-09-02)
0:04.67 INFO: First bad revision: aa032cbc94551a0f6e7e821d78aa0388f998e830 (2020-09-03)
0:04.67 INFO: Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85e7a3055098f2f8f8d7abc59d7f0d6215e47984&tochange=aa032cbc94551a0f6e7e821d78aa0388f998e830

0:04.67 INFO: Switching bisection method to taskcluster
0:04.67 INFO: Getting mozilla-central builds between 85e7a3055098f2f8f8d7abc59d7f0d6215e47984 and aa032cbc94551a0f6e7e821d78aa0388f998e830
Exception in thread Thread-8:
Traceback (most recent call last):
File "/home/neil/.local/lib/python3.6/site-packages/mozregression/fetch_build_info.py", line 134, in find_build_info
build_date = datetime.strptime(run["resolved"], "%Y-%m-%dT%H:%M:%S.%fZ")
File "/usr/lib/python3.6/_strptime.py", line 565, in _strptime_datetime
tt, fraction = _strptime(data_string, format)
File "/usr/lib/python3.6/_strptime.py", line 362, in _strptime
(data_string, format))
ValueError: time data '2020-09-03T05:45:20.440006+00:00' does not match format '%Y-%m-%dT%H:%M:%S.%fZ'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner

Comment 11

[Hiroyuki Ikezoe (:hiro)]

The error should have been already fixed (bug 1661607).

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Hey Lee, can you please test these two builds?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XgvBEC2_TZG1QHzDDSptUA/runs/0/artifacts/public/build/target.tar.bz2
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HLTS8JuyTFGiV0Ntk_7s9g/runs/0/artifacts/public/build/target.tar.bz2

The former is a build when bug 1662518 landed, the latter is the previous build before bug 1662518.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

I noticed there are a couple of issues with regard to CUPS (the IPP backend) on Ubuntu (I think it's on Linux). There are two printer entries on my Ubuntu 20.04, I believe those are the same single printer, but there are two different entries, one has ".local" suffix in the name and the other one doesn't have the suffix. And the ".local" one has the capability to change color mode, but the other one doesn't have (I've confirmed it on
http://localhost:631/printers/).

So problems are I've seen so far;

1. For the non ".local" printer, FetchCUPSVersionForPrinter fails here, thus the CUPS version of the printer will be 0
2. Thus, for the non ".local" printer SupportsColor always returns true (I think this is the cause of the issue on Lee's environment)
3. Chrome apparently use CUPS IPP backend only for Mac, so I guess there's reasons they don't use the IPP backends, they handles PPD files directly on Linux

Comment 14

[Lee McFarland]

Both builds have some degree of failure. This time, I set a consistent set of websites to make the test on. The older build is 20200902234942. The newer build is 20200902235330. I also ran the four using the current firefox nightly which is 20200904213127. Failure is taking more than 30 seconds to render the image on the left side of the print dialog invoked via File->Print. All tests failed on the current build

The Islandic government home page (www.government.is) worked on the older and newer build

The Wikipedia article on spring (Season) worked on the older and newer build

The US government's CDC (www.cdc.gov) failed on both older and newer builds

The resulting page from searching Amazon for Fry's chocolate cream 4 pack - failed on older and newer builds

I would conclude that in the past, there was some degree of success however, since current build (20200902235330), all attempts are failing. Previously, the degree of success depends upon the webpage contents. (In reply to Hiroyuki Ikezoe (:hiro) from comment #12)

Hey Lee, can you please test these two builds?

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/XgvBEC2_TZG1QHzDDSptUA/runs/0/artifacts/public/build/target.tar.bz2
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HLTS8JuyTFGiV0Ntk_7s9g/runs/0/artifacts/public/build/target.tar.bz2

The former is a build when bug 1662518 landed, the latter is the previous build before bug 1662518.

Both builds have some degree of failure. This time, I set a consistent set of websites to make the test on. The older build is 20200902234942. The newer build is 20200902235330. I also ran the four using the current firefox nightly which is 20200904213127. Failure is taking more than 30 seconds to render the image on the left side of the print dialog invoked via File->Print. All tests failed on the current build

The Islandic government home page (www.government.is) worked on the older and newer build

The Wikipedia article on spring (Season) worked on the older and newer build

The US government's CDC (www.cdc.gov) failed on both older and newer builds

The resulting page from searching Amazon for Fry's chocolate cream 4 pack - failed on older and newer builds

I would conclude that in the past, there was some degree of success however, since current build (20200902235330), all attempts are failing. Previously, the degree of success depends upon the webpage contents.

Comment 15

[Hiroyuki Ikezoe (:hiro)]

That's super confusing.. It seems to me that it just depends on the total page number of the side...

Comment 16

[Lee McFarland]

This hang condition has been present on all web pages if the system is Ubuntu 16.04 and thus without some sort of fix would be extremely harmful if it got into the regular release of firefox. Since those earlier builds I did the four webpage testing with, the hang condition is also always present in Ubuntu 18.04 and thus would prevent any installation using either Ubuntu 16.04 or Ubuntu 18.04 from moving forward to firefox 82 when it goes production.

Comment 17

[Jonathan Watt [:jwatt]]

Lee, it might provide some helpful info if you don't mind carrying out the following steps:

Open Tools -> Web Developer -> Browser Console
Click the trash can icon to clear any current messages
Switch back to the page you want to print and try to print it
Once the problem occurs, switch back to the Browser Console window
Right click on one of the messages in the Browser Console to open the context menu
From the context menu, select Export Visible Messages To -> File and save the file
Attach the file to this bug

You could then repeat the above steps, but instead of selecting Browser Console in the first step, select Web Console.

Comment 18

[Jonathan Watt [:jwatt]]

Another thing that would be helpful is to know if this issue reproduces on a clean profile. To do that you can start Firefox with the -P and -no-remote options, create a new profile, and test with that.

Finally it might be helpful if you could open the page about:support, click the Copy text to clipboard button, and then save that to file and attach it here. NOTE: please do check through the contents of this file first to make sure you're happy to attach it to this public bug. I don't think it should contain anything private, but all sorts of things are saved to preferences.

Comment 19

[Jonathan Watt [:jwatt]]

I suspect it's not broken, but could you also check whether printing in broken with the new UI pref disabled?

Comment 20

[Maarten Brouwers]

Just a heads up (hope I'm not hijacking this bug): I was experiencing the same error not on Ubuntu, but on MacOS. I didn't see any new messages bubble up in Browser Console, nor Web Console.

Toggling (also tried to toggle print.tab_modal.enabled, and got again the classic ui that was instantenous)

However, I have been able to get around the issue: I had a virtual printer driver installed that allowed me to print from a iOS device to my mac (Printopia 2). It is a 'bounjour' based service (Network printer). I had actually forgotten about it, switched it off and then just removed all printers. Enabling Printopia again introduced the delay again.

Comment 21

[Lee McFarland]

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

I suspect it's not broken, but could you also check whether printing in broken with the new UI pref disabled?

How do I disable the new UI pref?

Comment 22

[Lee McFarland]

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

Lee, it might provide some helpful info if you don't mind carrying out the following steps:

Open Tools -> Web Developer -> Browser Console
Click the trash can icon to clear any current messages
Switch back to the page you want to print and try to print it
Once the problem occurs, switch back to the Browser Console window
Right click on one of the messages in the Browser Console to open the context menu
From the context menu, select Export Visible Messages To -> File and save the file
Attach the file to this bug

You could then repeat the above steps, but instead of selecting Browser Console in the first step, select Web Console.
Uncaught (in promise) Error: Can't fetchPaperMargins: undefined
fetchPaperMargins chrome://global/content/print.js:686
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:686:13

---

as to the second item (browser console window)
There is nothing in that window

Comment 23

[Lee McFarland]

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

Another thing that would be helpful is to know if this issue reproduces on a clean profile. To do that you can start Firefox with the -P and -no-remote options, create a new profile, and test with that.

Finally it might be helpful if you could open the page about:support, click the Copy text to clipboard button, and then save that to file and attach it here. NOTE: please do check through the contents of this file first to make sure you're happy to attach it to this public bug. I don't think it should contain anything private, but all sorts of things are saved to preferences.

A new profile gives the same result. Using the new profile, I saved the test for about:support (as firefox.txt- thanks for the heads up on private information, since it was a fresh profile, I didn't see anything private.

Comment 24

[Lee McFarland]

Attachment: about:support for comment #18

Comment 25

[Hiroyuki Ikezoe (:hiro)]

Thank you Lee!

(In reply to Lee McFarland from comment #22)

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

Lee, it might provide some helpful info if you don't mind carrying out the following steps:

Open Tools -> Web Developer -> Browser Console
Click the trash can icon to clear any current messages
Switch back to the page you want to print and try to print it
Once the problem occurs, switch back to the Browser Console window
Right click on one of the messages in the Browser Console to open the context menu
From the context menu, select Export Visible Messages To -> File and save the file
Attach the file to this bug

You could then repeat the above steps, but instead of selecting Browser Console in the first step, select Web Console.
Uncaught (in promise) Error: Can't fetchPaperMargins: undefined
fetchPaperMargins chrome://global/content/print.js:686
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

That's bug 1663503.

Comment 26

[Jonathan Watt [:jwatt]]

Thanks for going to the trouble of providing the above information.

(In reply to Lee McFarland from comment #21)

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

I suspect it's not broken, but could you also check whether printing in broken with the new UI pref disabled?

How do I disable the new UI pref?

Hiro's right, it looks like you're experiencing bug 1663503. In that case no need to try with the pref off (although to answer your question, you'd load the page about:config and change the pref print.tab_modal.enabled to false and reload the page and try to print again).

Comment 27

[Jonathan Watt [:jwatt]]

(In reply to Maarten Brouwers from comment #20)

Just a heads up (hope I'm not hijacking this bug): I was experiencing the same error not on Ubuntu, but on MacOS. I didn't see any new messages bubble up in Browser Console, nor Web Console.

Toggling (also tried to toggle print.tab_modal.enabled, and got again the classic ui that was instantenous)

However, I have been able to get around the issue: I had a virtual printer driver installed that allowed me to print from a iOS device to my mac (Printopia 2). It is a 'bounjour' based service (Network printer). I had actually forgotten about it, switched it off and then just removed all printers. Enabling Printopia again introduced the delay again.

This is very good information, but yes, it would be a different issue and better investigated in a separate bug. Can you file one with all the information you have and CC me?

Comment 28

[Jonathan Watt [:jwatt]]

Lee, 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 29

[Jonathan Watt [:jwatt]]

I guess you may not even get enough of the UI to actually tell what printer is selected. In that case can you check the page about:config to see what the pref print_printer contains?

Comment 30

[Lee McFarland]

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

Thanks for going to the trouble of providing the above information.

(In reply to Lee McFarland from comment #21)

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

I suspect it's not broken, but could you also check whether printing in broken with the new UI pref disabled?

How do I disable the new UI pref?

Hiro's right, it looks like you're experiencing bug 1663503. In that case no need to try with the pref off (although to answer your question, you'd load the page about:config and change the pref print.tab_modal.enabled to false and reload the page and try to print again).

setting print.tab_modal.enabled to false does make the problem go away

Comment 31

[Lee McFarland]

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

I guess you may not even get enough of the UI to actually tell what printer is selected. In that case can you check the page about:config to see what the pref print_printer contains?

The printer is my default printer, local name is BigSquid. It is a networked printer. The printer is a Canon iX6820

Comment 32

[Lee McFarland]

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

Lee, 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.

In my installation, it's reasonable to assume all instances of firefox default to the same printer on the Ubuntu 16.04 system. I have two instances of firefox on the system. I run a standard 'production' level firefox which is installed in the system area and used by all. Personally I have an instance of firefox nightly. For my production firefox, I can say the default paper size is US Letter. The list of possible paper sizes is huge. For firefox, I don't think I've selected anything other that US letter in landscape or portrait. Using other applications, I've printed many sizes from quarter sheet (4.25x5.5) to tabloid (11x17). The printer is capable of larger sizes however, tabloid is the largest paper I have.

Comment 33

[Jonathan Watt [:jwatt]]

Thanks, Lee!

Comment 34

[Jonathan Watt [:jwatt]]

Lee, in bug 1664172 comment 13 you say the crash you were experiencing on Ubuntu 16.04 is gone. Is the hang this bug covers also gone, or do you still experience that? I suspect you still experience it given bug 1663503 hasn't been fixed yet, but just want to double check.

Comment 35

[Lee McFarland]

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

Lee, in bug 1664172 comment 13 you say the crash you were experiencing on Ubuntu 16.04 is gone. Is the hang this bug covers also gone, or do you still experience that? I suspect you still experience it given bug 1663503 hasn't been fixed yet, but just want to double check.

I still experience the hang. With the crash, I couldn't get to the point where the hang would happen.

Comment 36

[Erik Nordin [:nordzilla]]

It appears that the cause of this issue is that some printers are returning an empty paper list, which is why we get an error for fetching the margins (for a nonexistent paper).

Note that this bug and Bug 1663503 refer to the same issue.

sfoster is assigned to the latter, and is looking into fixing this issue on the front end such that we can gracefully handle a case where the paper list returns empty.

I am going to continue investigating with regard to this bug to try to figure out why we are getting an empty paper list on Ubuntu in the first place.

Comment 37

[Erik Nordin [:nordzilla]]

Attachment: Bug 1662946 - Fix Paper List Retrieval For Older Versions of Ubuntu

• Rename EnsurePrinterInfo to TryEnsurePrinterInfo to reflect the fact that it can fail to populate the printer info.
• Add argument to TryEnsurePrinterInfo to accept a connection other than the default.
• Allow TryEnsurePrinterInfo to try once with the default connection and once with an established connection.
• Use an established connection to retrieve the paper list information.

Comment 38

[Erik Nordin [:nordzilla]]

I did more digging into this by setting up an Ubuntu 16.04.7 VM and configuring it to build Firefox locally.

I was able to determine that the cause of the empty paper list is that cupsCopyDestInfo(), called from EnsurePrinterInfo(), is returning null here, which returns the empty list here, as expected.

I ran the affected code on my Ubuntu 20.04.1 VM and it worked just fine, so I am assuming that there is a difference in the different CUPS versions shipped with each operating system. I have not tested with an Ubuntu 18 VM, but I believe it is affected the same way 16 is, based on previous comments.

Fortunately, it looks like we receive a null printerInfo on older versions of Ubuntu only when we try to retrieve the information via CUPS_HTTP_DEFAULT. I tested retrieving information from my Canon iX6820 using an established printer connection (rather than the default) on my Ubuntu 16.04.7 VM and was able to successfully retrieve a paper list.

I am hopeful that this patch will fix the issue.

Comment 39

[Erik Nordin [:nordzilla]]

Attachment: Bug 1662946 - Use Printer Connection For CUPS Printers r=alaskanemily,emilio,jwatt

• Add mConnection data member to CUPSPrinterInfo.
• Modify TryEnsurePrinterInfo to create and store a connection.
• Rename EnsurePrinterInfo to TryEnsurePrinterInfo to reflect the fact that it can fail to populate the printer info.
• Use an established connection to retrieve the paper list information.

Comment 40

[Phabricator Automation]

Comment on attachment 9177757 [details]
Bug 1662946 - Use Printer Connection For CUPS Printers r=alaskanemily,emilio,jwatt

Revision D91359 was moved to bug 1667495. Setting attachment 9177757 [details] to obsolete.

Comment 41

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/283a25b4065f
Fix Paper List Retrieval For Older Versions of Ubuntu r=emilio

Comment 42

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/283a25b4065f

Comment 43

[Erik Nordin [:nordzilla]]

Comment on attachment 9177476 [details]
Bug 1662946 - Fix Paper List Retrieval For Older Versions of Ubuntu

Beta/Release Uplift Approval Request

• User impact if declined: Older versions of Ubuntu (such as 16 LTS) will not be able to retrieve accurate paper lists from printers.
• 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: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch should fix paper list retrieval for older versions of Ubuntu (because they are running older versions of CUPS). The newer versions of CUPS, such as on macOS should be unaffected. The code paths do not affect Windows at all.

I have tested this with local builds on Ubuntu 16 LTS, Ubuntu 20 LTS, and macOS 10.15.6

• String changes made/needed:

Comment 44

[Lee McFarland]

Attachment: resulting view now that the hang in Ubuntu 16.04 is resolved

Comment 45

[Lee McFarland]

As of this morning's nightly build, the hang is gone on Ubuntu 16-04. Once the print menu shows (which is quick), a print can be made. With all this effort on the print UI, there is a possibility something undesirable could slip into the standard release of firefox. Please consider continuing to allow the config preference print.tab_modal.enabled as it allows a work-around to issues with the print UI. Not that the user community would regularly set such a preference to FALSE but, the ability to print a webpage is too critical to intentionally remove a possible work-around.

The resulting print menu is functional but not clean. While the menu is shown, the preview area at the left is a large gray square with a white rectangle within. This area covers the majority of the screen. A screenshot (U16-1662946) was just added

Comment 46

[Erik Nordin [:nordzilla]]

Lee,

I'm glad that the hang is gone for you.

With regard to the tiny page that you are seeing in the print preview, we are aware that this sometimes happens, and it is being tracked in bug 1659928.

As far as I know (which may be wrong), there is no intention to remove the print.tab_modal.enabled preference when the print UI is released. When we release features, we will typically set the default value to true instead of false, but the preference still exists within about:config.

Even if the preference were to disappear, you should still be able to access the system print dialog via the Print using the system dialog... button near the bottom of the new UI.

Thank you again for your efforts to test the new UI on your hardware, and to bring up your concerns and considerations on bugzilla. It's much appreciated.

Comment 47

[Jonathan Watt [:jwatt]]

Seconded. Thanks for contributing your time to test the new UI and report the multiple bugs you've found, Lee! It's been very valuable.

Comment 48

[Julien Cristau [:jcristau]]

Comment on attachment 9177476 [details]
Bug 1662946 - Fix Paper List Retrieval For Older Versions of Ubuntu

approved for 82.0b5

Comment 49

[Julien Cristau [:jcristau]]

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

Comment 50

[Anca Soncutean, Desktop QA]

Reproduced with Fx 82.0a1 (2020-09-02) on Ubuntu 16.04.
Verified fixed with Fx 83.0a1 (2020-10-01) and Fx 82.0b6 on Ubuntu 16.04 and Ubuntu 18.04; although not a direct target here, things look good also on macOS 10.15 and Windows 10.