Closed wioux closed 6 years ago
I'll try to dig deeper into this issue. IMO your change shouldn't change anything. Do you tried to use different chrome versions?
I have a similar problem on Chrome 64/Alpine Linux running on a different machine, but I see there was another issue with that version of (#22) so maybe it's not the same thing.
Right now we can reproduce it pretty readily (~50% of the time) on Ubuntu 16.04/Chrome 65 with the following steps on master:
$ yarn run build
yarn run v1.6.0
$ babel index.js cli/chrome-headless-render-pdf.js --presets env --plugins transform-runtime --out-dir dist/
index.js -> dist/index.js
cli/chrome-headless-render-pdf.js -> dist/cli/chrome-headless-render-pdf.js
Done in 0.98s.
$ cat test.html
<html>
<body>
<h1>hello world</h1>
</body>
</html>
$ node dist/cli/chrome-headless-render-pdf.js --url=file://$(pwd)/test.html --pdf test.pdf
Using chromium-browser
Waiting for chrome to became available
Connected!
Connected to HeadlessChrome/65.0.3325.181, protocol 1.2
Opening file:///home/peter/Projects/chrome-headless-render-pdf/test.html
[ ... hangs ...]
I created a Dockerfile[1] which can reproduce the issue on both linux and macs, in case that helps.
[1] https://gist.github.com/wioux/dd0869e26c6140ef09b25375bcc93fa5
Thanks, I found the issue:
Page.navigate
starts rendering page, but promise for loadEventFired
is created after that.
For very simple pages, this is enough time to miss that event in meantime.
But there is no need to start counting budget after load event.
I ran your docker in loop with that fix, and it looks like it is resolved now.
Thanks for your effort!
Running 65.0.3325.181 on Ubuntu, the cli sometimes hangs when rendering even trivial documents like this:
It appears to be due to the virtual time budget / jsDone callback steps -- I can fix my issue by removing the related lines:
Perhaps there could be an option like
--wait-for-networking=false
to disable this behavior? It seems this feature of the debugging protocol is still experimental.[1] I'd be happy to submit a PR if that seems like a good option.edit: The issue also goes away completely if I move the
setVirtualTimePolicy
call to after thePage.loadEventFired
event, as in this diff. I'm going to open a PR for this rather than add another CLI option.[1] https://chromedevtools.github.io/devtools-protocol/tot/Emulation/#method-setVirtualTimePolicy