1898184 - tab or page freezes after printing with print.prefer_system_dialog=true

Status: VERIFIED FIXED

(Core :: Print Preview, defect)

Description

[Olivier]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15

Steps to reproduce:

I wanted to print an e-mail in outlook.office.com or a badge for visitors in our company's home-made web page using the mac's dialog window, not the Firefox one.

Actual results:

Once I click "print" in the dialog window, the tab or page doesn't respond anymore. Even the refresh button doesn't work. I need to close it and open a new tab or page. It may be related to javascript:window.print() that appears in the lower left corner of the page.

Expected results:

The page or tab should still respond like reading another e-mail or going back to the main menu of the visitor's badge creation.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Print Preview' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

Would it be possible to either attach a profile or a single-file of the page, if it's page-specific?

Also:

• If this worked before, it might be useful to run mozregression to see what caused this.
• This might be specific to a particular macOS version or configuration in your machine, so it'd be useful to know the about:support information too.

Thanks.

Comment 3

[Olivier]

Hello !

It worked with Firefox 125.0.3 and when I updated to 126.0, I had that freeze.

And after more researches, I found the culprit:
I configure the user.js file in the user's profile to set the default printing window to the system one as there are missing preferences with the print window of Firefox. During my testings, I removed the user.js file but didn't notice that the configuration remained. Once I've set it back to default, it's working again. It's the following line:

user_pref("print.prefer_system_dialog", true);

And I just noticed that if I use the Firefox print window as default then switch to the system one by clicking the link "Print using the system dialog...", I haven't the problem.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Thanks, that is good to know. Still it's not hanging with that pref on my macOS system for a simple page like data:text/html,<button onclick=print()>Print, so there might be other things responsible for it. Could you attach the about:support info to see if there''s something suspicious in the other print. prefs or what not? Thanks.

Comment 5

[Olivier]

Attachment: FF126-raw data.txt

Comment 6

[Olivier]

Attachment: FF126-text.txt

Comment 7

[Olivier]

Hello !

I've attached the files. It took me some time because I installed macOS Ventura 13.6.7 from scratch on my lab computer, installed Firefox 126.0, the copier's drivers, added the copier, opened FF and I've set the print.prefer_system_dialog to true in the about:config pane (not using user.js), I then went to my webmail in outlook.office.com and printed a mail. I did nothing more and I got the problem.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Ok, so just to confirm, you don't even get to see the native dialog, correct? Or do you see the dialog, and the tab hangs when you actually print?

In any case, would it be feasible for you to take a performance profile to see what might be going on?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I tried to reproduce on outlook.live.com which is the closest thing I have but I still see the dialog just fine.

Comment 10

[Olivier]

I always have the print dialog window. The problem lies after I've clicked the "print" button.

If I set print.prefer_system_dialog to false, I have the window from Firefox. I click the "Print using the system dialog..." link and I can print my e-mail just fine using the system print window and the web page continues to respond.

If I have print.prefer_system_dialog to true, I have the window from macOS, I click the "print" button and my e-mail prints but the web page no longer responds. I can't do anything except close it and open a new one.

I can reproduce this behavior every time and actually on the 5 computers on which I took a look.

Please note that it's when there's a print icon like outlook.office.com that I have that problem. If i'm on a google search result page, I can print just fine using the File => Print... menu. I can reproduce the problem on outlook.live.com too.

For the performance profile, here it is: https://share.firefox.dev/3WU7aKu

Comment 11

[Olivier]

Hello !

As I said in my first message, we use a website to register visitors and print a badge for them. As it's home-made, I asked my colleague to check the print button that he uses and here's the code below. He also made another button for test as you may notice, for the same result. Maybe that it will help.

<span class="message_ok">Visiteur enregistré, veuillez<br /><a href="javascript:window.print();" class="btn btn-success" role="button">imprimer le badge</a></span><span class="message_ok">Visiteur enregistré, veuillez<br /><a href="#" onClick="window.print();" class="btn btn-success" role="button">imprimer le badge TEST</a></span>

I've updated Firefox to the latest version, 126.0.1, the problem still persists.

Comment 12

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

The severity field is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit BugBot documentation.

Comment 13

[Jonathan Kew [:jfkthame]]

I was able to reproduce this in Nightly on macOS, as follows:

• In about:config, ensure that print.prefer_system_dialog is set to true
• Load data:text/html,<span>Test <a href="javascript:window.print();">print</a></span>
• Hover over the print link, and observe that the cursor changes to a pointing finger, and the javascript:window.print(); shows in the status panel at bottom left
• Now click the print link; the system print dialog appears
• As I don't have an actual printer connected, I chose Open in Preview from the PDF menu at bottom left
• The PDF is generated and opens in Preview, as expected
• Click back on the browser window
  • observe that the javascript:window.print(); status remains "stuck" no matter where the cursor is moved
  • observe that the cursor remains a pointing finger even when it isn't over the link
  • the content is completely unresponsive

