puppeteer: page.goto returns null periodically
Steps to reproduce
Similar/same as: #1391
Tell us about your environment:
- Puppeteer version: 1.3.0
- Platform / OS version: Mac
- URLs (if applicable): https://www.microsoft.com/en-gb/store/d/xbox-one-s-1tb-console-playerunknowns-battlegrounds-bundle/908z9jn5cnh2/gz4w?cid=msft_web_collection
- Node.js version: 9.11.1
What steps will reproduce the problem?
const browser = await puppeteer.launch();
const page = await browser.newPage();
for (var i = 0; i < 15; i++) {
const r = await page.goto('https://www.microsoft.com/en-gb/store/d/xbox-one-s-1tb-console-playerunknowns-battlegrounds-bundle/908z9jn5cnh2/gz4w?cid=msft_web_collection', { waitUntil: 'domcontentloaded' });
console.log(r.ok());
}
await browser.close();
What is the expected result?
true
outputted 15 times
What happens instead?
Sometimes true
15 times, sometimes TypeError: Cannot read property 'ok' of null
It works as expected on 1.2.0, but fails on 1.3.0
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 28 (7 by maintainers)
Commits related to this issue
- bugfix: tool crashes sometimes when page response is empty UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'request' of null at /opt/inspection/website-evidence-collector/webs... — committed to EU-EDPS/website-evidence-collector by rriemann 4 years ago
- Added fix to intermittent null return in page.goto call https://github.com/puppeteer/puppeteer/issues/2479#issuecomment-646839471 — committed to framirezsandino/headless-chrome-crawler by deleted user 3 years ago
- Added fix to intermittent null return in page.goto call https://github.com/puppeteer/puppeteer/issues/2479#issuecomment-646839471 — committed to framirezsandino/headless-chrome-crawler by deleted user 3 years ago
- Workaround for [puppeteer/puppeteer#2479] — committed to garzj/d4sd by garzj 2 years ago
Here’s a bit of a workaround until this is fixed:
This will return the first response you’re getting once interception starts. This will NOT return the intial request you’re actually looking. So if you actually need that request, you’re out of luck unless you use an incognito tab.
Yep, I can confirm this works on 1.8.0!
Actually, regarding my above example of reproducing it. If you comment out the first request (or second, doesn’t matter) so it looks like this:
Then it works.
So, pretty sure the
response
becomesnull
if the URL has been requested before and contains an anchor part.FWIW, If you could have an issue due to service workers, over at playwright they have the ability to block the service worker registration (but maybe the real issue is that page.goto still returns the wrong ‘frame’)
https://github.com/microsoft/playwright/pull/14321/files#diff-5e6d61431da6c4bb6fda4276ba5781ae64e98537d9f68c9c51a465e1fcb4c6c2R125
ah yes… I can confirm it’s working thanks! 😄
It seems this problem has something todo with caching. When I create a createIncognitoBrowserContext for every request. This never happens. Since I removed that extra context. This Problem happened also to me. So my guess is that now the second request is fullfilled via cache and so there is no response. This is also why the chromePage.waitForResponse(() => true); works. Since it waits for the cache refresh request.
@jtara1 that sounds unlikely, for me it happens everytime that a page has a redirection initiated by javascript after the event
domcontentloaded
is triggered@aslushnikov Hi, sorry, it was my fault, the problem was the ssl certificates and chromium is killing the request.
@bluepeter that workaround works for me, thanks a lot