As this being a Non-Regression issue, changing the status to Untriaged so that the issue would get addressed.

Thank You!

Rob, is this a known issue? I imagine it's never worked with the current extension?

The print button in the viewer's toolbar works. Maybe the viewer can listen for window.onbeforeprint and react appropriately?

My extension doesn't automatically close the print preview dialog (extensions and web pages cannot do that).

Printing via the context menu doesn't work though, because the printed content is generated asynchronously. Coincidentally I wrote about the beforeprint event a few days ago (and why the event is useless): https://github.com/mozilla/pdf.js/pull/9439

From looking at it, it looks like this *is* an issue with the native print preview dialog.  Over to thestig to investigate.

Sure, the print preview dialog self closing is probably triggered by a navigation or something. Will look.

Yes, it's a navigation. We have had a few bugs like this in the past. It is very difficult to distinguish which same-page transitions should close print preview -
 one example that came up after a previous attempt to fix this was navigation within chrome://pages - and which should not -
 there was a bug for gmail where the hash at the end of the URL was changing but the expectation was that the preview should not close. Not sure if there will be anything we can do about this, but we can investigate.

A programmatic way to close print preview sounds like a nice work-around to implement asynchronous printing (onbeforeprint = <close print preview>, prepare page, window.print() ).

Is there a seemingly stable / reliable way to close the print preview page? It doesn't have to be officially supported; if I can already intercept print requests, rewrite the page and re-issue the print request, that would already improve the UX of my PDF Viewer extension.

The relevant code is here: https://cs.chromium.org/chromium/src/chrome/browser/printing/print_preview_dialog_controller.cc?l=345
If a page creates a navigation that doesn't match the checks in lines 348-354, the dialog closes. Those checks are trying to draw a line between the cases of  bug 634237  (where the dialog should close since the page changes) and  bug 614998  (where the dialog should stay open because it doesn't), but they aren't perfect, as there does not seem to be a foolproof way to detect whether a navigation changes the underlying page or not.

At one point creis@, who was working on navigation changes, suggested changing those checks out for a more sane-looking check of the is_same_document and did_replace_entry fields of LoadCommittedDetails, but that caused  bug 634237  to come back so we never landed it. I tested and making that change would fix the dialog closing issue here, but it still causes the same regression. FYI, a better example navigation that shows the 634237 case now that MD settings has launched and the reset page is a modal dialog is chrome://settings -> chrome://settings/searchEngines.