Node.js puppeteer - How to set navigation timeout?
Solution 1:
You can use timeout: 0
to disable timeout errors if you're loading a heavy page.
Use it in your page.goto
like:
await page.goto('url'+tableCell04Val, {waitUntil: 'load', timeout: 0});
You can see the PR made to Pupeteer here which added the change, along with documentation and the unit tests that implement it.
Solution 2:
UPDATE 2019
You can also change the page behaviour since V1.0.0:
await page.setDefaultNavigationTimeout(0);
The param is the timeout in milliseconds.
References: https://github.com/GoogleChrome/puppeteer/blob/master/docs/api.md#pagesetdefaultnavigationtimeouttimeout https://pptr.dev/#?product=Puppeteer&version=v1.17.0&show=api-pagesetdefaultnavigationtimeouttimeout
Solution 3:
There are two methods to handle the timeouts in Puppeteer:
a) page.setDefaultNavigationTimeout(timeoutInMiliseconds)
It affects the navigation-related functions:
• page.goBack([options])
• page.goForward([options])
• page.goto(url[, options])
• page.reload([options])
• page.setContent(html[, options])
• page.waitForNavigation([options])
b) page.setDefaultTimeout(timeoutInMiliseconds)
It affects all the previous navigation functions plus all the Waiting funtions:
• page.waitFor(selectorOrFunctionOrTimeout[, options[, ...args]])
• page.waitForFunction(pageFunction[, options[, ...args]])
• page.waitForRequest(urlOrPredicate[, options])
• page.waitForResponse(urlOrPredicate[, options])
• page.waitForSelector(selector[, options])
• page.waitForXPath(xpath[, options])
NOTE: page.setDefaultNavigationTimeout
takes priority over page.setDefaultTimeout
Solution 4:
You can set timeout like this
await page.goto('url'+tableCell04Val, {waitUntil: 'load', timeout: 10000}).then(() => {
console.log('success')
}).catch((res) => {
console.log('fails', res)
})
Solution 5:
await page.goto('url'+tableCell04Val, { waitUntil: 'networkidle2',timeout: 0});
networkidle2 comes handy for pages that do long-polling or any other side activity.
Check https://github.com/puppeteer/puppeteer/issues/1552#issuecomment-350954419