Affected versions

• 81.0a1 (BuildId:20200815093117)

Affected platforms

• Windows 10 64bit
• macOS 10.14
• Ubuntu 18.04 64bit

Preconditions

• Ensure that the print.tab_modal.enabled pref is set to true

Steps to reproduce

1. Launch Firefox.
2. Access the following link.
3. Open the print preview.
4. Fastly switch between “Fit to page” & scale radio buttons. (Also try switching to different orientation options while doing this).

Expected result

• The print preview updates successfully.

Actual result

• The system dialog gets open & “An error occurred while printing” error message is displayed.

Regression Range

• This seems to be a regression:
• Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4e6b4ef959560877408e46d85db19011b1ca5efe&tochange=5b4faf8f838301f19d6350f477dfd080ee6aeea8
• Potential Regressor: Bug 1657911

Notes

• The following error is outputted inside the browser console:
  TypeError: can't access property "hasAttribute", tab is undefinedLinkHandlerParent.jsm:46:15
• For further information regarding this issue please observe the attached screencast.
• [Suggested Severity] S2

Hi Hiro!

It seems that mozregression pointed out Bug 1657911 - Call nsDeviceContext::UnregisterPageDoneCallback only in the parent process and only if IsSyncPagePrinting. r=jwatt for causing this regression.

Can you please take a look?

Thank you!!

As a side note..it seems that, sometimes, while reproducing this behavior the print preview gets broken (no longer displays the page and remains in a loading state until the user reopens the print preview)

I believe it's a pre-existing issue, the change stopped the crash, then the process is able to keep running, then the dialog. :/

I will try to poke around.

I'm adding some additional steps that can reproduce this behavior much easier and to trigger the behavior mentioned in comment 1 as well.

Instead of fastly changing between the scaling & orientation option, you can:
Step 4: Using keyboard navigation, reach the Destination section and keep the up arrow key & down arrow key to fastly change between the available printing options.

Okay, the dialog is triggered by ShowPrintDialog call in nsPrintJob::DoCommonPrint.

There are two cases I've seen where the ShowPrintDialog gets called.

1. We do unconditionally call it if "print.print_via_parent" is true
2. mIsCreatingPrintPreview is changed to false while processing nsPrintJob::DoCommonPrint, that what saw in bug 1657911 comment 8

As for 1) I believe with the new print preview UI setup we don't need to open the dialog to get print settings.

As for 2) I have no idea other than checking the change as I commented in bug 1657911 comment 8.

:bobowen, am I correct about 1)?

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

Okay, the dialog is triggered by ShowPrintDialog call in nsPrintJob::DoCommonPrint.

There are two cases I've seen where the ShowPrintDialog gets called.

1. We do unconditionally call it if "print.print_via_parent" is true
2. mIsCreatingPrintPreview is changed to false while processing nsPrintJob::DoCommonPrint, that what saw in bug 1657911 comment 8

As for 1) I believe with the new print preview UI setup we don't need to open the dialog to get print settings.

As for 2) I have no idea other than checking the change as I commented in bug 1657911 comment 8.

:bobowen, am I correct about 1)?

Yes, although we don't actually open the dialog at all for print preview.
Unfortunately that was a hack to hijack an existing sync call to open the dialog and retrieve settings, to just retrieve the settings for the print preview case. It needed to be uplifted, which is why I decided to hijack that call which already did what we needed, just without the display of the print dialog.
We found that some print drivers were writing to files for some reason and breaking due to the sandbox.

My guess as to what is happening here, we have a subsequent PrintPreview running in the same nsPrintJob and mIsCreatingPrintPreview is getting set to false at [1], in a nested event loop (or something).

[1] https://searchfox.org/mozilla-central/rev/2f9eacd9d3d995c937b4251a5557d95d494c9be1/layout/printing/nsPrintJob.cpp#2615

(In reply to Bob Owen (:bobowen) from comment #5)

My guess as to what is happening here, we have a subsequent PrintPreview running in the same nsPrintJob and mIsCreatingPrintPreview is getting set to false at [1], in a nested event loop (or something).

Yes, that's one of the causes.

Set release status flags based on info from the regressing bug 1657911

As far as I can tell this was fixed by bug 1659432. Thank you Emilio!

I can no longer reproduce this issue using Firefox 81.0a1 (BuildId:20200823211533) on Windows 10 64bit, macOS 10.14 & Ubuntu 20.04.

https://testrail.stage.mozaws.net/index.php?/cases/view/1081134