For this specific bug, I think the best thing would be to not fire the load event until we're ready to print, because it's possible that the parent page will want to show some sort of UI at that point too.
On the platform side that probably means adding a way to block the load event firing and then unblock it. As in, ChromeOnly API for
Document::UnblockOnload. Or the PDF code could just add a dummy request to the loadgroup itself, I guess, but exposing the Document APIs seems safer/saner.
Would that be workable on the pdf.js end?
We could try to make beforeprint cancelale or add another pdf-js-specific event, but I'd rather have less platform-side special-casing here....