-
Notifications
You must be signed in to change notification settings - Fork 9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: wait for fonts before pdf printing #12175
Conversation
d3d1edd
to
5932a9f
Compare
5932a9f
to
0de168f
Compare
Hi @OrKoN. I wonder if we should actually get this added to the WebDriver specifications. It sounds like an important thing to do. |
@whimboo perhaps but it is easy to implement on the client side. I decided to enable this by default to learn if there are use cases where waiting for fonts is not desired. It could inform our decision as to if this needs to be optional. |
Sounds good. In case it would make things more stable please inform us or as usual file an issue for BiDi yourself. Thanks! |
Hi, could you write what is the command exactly, Thanks |
This change introduced a bug for our use-case. We had intermittent requests that failed with timeout. It seems that when reusing pages (with multiple While investigating, I tried to debug without My workaround is to close the page after each PDF generation instead of re-using pages. I'm not sure if this is a bug on Chrome side or on Puppeteer side. Do you think that waiting for |
@gnuletik could you provide a minimal executable example that demonstrates the problem? Generally, the browser resolves |
@OrKoN Thanks for the feedback! You can run it with
You can switch the lines in comment in order to close / reopen the tabs, which makes the script complete: While building it, I realized that the issue only occurs when rendering a page with:
as you can see here: https://github.com/gnuletik/puppeteer-repro-12175/blob/main/public/index.html I also gave
Thanks! |
@gnuletik thanks, I see what is happening, so indeed it looks like tabs are being throttled because all PDFs are being requested at the same time and only one page can active at the same time. Would you mind filing a new issue for this? I also wonder if the fonts are actually loaded in the previous versions of Puppeteer? i.e., is it only the fonts.ready timing out or if the fonts are altogether not loading. |
A few workarounds:
We could roll back the behavior of waiting for fonts or make it optional but I think the issue is probably that with this usage pattern some PDFs would not have the fonts loaded (although the timeouts would go away). |
Having a mutex would make sure the page is active when PDF is being generated:
Obviously, this cannot run in parallel. So the other workaround for using headless shell would be recommended to achieve parallelism. |
Shorter example to reproduce:
|
@gnuletik interesting is that I am not able to reproduce on Linux but on Mac it happens consistently. Edit: the full example also reproduces on Linux. |
Thanks for digging into the issue @OrKoN! Yes the full example happens consistently on Linux on my side. I did not see a visual issue with the previous version, but that's hard to prove that it can never happen. I'd be happy to create an issue but the Issue template is expecting a single JS file without external dependencies. So I guess that if I don't respect it, the issue will get closed. |
@OrKoN I have digged a bit deeper in the code and basically the ready promise is resolved when layout happens in Chrome and since the page is inactive there is no layout/animation frames etc. I am not sure yet how it is all connected with the svg document. I am not sure if we can go to the previous behavior since other users have the issue of fonts not being loaded for PDF and at the same time I am not sure if it is possible to change the browser behavior (although fonts.ready seems to be under-specified w3c/csswg-drafts#4248). I think the recommendation would be to activate the page before interacting with it (like a user would do) or use the headless: 'shell' where replicating the behavior of the browser w.r.t to the activation/focus/page visibility is not desired. |
Cool finding for the ready promise trigger condition!
Do you mean using
|
yes, |
This PR adds a command to always wait for the web fonts readiness before generating a PDF.
Closes #3183