This does not occur if print.prefer_system_dialog is set to false, and the system dialog opened via the Firefox print panel.

Capturing a profile after doing the print operation, so that the content window is in this "stuck" state, we can see that it is inside SpinEventLoopUntil, called from nsGlobalWindowOuter::Print. Apparently the context bc is never getting discarded, and we're blocking forever.

Marking S3 as this involves a non-default pref setting, and at least the parent process remains responsive so it's possible to close the unresponsive tab, but it does seem like a genuine bug.

Comment 14

[Jonathan Kew [:jfkthame]]

FWIW, the problem reproduces on Windows, too, with print.prefer_system_dialog set to true. Profile shows we're stuck in the same SpinEventLoopUntil call.

Comment 16

[Olivier]

Hello !

Any news about this ? I just tried on the latest Firefox version (129.0.1), still same problem. Quite annoying as my colleagues have to close the tab and open a new one for each printed document but they don't have any other choice.

Comment 17

[iYx3Zp8Q08hrNVZCHTYt]

Hello Forum,

We have tried this on different version across different OS as given below:

• v128.3.0esr (Windows 11)
• v128.3.0esr (Debian 12)
• v131.0 (Archlinux)

We are still facing the issue when using system dialog instead of Firefox's built-in dialog in order to print a document, and it is resolved when using the Firefox's dialog. However, due to current structure, we need to be able to print directly (or save) to specific folders. Can there be an alternative to stop the SpinEventLoopUntil call, as reported by Jonathan?

Comment 18

[Jonathan Kew [:jfkthame]]

According to the comment here, it looks like the behavior of blocking on bc is supposed to be specific to the new print UI. In that case, I think the fix here is actually quite trivial: if print.prefer_system_dialog is set, then we're not using the new UI and we don't need to block here at all.

Currently shouldBlock gets set because aIsPreview will always be Yes unless the print.always_print_silent pref was set. But if print.prefer_system_dialog then we're not actually going to open the preview pane, so that's kinda misleading.

Comment 19

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1898184 - Don't set the forPreview flag if the prefer_system_dialog pref is set, to avoid blocking forever in nsGlobalWindowOuter::Print. r=jwatt

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d5bf3d6c98a7
Don't set the forPreview flag if the prefer_system_dialog pref is set, to avoid blocking forever in nsGlobalWindowOuter::Print. r=jwatt

Comment 21

[Cosmin Sabou [:CosminS]]

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

Comment 22

[Markus Stange [:mstange]]

There's a report from ESR 128 in bug 1923561 of what is likely to be the same issue.

Comment 23

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1898184 - Don't set the forPreview flag if the prefer_system_dialog pref is set, to avoid blocking forever in nsGlobalWindowOuter::Print. r=jwatt

Original Revision: https://phabricator.services.mozilla.com/D224950

Comment 24

[Phabricator Automation]

esr128 Uplift Approval Request

• User impact if declined: content process hangs after using window.print, for users with prefer_system_dialog=true
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: see comment 13
• Risk associated with taking this patch: minimal
• Explanation of risk level: trivial patch to add a pref-check
• String changes made/needed: none
• Is Android affected?: yes

Comment 25

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

The patch landed in nightly and beta is affected.
:jfkthame, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox132 to wontfix.

For more information, please visit BugBot documentation.

Comment 26

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr128/rev/d2ed121d32ae

Comment 27

[Ina Popescu, Desktop QA]

I've replicated this issue using Nightly 128.0a1 (2024-05-22) on Windows 11 x64 following the STR from Comment 13.
Verified as fixed in the Firefox 133.0b3 version on Windows 11 x64, macOS 13, and Ubuntu 22.04, as the issue no longer occurs.

Comment 28

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1898184 - Don't set the forPreview flag if the prefer_system_dialog pref is set, to avoid blocking forever in nsGlobalWindowOuter::Print.

Original Revision: https://phabricator.services.mozilla.com/D224950

Comment 29

[Phabricator Automation]

release Uplift Approval Request

• User impact if declined: content process hangs after using window.print, for users with prefer_system_dialog=true
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: see comment 13
• Risk associated with taking this patch: minimal
• Explanation of risk level: trivial patch to add a pref-check
• String changes made/needed: none
• Is Android affected?: yes

Comment 31

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/eae4af2a9ec1

Comment 32

[Ina Popescu, Desktop QA]

Also verified as fixed in the Firefox 132.0.2 version on Windows 11 x64, macOS 13, and Ubuntu 22.04, as it no longer occurs. I'll verify in Firefox 128.5.0esr once the build is available.

Comment 34

[Ina Popescu, Desktop QA]

Verified as fixed in the Firefox 128.5.0esr version on Windows 11 x64, macOS 13, and Ubuntu 22.04. Updating the flags accordingly.