Handling `Print Preview` in WebDriver

[whimboo]

While the current user prompt handler covers basic prompt types and beforeunload, there are other prompts or prompt-like pop-ups, such as Print Preview, that block the visible tab (including all its browsing contexts).

Print Preview is a unique case, raising the question of whether it should be handled at all from a WebDriver perspective. Since it behaves like its own window but runs in the browser’s chrome context, it might not require handling within the WebDriver protocol.

As mentioned in bug 1932525, both Chrome and Edge allow users to interact with Print Preview by switching to a specific window handle. However, this can be confusing because Print Preview is not a real tab and also blocks access to the underlying web content.

We’d like to discuss whether handling such dialogs is necessary, and if so, how it could be implemented effectively.

CC @jgraham @OrKoN @sadym-chromium @gsnedders @shs96c

[gsnedders]

Since it behaves like its own window but runs in the browser’s chrome context, it might not require handling within the WebDriver protocol.

What do you mean by "print preview" here? There's an application-provided "print" dialog that (at least) Firefox and Chrome have, with an option to switch to the system print dialog? I don't see that called "print preview" anywhere in the UI of either, at least on macOS?

But notably, not all user agents provide such a dialog. Safari uses the system dialog, which is window model, and thus you cannot interact with the page or any other tab in the same window. I'd also be curious about what happens on mobile browsers — where I expect print dialogs might be application model? See also #1090 about the print dialog.

#1781 is thus also related here, because it's another case of "what is a user prompt", especially when user agents can and do make up their own prompts in ways that do not implicate any web standard.