WebProgressListener for printing has STOP (and NETWORK, DOCUMENT) flag set before file has been completely written to disk
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
People
(Reporter: whimboo, Unassigned)
References
Details
While adding the print to PDF feature for our CDP (Chrome dev-tools protocol) implementation for Puppeteer I noticed that the web progress listener for printing states to be done while the file hasn't been completely written to disk yet. As such accessing the file immediately will cause only partial or even no data read.
As workaround for such a situation I had to use a timed check if the file size doesn't change anymore. Usually this additional code runs 200 - 500ms.
Jonathan mentioned to me that this could be related to e10s, and indeed when e10s gets turned off it works all just fine. Setting needinfo for him given that he wants to rewrite the code soon.
Comment 1•4 years ago
|
||
In case anyone is wondering, I intend to let this needinfo sit for now while I'm doing some rewriting. If anyone needs this to be fixed now, let me know.
Updated•4 years ago
|
Comment 2•4 years ago
|
||
Note the patch for bug 1652270 will convert the code to use Promises, but it will still resolve prematurely.
Updated•2 years ago
|
Comment 3•1 year ago
|
||
:whimboo, is this bug fixed by https://bugzilla.mozilla.org/show_bug.cgi?id=1785046?
Reporter | ||
Comment 4•1 year ago
|
||
I have a hard time to reproduce the reported issue even before bug 1785046 got fixed. When I add a dump statement in CDP's print to PDF code I can see the following output for large PDF files:
*** file size pdf: 4152773
*** file size pdf: 4152773
As such the first reported filesize is already above 4MB and the 2nd iteration in the loop doesn't report any further progress. Checking the file on the filesystem afterward has the same reported size and is completely printed.
As such I would say we close this bug as WFM given that I'm not able to find a proper changeset that fixed it for us.
Description
•