So if we have some JS code that does:

window.print();
// delete all the page contents

How do we prevent the delete from happening while the user is doing print preview, and want to change from portrait to landscape?

wouldn't a read-only snapshot of the page allow for relayouting it for print? I'd guess you just need a static DOM tree (or even just a display list)

If such a thing is possible in Blink, then maybe? I can't find the old bug about snapshotting the renderer from ~6 years ago, but we concluded even if we can snapshot the renderer, we can still have plugins like Flash on the page and we cannot snapshot the state of the Flash plugin. I suppose we could take a screenshot of what Flash has drawn on screen, but on a page where Flash is the primary content, stretching the screenshot may not be the best experience.

Media queries can apply differently based on the various print modes or orientation. You need the actual DOM, our display list isn't enough.

You could maybe clone the DOM all the way down the frame tree and display it again in another frame tree for printing. Then you have to figure out what to do about plugins.

We could sync IPC to the browser and hang, when the browser returns it could tell us to either repeat the sync IPC after doing something like relayout in a different orientation or break out of the loop. I don't know if that's much better than a nested message loop though.

I'd like to avoid the nested message loop, as it appears to be impossible for us to not run script inside them, and that in turn triggers a ton of security bugs :(

btw, about plugins, how do we print them? Do we capture a 300dpi screenshot or something? If we just capture something at the current screen resolution, the print out will look suboptimal anyways, so I'd say scaling is fine.

In theory, we're supposed to suspend all script execution, right? How bad would it be for isScriptForbidden() to also check that the execution context wasn't suspended by ScopedPageLoadeDeferrer?

Making print() not run a nested message loop would be nice, but I'm wondering if this same issue can affect alert() / confirm() / prompt().

re: comment 5 - I'd like to as well, I just don't know how. There is also bug 139706 BTW.

re: comment 6 - I believe the only plugins we have at this point are Flash and PDF. For PDF, we use pp::Printing_Dev. Not sure about Flash. I know we go through content/renderer/pepper/pepper_plugin_instance_impl.cc, but a lot of Blink-side is a black box to me. This is if the plugin is the only thing being printed. If the plugin is embedded in a webpage, I'm not exactly sure what happens, though it feels like it could just be an image snapshot.

An orientation change would result in a relayout which can drastically change the size and shape of the plugin. I don't think stretching the plugin will work, it would distort things pretty bad (ex. Border width and text)

FWIW, at least for me on Linux, loading https://www.adobe.com/shockwave/welcome/flash.swf and trying to right click -> print brings up a print preview dialog without any orientation settings. Not sure if print preview just never handled this case and is broken. If I fall back to the native print dialog, changing the orientation there has no effect and it always prints out portrait.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is now the official "window.print() hangs the message loop while the dialog is up" bug and I am duping bugs to it.

As per the spec, the UA _may_ pause the browser while the dialog is up. We do so, and we cause all kinds of issues. As Jochen pointed out in this bug, if we were a bit more clever, perhaps we could get away with not doing so.

 Issue 692385  has been merged into this issue.

 Issue 837674  has been merged into this issue.

Re #13: Do you happen to have any examples of the issues we're encountering? I'm worried that alert() might have the same issues and we can't really stop using message loop there.

Re issues, see the bugs duped here.

As for JS dialogs, we're stuck. However, those at least are auto-dismissing, so that if someone switches away we kill them and let all the other pages continue. I don't know if auto-dismissing the print dialog would be an adequate substitute.