Bugzilla

(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> Okay, the dialog is triggered by [ShowPrintDialog call](https://searchfox.org/mozilla-central/rev/62494de24f8d4aa003b6ff911e025e07a6d7a117/layout/printing/nsPrintJob.cpp#790-791) in nsPrintJob::DoCommonPrint.
> 
> There are two cases I've seen where the `ShowPrintDialog` gets called.
> 
> 1) [We do unconditionally call it](https://searchfox.org/mozilla-central/source/layout/printing/nsPrintJob.cpp#748,760) 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](https://searchfox.org/mozilla-central/rev/62494de24f8d4aa003b6ff911e025e07a6d7a117/layout/printing/nsPrintJob.cpp#744-747).
> 
> 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 PrintePreview 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 Hiroyuki Ikezoe (:hiro) from comment #4)
> Okay, the dialog is triggered by [ShowPrintDialog call](https://searchfox.org/mozilla-central/rev/62494de24f8d4aa003b6ff911e025e07a6d7a117/layout/printing/nsPrintJob.cpp#790-791) in nsPrintJob::DoCommonPrint.
> 
> There are two cases I've seen where the `ShowPrintDialog` gets called.
> 
> 1) [We do unconditionally call it](https://searchfox.org/mozilla-central/source/layout/printing/nsPrintJob.cpp#748,760) 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](https://searchfox.org/mozilla-central/rev/62494de24f8d4aa003b6ff911e025e07a6d7a117/layout/printing/nsPrintJob.cpp#744-747).
> 
> 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