1652764 - window.print() takes a very long time as of FF 78 on Macos Sierra

Status: RESOLVED FIXED

(Core :: Print Preview, defect)

Description

[tom.bertrand]

Attachment: FF-print.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

Install the latest FF 78 on MacOS Sierra, attempt a window.print() from the console, notice the time it takes for it to trigger the print prompt.

Actual results:

An excessive amount of time is being used before seeing the print prompt.

Expected results:

Same as FF 77 where the print prompt would instantly trigger.

Comment 1

[Peter Magyari (Desktop QA)]

Hi Tom,

I couldn't reproduce the issue you've mentioned on either Firefox 78.0.2 or Firefox 80.0a1 on MacOS 10.14 or 10.15 (I do not have access to 10.12)

Could you check if this issue also occurs while using a new profile? (you won't lose your old profile) Here is a link that can help you do that:
https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles#w_start-the-profile-manager-when-firefox-is-closed

Thanks!

Comment 2

[frank.robert]

Can confirm this issue on MacOS 10.12 Sierra.

It's worth noting that High Sierra nor Catalina can reproduce this issue.

• CMD+P works as expected and immediately prompts the print dialog.
• All examples on https://developer.mozilla.org/en-US/docs/Web/Guide/Printing either fail entirely or take quite a bit of time (30s+) before the print dialog appears.

Here are the results available on the firefox profiler

Comment 3

[frank.robert]

It might also be worth noting we have about 100 individual users of our application on 10.12 reporting this issue for Firefox 78.xx

Comment 4

[tom.bertrand]

Attachment: window.print-profile

Comment 5

[tom.bertrand]

Attachment: window.print-profile2

Comment 6

[tom.bertrand]

Hey Peter, thanks for your reply.

The issue only happen on MacOS 10.12 Sierra since FF 78, (we've recommended to our users to downgrade to FF 77 for the time being and they were able to resume their printing operations). I tried creating a new profile as you suggested and the same performance issue was noticeable by simply calling window.print() from the console.

Comment 7

[Peter Magyari (Desktop QA)]

I'll set a component in order to involve the development team in reviewing the issue.

Meanwhile, could you please check if it is the same on the latest Firefox Nightly? You can download it from here:
https://www.mozilla.org/en-US/firefox/channel/desktop/

Thank you!

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Could you upload a profile, not only a picture of a profile?

Comment 9

[frank.robert]

Attachment: profile-window.print.json

(In reply to Olli Pettay [:smaug] from comment #8)

Could you upload a profile, not only a picture of a profile?

The screenshot Tom uploaded comes from the profile I linked. Uploaded for ease of access.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Aha, I missed the link in comment 2

But the profile is showing only one process, and that process is waiting for something.
Seeing also what is happening in other processes would be good.

Comment 11

[tom.bertrand]

Attachment: window.print-ff-nightly.jpg

Comment 12

[tom.bertrand]

Hey Olli, I've tried publishing the profile which has a bit more informations I hope, lmk if there is something else I can help with

https://profiler.firefox.com/public/3kv6zz03kd2an448yp7s99nfq6mje6hmrgd3dh8/network-chart/?globalTrackOrder=6-0-1-2-3-4-5&hiddenGlobalTracks=1-2-3-4&localTrackOrderByPid=18751-1-0~18754-0~&thread=6&v=4

Comment 13

[Mats Palmgren (inactive)]

Doesn't seem related to Layout, but feel free to send it back if it turns out it is.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

Does window.print() take lots of time only if executed from the console?

Comment 15

[frank.robert]

(In reply to Olli Pettay [:smaug] from comment #14)

Does window.print() take lots of time only if executed from the console?

It also takes a significant amount of time if executed from some .js scripts

Comment 16

[Sean Voisen (:svoisen)]

jwatt: Anything you can think of that landed as part of print refactoring in 78 that might be related?

I'll move this to Print Preview for the time being to keep it out of Core::General.

Comment 17

[Daniel Bodea [:danibodea]]

According to this (https://bugzilla.mozilla.org/show_bug.cgi?id=1627626#c14), mozregression cannot be installed on Mac OS 10.12. Regression window finding procedure should be attempted while using Mac OS 10.13.

Comment 18

[Daniel Bodea [:danibodea]]

I have managed to run a special version of mozregression after all and I have come up with these results:

59:18.27 INFO: No more integration revisions, bisection finished.
59:18.27 INFO: Last good revision: 0f1e35bee5748fc5d8c5f2043d32c16ed261c99b
59:18.27 INFO: First bad revision: faf8e8097d2351b57063ad15b75d54c6ce32b24d
59:18.27 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0f1e35bee5748fc5d8c5f2043d32c16ed261c99b&tochange=faf8e8097d2351b57063ad15b75d54c6ce32b24d

Please NI me if retesting is necessary.

Comment 19

[Jonathan Kew [:jfkthame]]

Tom, do you have a large number of printers configured or available (in System Preferences / Printers & Scanners), by any chance? Or network-connected printers that might be taking a long time to respond when the system queries them?

Erik, can you investigate this at all? I wonder if there are conditions that make the [NSPrinter printerNames]; query potentially very slow to return...? (Note that it's only on 10.12, though; according to comments above, more recent OS versions don't suffer from the issue.)

Comment 20

[tom.bertrand]

Hey Jonathan, I currently have no printer setup on my testing environment (Printers & Scanners is empty). If it can help your investigation we do have ~95 opened tickets (starting a day or 2 after FF 78 was released) with a subset of our customers that are all using MacOS Sierra. For the mean time we recommend them to downgrade to FF 77 which solves their issue.

Comment 21

[Erik Nordin [:nordzilla]]

I can confirm that I am unable to reproduce this behavior on my macOS 10.15.5 build.

Based on the attached profile, it looks like there is a poll to libsystem_kernel.dylib that is taking up a lot of time.

I believe that jwatt may be working on something that may resolve this issue.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

Should bug 117233 be backed out until this is fixed?

Comment 23

[Erik Nordin [:nordzilla]]

I don't know if that would be feasible.

This is pretty hot area of the code, especially within the last few weeks. Many changes are already built on top of that patch; and the class itself (along with its XPIDL interface) have been modified/renamed/provided new functionality since Bug 117233 landed.

But I would defer to jwatt's judgment for a final answer.

Comment 24

[Jonathan Watt [:jwatt]]

Attachment: stack

Comment 25

[Jonathan Watt [:jwatt]]

To cut a very long story short, this is caused by sandboxing causing the [NSPrinter printerNames] call to hang (which is actually bug 1324610 which we fixed years ago when Sierra was the latest OS X version) due to us invadvertantly calling that on the content process. I'm still figuring out the best way to fix the code.

Comment 27

[Jonathan Watt [:jwatt]]

Attachment: Bug 1652764. Only allow nsPrinterList objects to be created in the main process. r=bobowen

Comment 28

[Phabricator Automation]

Comment on attachment 9167151 [details]
Bug 1652764. Only allow nsPrinterList objects to be created in the main process. r=bobowen

Revision D85476 was moved to bug 1657854. Setting attachment 9167151 [details] to obsolete.

Comment 29

[Bob Owen (:bobowen)]

Attachment: Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt!

Comment 30

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=cb04cbbe017729c25d0b9c272b1e390008f5034f

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dfbfb3f7c5b8
Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

Comment 32

[Bob Owen (:bobowen)]

I'll get the patch up for Beta and ESR78, on Monday.
Should be the same patch for both, hopefully.

Comment 33

[Atila Butkovits]

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

Comment 34

[Bob Owen (:bobowen)]

Attachment: * Beta * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

Comment 35

[Bob Owen (:bobowen)]

Attachment: * ESR78 * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

Comment 36

[Bob Owen (:bobowen)]

Comment on attachment 9169139 [details] [diff] [review]

• Beta * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

Beta/Release Uplift Approval Request

• User impact if declined: Users on older macOS versions will continue to experience long delays waiting for the print dialog.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: Assuming QE have equipment with affected versions of macOS, see bug Description for STR.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should be low risk, simple patch to block interface being created in content process, which is effectively what happened before the regressing patch landed.
• String changes made/needed: None

Comment 37

[Julien Cristau [:jcristau]]

Comment on attachment 9169139 [details] [diff] [review]

• Beta * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

approved for 80.0b7

Comment 38

[Julien Cristau [:jcristau]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4d19b53fb9df

Comment 39

[Negritas Sergiu, Desktop QA]

Hello! I managed to reproduce the issue following the STR provided in the description using Fx 78.0.2 on macOS 10.12 (Sierra).
I can confirm that the issue is fixed on Fx 80.0b7 and on Fx nightly 81.0a1 (2020-08-11) using the same OS version.

Comment 40

[Bob Owen (:bobowen)]

(In reply to Negritas Sergiu from comment #39)

Hello! I managed to reproduce the issue following the STR provided in the description using Fx 78.0.2 on macOS 10.12 (Sierra).
I can confirm that the issue is fixed on Fx 80.0b7 and on Fx nightly 81.0a1 (2020-08-11) using the same OS version.

Thanks for verifying.

Comment 41

[Bob Owen (:bobowen)]

Comment on attachment 9169140 [details] [diff] [review]

• ESR78 * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Severe delay on printing dialog, making the feature very annoying or possibly apparently broken altogether.
• User impact if declined: Users on older macOS versions will continue to experience long delays waiting for the print dialog.
• Fix Landed on Version: 81
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should be low risk, simple patch to block interface being created in content process, which is effectively what happened before the regressing patch landed.
  Patch very similar to the one landed on Nightly and Beta, with just interface name changes.
• String or UUID changes made by this patch: None

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9169140 [details] [diff] [review]

• ESR78 * Bug 1652764: Only allow nsPrinterList objects to be created in the main process on macOS. r=jwatt

Approved for 78.2esr.

Comment 44

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/4926d2fb2493