Fix empty PDF issue with Puppeteer ^23.0.0 #876
Conversation
12e0627
to
90b49f8
Compare
c1a1240
to
93e9e35
Compare
|
I discovered this as well last night, but it was quite late, so I didn't have time to PR it :( I'm not personally sure why exactly this issue manifested as it did, but as far as I could tell, attempting to return the raw buffer from the JS side would mess up the encoding or something, because the broken PDFs are encoded as UTF-8, whereas the working one (as decoded from base64 by PHP) is ANSI. |
|
Good point, I looked at it again and tried to see if I could just assert the binary data to contain the text. This works, but it also works with the empty PDF, resulting in a false positive. The thing that causes it to be a white page seems to be very subtle, because all the content is actually there in the binary data. |
|
I don't know much of anything about the PDF structure, but it appears they come out as blocks of stream data, prefixed with a length and "stream" keyword. I'd assume the difference in file encoding might affect that stream data and make it not display, while the binary remains identical. |
|
Very nice, thank you! |
This pull request reintroduces the changes done for Puppeteer v23, while fixing the issue introduced in #870 resulting in a white PDF.
The issue was caused by not using base64 to communicate between puppeteer and Browsershot.
I also added a test that actually checks the contents of the PDF. To do this, I introduced the pdf-to-text package used in https://github.com/spatie/laravel-pdf and also added the same note in the README.
There is still one flaky test: 'can handle a permissions error with full output', which expects no errors, but sometimes gets a 404 on the favicon of example.com (because they have not favicon). It doesn't always fail, because the request for a favicon happens asynchronously.