Empty paper lists cause hangs firefox on Ubuntu 18.04/16.04 (Error: Can't fetchPaperMargins)
Categories
(Core :: Printing: Output, defect, P1)
Tracking
()
People
(Reporter: 6dnail, Assigned: nordzilla)
References
Details
(Whiteboard: [print2020_v82][old-ui-])
Attachments
(4 files, 2 obsolete files)
(deleted),
image/png
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/x-phabricator-request
|
jcristau
:
approval-mozilla-beta+
|
Details |
(deleted),
image/jpeg
|
Details |
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•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
Comment 2•4 years ago
|
||
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•4 years ago
|
||
list of printers that appears after the dialog finally stops loading (might be > 5 minutes), also includes remote printers
Reporter | ||
Comment 4•4 years ago
|
||
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•4 years ago
|
||
Updated•4 years ago
|
Comment 6•4 years ago
|
||
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•4 years ago
|
||
(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!
Updated•4 years ago
|
Reporter | ||
Comment 8•4 years ago
|
||
(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•4 years ago
|
||
(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.
Updated•4 years ago
|
Reporter | ||
Comment 10•4 years ago
|
||
(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•4 years ago
|
||
The error should have been already fixed (bug 1661607).
Comment 12•4 years ago
|
||
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•4 years ago
|
||
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;
- For the non ".local" printer, FetchCUPSVersionForPrinter fails here, thus the CUPS version of the printer will be 0
- Thus, for the non ".local" printer SupportsColor always returns true (I think this is the cause of the issue on Lee's environment)
- 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
Reporter | ||
Comment 14•4 years ago
|
||
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.bz2The 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•4 years ago
|
||
That's super confusing.. It seems to me that it just depends on the total page number of the side...
Reporter | ||
Comment 16•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 17•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
I suspect it's not broken, but could you also check whether printing in broken with the new UI pref disabled?
Comment 20•4 years ago
|
||
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.
Reporter | ||
Comment 21•4 years ago
|
||
(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?
Reporter | ||
Comment 22•4 years ago
|
||
(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
Reporter | ||
Comment 23•4 years ago
|
||
(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.
Reporter | ||
Comment 24•4 years ago
|
||
Comment 25•4 years ago
|
||
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•4 years ago
|
||
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•4 years ago
|
||
(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•4 years ago
|
||
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•4 years ago
|
||
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?
Reporter | ||
Comment 30•4 years ago
|
||
(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 prefprint.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
Reporter | ||
Comment 31•4 years ago
|
||
(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 prefprint_printer
contains?
The printer is my default printer, local name is BigSquid. It is a networked printer. The printer is a Canon iX6820
Reporter | ||
Comment 32•4 years ago
|
||
(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.
Updated•4 years ago
|
Comment 34•4 years ago
|
||
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.
Reporter | ||
Comment 35•4 years ago
|
||
(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.
Assignee | ||
Comment 36•4 years ago
|
||
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.
Assignee | ||
Comment 37•4 years ago
|
||
- 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.
Assignee | ||
Comment 38•4 years ago
|
||
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.
Updated•4 years ago
|
Assignee | ||
Comment 39•4 years ago
|
||
- 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.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Comment 40•4 years ago
|
||
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•4 years ago
|
||
Updated•4 years ago
|
Comment 42•4 years ago
|
||
bugherder |
Assignee | ||
Comment 43•4 years ago
|
||
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:
Reporter | ||
Comment 44•4 years ago
|
||
Reporter | ||
Comment 45•4 years ago
|
||
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
Assignee | ||
Comment 46•4 years ago
|
||
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•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 48•4 years ago
|
||
Comment on attachment 9177476 [details]
Bug 1662946 - Fix Paper List Retrieval For Older Versions of Ubuntu
approved for 82.0b5
Comment 49•4 years ago
|
||
bugherder uplift |
Updated•4 years ago
|
Updated•4 years ago
|
Comment 50•4 years ago
|
||
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.
Description
•