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
[Bug]: page.goto hangs on aborted client side redirect #9175
Comments
Thanks for the detailed repro! it looks like we did regress here while fixing the navigation flakiness. I guess the navigation response is never received because it's aborted so we don't resolve the lifecycle watched. |
Hi @mkacmar , I thought I had the exact same problem on version 17.1.3 and this issue brings me to update the version to 19.2.0 and now I can not reproduce anymore, even with version 1.6.1.1 😒 Can you please try following ? const puppeteer = require('puppeteer');
(async () => {
const url = 'http://localhost/test2/test.html'; // your page with the redirect
const browser = await puppeteer.launch({ headless: true });
const page = await browser.newPage();
await page.setRequestInterception(true);
page.on('request', (request) => {
if (
request.isNavigationRequest() &&
request.frame() === page.mainFrame() &&
request.url() !== url
) {
request.abort('aborted');
} else {
request.continue();
}
});
await page.goto(url, {
timeout: 6666,
waitUntil: ['domcontentloaded', 'networkidle0'],
});
await page.close();
await browser.close();
})(); It seems |
Hello @gRoussac, it doesn't seem like that's the case on my side unfortunately (I've tried 2580347 and v19.2.0) - |
@mkacmar very weird, did you see I also changed your if statements ? I uploaded my files here https://github.com/gRoussac/puppeteer-puppeteer-issues-9175 |
#8768 fixes flakiness in handling navigations but it didn't account for the fact that subsequent navigation requests could be aborted via the request interception. In that case, the navigationResponseReceived promise would never be resolved. This PR adds a listener for the failed network requests and resolves the promise if the network request has failed. Adding test coverage for this seems tricky, as the reproduction depends on timing of the second navigation request. Closes #9175
🤖 I have created a release *beep* *boop* --- <details><summary>puppeteer: 19.2.1</summary> ### Dependencies * The following workspace dependencies were updated * dependencies * puppeteer-core bumped from 19.2.0 to ^19.2.1 </details> <details><summary>puppeteer-core: 19.2.1</summary> ## [19.2.1](puppeteer-core-v19.2.0...puppeteer-core-v19.2.1) (2022-10-28) ### Bug Fixes * resolve navigation requests when request fails ([#9178](#9178)) ([c11297b](c11297b)), closes [#9175](#9175) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: release-please[bot] <55107282+release-please[bot]@users.noreply.github.com>
Bug description
Steps to reproduce the problem:
Minimal reproducible example (uses the recommended approach from #823 (comment)):
The issue starts to appear with v16.1.1, it works as expected with v16.1.0 - I can reproduce the issue on most recent version - (19.2.0 at the time of writing).
I've tracked the issue to commit 2580347 - I've attached the log output from this commit.
Let me know if I can provide more details or if there's a different recommended approach to stop client side redirects.
Puppeteer version
16.1.1
Node.js version
16.14.0
npm version
8.3.1
What operating system are you seeing the problem on?
Linux
Relevant log output
The text was updated successfully, but these errors were encountered: