Some PDF content doesn't get shown in print preview. It's shown in the print and in the PDF viewer. Both PDF files for which I noticed the issue are not public but one is my MoCo payslip (the "LOHN" one). Because Emilio has access to similar documents, maybe he can reproduce the issue? Page 2 is always affected, page 3 sometimes. The tables are getting cut off in a row and nothing gets rendered below on the page.

For another document which I could share with MoCo employees, the first two pages don't get rendered and toggling the printing of backgrounds doesn't change anything.

This can be often reproduced with page 3 of https://5essexcourt.co.uk/images/uploads/misc/5_Essex_Court_Pupillage_Application_Round_2018.pdf which is shown as blank in these cases.

Not reproducible with Nightly on Windows 10 (10 attempts).

Bisection for the blank page issue points to bug 1636728 as regressor.

I also couldn't reproduce on Linux, nor Mac.

I pondered a bit about whether reusing the print preview document meant that some state related to the print callback ended up being messed up, but I don't think that can't happen... So I suspect it's some sort of canvas bug, but...

Nical, do you know of 2d-canvas specific codepaths in Win8 or such which could explain this? (For reference, printing a pdf with pdf.js uses the .mozPrintCallback API which effectively just gives you a context to render into).

It looks like PDF.js is supposed that mozPrintCallbacks are called between beforeprint and afterprint? But now the callback is called after the afterprint event.

It's been over a year since we stopped doing that though. Since https://phabricator.services.mozilla.com/D34280 we've dispatched the events directly before and after the original clone operation.

It just landed two month ago, right?

Oh, wow. There was a long gap between me writing that patch and landing it.

Anyway, it landed for v80, but we're blaming bug 1636728 which landed for v82 Nightly. I'm just trying to say that PDF.js assuming that mozPrintCallbacks are called between beforeprint and afterprint isn't the only factor here (not that you said that). :-)

At any rate, I believe emilio has now reproduced the issue and tracked it down to something to do with the new event loop spinning that his patch does.

A similar issue, bug 1661222 was reported before bug 1636728, and I believe these are caused by the same root cause. Anyways, I agree that firing mozPrintCallback is not the only one factor, I think there are multiple timing specific issues.

Yeah, this is timing-dependent, see bug 1662426 comment 7 for the gory details. Sorry for the noise nical.

I have a try run there which needs some minor pdf.js changes.

:emilio, is bug 1661222 a dupe of this?

I think so.

I believe bug 1662426 fixes this.

Yes, I think the patch in bug 1662426 should fix this, but I couldn't reproduce this exact error so I've asked Aryx to confirm there.