When you try to print during document load, we used to get a dialog saying "Cannot print this document yet, it is still being loaded.".

This stopped happening after bug 1636803 landed.

Can you clarify the steps to reproduce? I just tried on macOS, and maybe I'm too slow or my internet too fast, but I can't get the dialog to appear on 79...

(In reply to :Gijs (he/him) from comment #1)

Can you clarify the steps to reproduce? I just tried on macOS, and maybe I'm too slow or my internet too fast, but I can't get the dialog to appear on 79...

I tend to use either the single page html spec (https://html.spec.whatwg.org/) or the boston globe home page (https://www.bostonglobe.com/).
Which both take a while to load for me and then Ctrl+P (Cmd+P on macOS) during the load.

Bug 1653323 will address some part of this bug - the print UI will show up and the preview area will show a "loading" state until the document is ready.

Sean, is this dialog something that should still be shown when loading?

Ideally, the tab modal UI appears immediately, with a loading indicator on the preview while the load finishes, and the print button disabled until then. I think we should get rid of the dialog. (At least, this is a summary of what we discussed in a prior printing meeting.)

This wasn't really a bug against the new print preview UI, it was for a regression to the old printing one.

If you hit Ctrl+P (for example) while a document is loading, it used to give you this dialog, which you had to cancel and then the print dialog would appear (and still does) once the document had loaded.
This wasn't without problems, because if you didn't cancel the warning dialog, the print dialog would still appear (due to a nested event loop under the warning dialog). This used to cause issues because of pre-win8's own crazy event loop processing under the print dialog.

However, if you went to print with the old UI and the document hadn't loaded, we've gave you some indication of why the print dialog hasn't appeared and now we don't.
I understand that we may not want to fix regressions at this stage in the old UI, but just wanted to be clear on what this actual regression is. :-)

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

This wasn't really a bug against the new print preview UI, it was for a regression to the old printing one.

I see. I'll keep as P2; ideally we fix it by 81 but there are higher priorities. Given the regressing bug, I'm going to move it to Core::Print Preview to track for the platform side.

I'm not sure we'll actually fix this. Rather than opening a modal dialog window, it seems preferable that for the new doorhanger UI, it opens immediately (before the document has loaded), spins its throbber until the document has loaded, and only then tries to create the print preview. I've opened bug 1663972 for that. I'll keep this as [print2020_v83] to make sure it's not completely off the radar, but that's my current thinking.