[Bug]: await browser.pages() hanging when used with remote connection (puppeteer.connect) #11640
Comments
|
The issue has been labeled as confirmed by the automatic analyser. |
|
What is the remote browser version? |
|
I am unable to reproduce with the version matching the version supported by Puppeteer. |
|
Google Chrome Version 120.0.6099.199 |
|
Although we do not support that version with Puppeteer yet, think it should work. Could you reproduce it by launching the browser with the fresh profile? Could you provide a CDP log by running the script that connects to the browser with the env var |
|
same problem here. chrome.exe is started by the following command line let browser = await puppeteer.connect({
browserURL: 'http://127.0.0.1:9290',
defaultViewport: null,
protocolTimeout: 5000
})
await browser.pages() // throws "ProtocolError: Network.enable timed out."" after 5 secondserror logversion & env"puppeteer-core": "^21.10.0", windows 11 23h2 (22631.3007) chrome 121.0.6167.140 |
|
I then closed some tabs, restarted chrome, and tried again, and the problem disappeared. |
|
Same issue here. I need to reuse a chromium instance already opened and browser.pages() doesn't resolve. |
|
The issue was not reproducible. If you see it, you are likely using a not compatible Chrome version or some of the pages are blocked by alert dialogs (there is an issue for that). |
|
Same issue here. puppeteer 22.10.0 |
|
Same issue puppeteer core 22.11.2 |
|
I am also experiencing this. The bug does go away when all Chrome instances are closed and reopened, as @ShenHongFei stated. I have found a way to reproduce this issue. I was applying to some jobs on Indeed.com and I noticed that after submitting an application, Puppeteer would hang when you tried to await either Some important notes about applying to jobs on Indeed: The submission page for the job application process states that it is "Protected by reCAPTCHA" and the submit button can only be clicked after the CloudFlare turnstile captcha has verified that you are human. Visiting this page and having the captcha successfully verify that you are human seems to cause I believe the issue is caused by whatever reCAPTCHA / CloudFlare turnstile does to the browser. |
|
I am able to reliably reproduce the error from original issue using a docker image & pdf rendering on an Alpine 3.20, but not on debian. Here's my Dockerfile: FROM alpine:3.20
WORKDIR /root
RUN apk add chromium npm
RUN npm install puppeteer
COPY <<EOF /root/input.html
<p>Hello, world!</p>
EOF
COPY <<EOF /root/script.js
const puppeteer = require('puppeteer')
async function printPDF() {
const browser = await puppeteer.launch({
headless: true,
args: [
"--no-sandbox",
"--single-process",
"--no-zygote",
"--disable-gpu"
],
});
const page = await browser.newPage();
await page.goto('file:///root/input.html', {waitUntil: 'networkidle0'});
const pdf = await page.pdf({ path: "/root/output.pdf", format: 'A4' });
await browser.close();
return pdf
}
printPDF()
EOF
ENV PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromiumThen: sudo docker build --tag docker-chromium-issue .
sudo docker run -it --rm docker-chromium-issue node /root/script.jsThe While the command is running, I observe unusually high CPU usage by chromium process. Updating the Dockerfile to be debian-based fixes the issue: diff --git a/Dockerfile b/Dockerfile
index f025886..f706b48 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -1,8 +1,8 @@
-FROM alpine:3.20
+FROM debian:12
WORKDIR /root
-RUN apk add chromium npm
+RUN apt update; apt install chromium npm --yes
RUN npm install puppeteer |
|
In my case I was just able to resolve the issue with Alpine image byremoving |
This flag is causing Puppeteer to hang on recent Alpine / Chromium, see: puppeteer/puppeteer#11640 (comment) puppeteer/puppeteer#11640 (comment)
|
We just started seeing this exact error today, but only on EC2 instances in AWS. We have a dockerized API server that's pulling in some assets from an S3 bucket. I've verified that a curl command DOES work, so it's not a network problem. And I've verified that the EC2 instance AND the docker container on that instance can see the stuff on the S3 bucket. This has been working for years, and just started throwing this error and not producing the expected PDF files last night. We are not using --single-process, so that wasn't a fix for us. We ARE in the Alpine docker container, but I don't have a good way to test switching to Debian as this app is very extensive. I see this issue is closed, but we are still experiencing it, but again, not on local development environments, only on the test/stage/prod environments we have in AWS. Any ideas?? We've tried so many things, even going back to the previous sprint release of our own code and database, which DID work as of yesterday, but today, no dice. Any help is appreciate. |
Additional context: We've narrowed it down to the newPage() method being what's hanging, so we haven't even tried to load our content when it hangs. Here's the code, just in case: |
|
We also faced this issue today. Our code is very similar to yours, setting up HTML and generating PDFs. We are also using the Alpine Node image. We deployed a new Docker image today, which caused this issue, while the Docker image we deployed 10 days ago was working fine. Comparing the two images, we found that both use Alpine v3.20, but the version of Chromium in the community repository changed from chromium-126.0.6478.182-r0 to chromium-127.0.6533.72-r0. (You can see the related history at https://git.alpinelinux.org/aports/log/?h=3.20-stable&qt=grep&q=chromium) We suspect that the change in the Chromium binary is causing this issue. We are planning to extract the APK file from the old Docker image and test it. Since we don't have much experience with APK packages, we are facing difficulties with offline installation due to the dependencies of chromium. I think you might want to try this approach as well. If this resolves the issue, it could indicate that the Chromium update in Alpine v3.20 is faulty. |
|
Note that technically Alpine Linux is not supported by Chrome (for Testing) which we provide with Puppeteer: https://support.google.com/chrome/a/answer/7100626?hl=en You would need |
|
By the time yesterday ended, Puppeteer was causing this network.enable error every 1-3 minutes, restarting NodeJS, with NOTHING calling it, just trying to load the project. Last night was a nightmare retrofitting and removing a bunch of stuff temporarily. We've had so many of these difficult-to-find-and-resolve issues over the past 6 months with Puppeteer that we've decided to just scrap it and go a different direction. I'm sure it has it's uses in other situations, but for us we just can't tolerate being dependent on something that feels so flaky to our process and that has so few options for real debugging with how we are using it, when everything else is "owned" by us and is stable. Cheers, all. |
|
Confirmed this is happening with current Alpine release Downgrading from Alpine 3.20 to 3.19 fixed the issue. |
|
We have seen success in preventing this on alpine 3.20 by adding a (async () => {
const puppeteer = require("puppeteer");
// Launch the browser and open a new blank page
const browser = await puppeteer.launch({args:['--no-sandbox']});
const page = await browser.newPage();
const version = await page.browser().version();
console.log("page browser version: " + version);
await page.goto('https://bbc.co.uk/news');
console.log("Page title: " + await page.title());
await browser.close();
})();Will time out and fail with Whereas, adding the flag, e.g. (async () => {
const puppeteer = require("puppeteer");
// Launch the browser and open a new blank page
const browser = await puppeteer.launch({args:['--no-sandbox --disable-gpu']});
const page = await browser.newPage();
const version = await page.browser().version();
console.log("page browser version: " + version);
await page.goto('https://bbc.co.uk/news');
console.log("Page title: " + await page.title());
const element = await page.waitForSelector('h1')
let value = await element.evaluate(el => el.textContent)
console.log('h1 = ' + value);
await browser.close();
})();Outputs the expected results, we are currently assuming that chromium updated something GPU related in 127+ but are too busy trying test the fix! |
|
related issue from alpine aports |
Thanks for mentioning this workaround. While locally and with kvm there were no problems with chrome 127.x (Ubuntu based), k8s pods did show this error (debian based image) - "disable-gpu" did help here too. |
|
Same issue here. |
This change updates the dependency versions of: - debian-bookworm - pandoc - pandoc-crossref - puppeteer - imgur - mermaid-filter - typescript - drawio It also resolves an issue seen running on newer Chromium browsers (>126 or so) where the browser hangs. See puppeteer/puppeteer#11640 for more information about this issue. Because of the update to pandoc 3.2.1, this change also updates the TCG LaTeX template to provide the new required `\pandocbounded` macro. It doesn't appear to have any actual effect for images in docs.
This change updates the dependency versions of: - debian-bookworm - pandoc - pandoc-crossref - puppeteer - imgur - mermaid-filter - typescript - drawio It also resolves an issue seen running on newer Chromium browsers (>126 or so) where the browser hangs. See puppeteer/puppeteer#11640 for more information about this issue. Because of the update to pandoc 3.2.1, this change also updates the TCG LaTeX template to provide the new required `\pandocbounded` macro. It doesn't appear to have any actual effect for images in docs.
|
Same here, Any thoughts? |
|
The fix that @CeeBeeUK suggested fixed my issue. At the time of writing this my Dockerfile uses Adding const browser = await puppeteer.launch({
args: ['--no-sandbox', '--disable-setuid-sandbox', '--disable-gpu'],
}); |
|
In my case (Ruby on Rails project) the solution was to add an extra worker to puma in combination with Puma was running with one worker and when chromium made a request to get assets (like stylesheet) it would not be capable of delivering it. Because the main thread was blocked with Pupetteer itself. Adding a new worker to serve assets / handle other processes/requests, made it work.
|
|
For me this was caused by sleeping tabs. Sleeping tabs didn't cause problems in the past but now they do apparently. |
Minimal, reproducible example
Error string
no error
Background
Launch chrome with --remote-debugging-port=9222
On Mac:
OTHER PEOPLE ARE EXPERIENCING THIS ISSUE:
https://stackoverflow.com/questions/77540484/browser-pages-does-not-resolve-in-puppeteer-script
Expectation
Return the pages array for all browser contexts.
However, I also attempted doing it only for
browser.defaultBrowserContext(), but it was the same bug in that case.Reality
Hanging, stuck, no error messages.
browser.pages()works when usingpuppeteer.launch()Puppeteer version
21.7.0
Node version
21.5.0
Package manager
npm
Package manager version
10.2.5
Operating system
macOS
The text was updated successfully, but these errors were encountered: