[BUG] page.goto: Timeout XXXms exceeded. No load or domcontentloaded event fired

[soloyal]

Context:

• Playwright Version: 1.19.1
• Operating System: Mac
• Node.js version: 16.11.1
• Browser: Firefox
• Extra:
• executablePath: '/Users/navin/Library/Caches/ms-playwright/firefox-1316/firefox/Nightly.app/Contents/MacOS/firefox',
  headless: false,
  args: [
  '--width=1280',
  '--height=720',
  ],

const { firefox } = require('playwright');

(async () => {
  const browser = await firefox.launch({
    headless: false,
    args: [
      '--width=1280',
      '--height=720',
    ],
  });
  const context = await browser.newContext();
  const page = await context.newPage();
  page.setDefaultTimeout(60000);
  // fire async navigation
  await page.goto('https://www.nike.com/', {
    waitUntil: 'load',
  });
  console.log('Done')
  await page.close()
  await browser.close()  
})();

Script opens the nike.com url but stuck on goto. No additional requests in the devtool. Visually it stopes the loading, web site looks correct (with all css/js), but got never finishes

DEBUG=pw:api node index.js
 pw:api => browserType.launch started +0ms
  pw:api <= browserType.launch succeeded +4s
  pw:api => browser.newContext started +1ms
  pw:api <= browser.newContext succeeded +23ms
  pw:api => browserContext.newPage started +1ms
  pw:api   navigated to "about:blank" +619ms
  pw:api   navigated to "about:blank" +38ms
  pw:api <= browserContext.newPage succeeded +6ms
  pw:api => page.goto started +1ms
  pw:api navigating to "https://www.nike.com/", waiting until "load" +6ms
  pw:api   "commit" event fired +862ms
  pw:api   navigated to "https://www.nike.com/il/" +0ms
  pw:api   "commit" event fired +2s
  pw:api   navigated to "https://unite.nike.com/session.html?appVersion=912&experienceVersion=912" +0ms
  pw:api   "commit" event fired +107ms
  pw:api   navigated to "https://api.nike.com/149e9513-01fa-4fb0-aad4-566afd725d1b/2d206a39-8ed7-437e-a3be-862e0f06eea3/fp" +0ms
  pw:api   "commit" event fired +23ms
  pw:api   navigated to "https://unite.nike.com/149e9513-01fa-4fb0-aad4-566afd725d1b/2d206a39-8ed7-437e-a3be-862e0f06eea3/fp" +1ms
  pw:api   "commit" event fired +5s
  pw:api   navigated to "https://www.googletagmanager.com/ns.html?id=GTM-NTF2X45" +0ms
  pw:api   "commit" event fired +828ms
  pw:api   navigated to "about:blank" +0ms

  pw:api   "commit" event fired +17ms
  pw:api   navigated to "about:blank" +1ms

  pw:api   "commit" event fired +51ms
  pw:api   navigated to "https://bid.g.doubleclick.net/xbbe/pixel?d=KAE" +0ms
  pw:api   "commit" event fired +29ms
  pw:api   navigated to "https://tr.snapchat.com/cm/i?pid=20634084-7fa1-4691-8aec-fefe00263e00" +0ms
  pw:api   "commit" event fired +406ms
  pw:api   navigated to "https://www.pinterest.com/ct.html" +0ms
  pw:api <= page.goto failed +49s
node:internal/process/promises:246
          triggerUncaughtException(err, true /* fromPromise */);
          ^

page.goto: Timeout 60000ms exceeded.
=========================== logs ===========================
navigating to "https://www.nike.com/", waiting until "load"
============================================================
    at /Users/navin/Downloads/goto/index.js:19:14 {
  name: 'TimeoutError'
}

same behavior for waitUntill: domcontentloaded or any other

[dgozman]

I can repro, and only in Firefox.

[soloyal]

Ok, but how to solve it?

[krutoo]

same problem

[pepehandsjpg]

i'm also having the same problem (firefox)

[dgattey]

I'm also getting this on Webkit + Firefox. Here's a run that exhibited this problem: https://github.com/shopcanal/e2e-tests/runs/5682749027?check_suite_focus=true

  pw:api <= browserContext.clearCookies succeeded +1ms
  pw:api => page.goto started +1ms
  pw:api navigating to "https://develop.shopcanal.com/login", waiting until "load" +1ms
  pw:api   "commit" event fired +219ms
  pw:api   navigated to "https://develop.shopcanal.com/login" +0ms
  pw:api   navigated to "https://develop.shopcanal.com/login" +329ms
  pw:api   navigated to "https://develop.shopcanal.com/login" +193ms
  pw:api   "domcontentloaded" event fired +21ms
  pw:api => browserContext.close started +59s
  pw:api <= page.goto failed +8ms
  pw:api <= browserContext.close succeeded +1ms

[tillschander]

I have the same problem with Chromium on Ubuntu. So it's not just a Firefox only issue.

Every time i run my tests one or two of them might fail randomly with the same waiting until load error:

page.waitForNavigation: Navigation failed because page was closed!
=========================== logs ===========================
waiting for navigation until "load"
============================================================

page.goto: Navigation failed because page was closed!
=========================== logs ===========================
navigating to "http://localhost:3000/some/url", waiting until "load"
============================================================

The corresponding code is nothing fancy. Here are some examples:

await Promise.all([
    page.waitForNavigation({ url: 'login' }),
    page.goto('login')
]);

await page.goto('search');
await expect(page.locator('h1')).toContainText('Search');
await page.goto('product/123456');
await expect(page.locator('h1')).toContainText('Product Title');

[liuxingbaoyu]

Fixed in #13340

[zhanglei4333]

Hello, is this problem solved now? Can I download the latest package to solve this problem, or modify my case according to the method of Liuxing Baoyu

[jatin-karla11]

@tillschander we are also facing this issue on our Jenkins pipeline jobs, and again this is totally random any test gets error at any time, out of 50 test cases 2-3 fails due to this (2 workers), and if I increase the number of workers gradually then this count keeps increasing. (in all browsers). But if we run tests in local everything works fine.
Any solution for this issue as this is impacting our daily automation build results. @zhanglei4333 @liuxingbaoyu @aslushnikov

[ajayEngProd]

Hello , we are also facing the same issue with timeouts happening randomly. We are running close to 60k tests across multiple machines in 20 minutes. This problem happens when tests run in a pipeline and not when they are running in local.

OS: windows
playwright version : 1.13.0
Dot net version : 5 and 6

any help in this regard will be very useful @zhanglei4333 @liuxingbaoyu @tillschander .

[daddyman]

We are getting the same behavior of random failures. We have ~1500 tests that run on a single worker. We are running under Jenkins using the Docker image.

What we see is one or two tests on almost every test run fail with a message similar to:

Timeout of 60000ms exceeded.

page.waitForNavigation: Navigation failed because page was closed!
=========================== logs ===========================
waiting for navigation until "load"
  navigated to "[http://172.24.142.157/designer/"](http://172.24.142.157/designer/)
============================================================

It is at the point where the test navigates to a page and does waitForNavigation.

• This happens on different pages during any given run
• We haven't seen it happening when running locally
• We tried different waitUntil values (networkidle, load, etc) but it still happens
• We are using the Promise.all pattern to navigate. when we navigate with a button click or similar action.
• It happens in Chrome but seems to happen more in Firefox.
• The application is an Angular app

I don't have a repro because of the random nature of the failures and it doesn't happen on the same page each time.

[sahil1610]

Hello,

I am also getting a similar issue with https://app.vwo.com on Chromium, Firefox and Webkit. Post the login, the URL is not getting redirected to the Dashboard and in the network panel, there is no call after the post Login call which gives 200.

Steps:

1. Land on https://app.vwo.com
2. Enter the Username and password and wait for redirection to dashboard page. (For username and password, you can simply create a free trial account on https://vwo.com.

Environment:

1. MacOS
2. Playwright Version 1.22
3. Browser - Chromium, Firefox and Webkit
4. Language binding - Javascript+Typescript

On Chromium, Firefox, and Safari the issue is intermediate, while on the local selenium 4 grid it's consistent.

[daddyman]

I turned on DEBUG=pw:api and the failure happens much less often but it did happen a couple of times. Both times while clicking a button to navigate to a new page (using Promise.all with page.waitForNavigation) a silent refresh of the access token occurred . Could this have something to do with the failure?

The attached file has the log output from the test that failed. Near the bottom is a comment "FAILURE STARTS HERE". The page.waitForNavigation doesn't complete. In another run where this test succeeds, without the token refresh in the middle, there is an extra log line mentioned in the file that says the page.waitForNavigation succeeded.

silent-refresh.txt

[daddyman]

I changed by tests to use DEBUG=pw:channel* and caught a test that succeeded once and failed once. In that test there is a page already loaded with a list page when the test starts. During the test:

• The Add button is clicked to navigate to the create page
• Wait for the create page to load
• Verify the header text and breadcrumb text on the create page
• Click the cancel button on the create page to navigate back to the list page

In the failure case while the breadcrumb text is being verified the refresh token timer fires and the token renewal process starts (same as the previous test I posted about). This seems to cause problems in the last step of navigating back to the list page.

These two files are a successful run of the test and the failed run of the test. I commented the progress of the text.
mappingdata-fail.txt
mappingdata-success.txt

Edit: This is on playwright 1.22.2 running headless under Docker with Jenkins and running under Chromuium.

[daddyman]

I opened a new issue specific to my case #15084 (a token refresh occurring during a test would add and remove an iframe which caused problems in playwright).

There is a pull request #15812 that fixed my problem when I manually applied it.

[KayakinCoder]

We were experiencing the same problem, only in our CI pipelines (tests working locally, failing randomly in pipelines). The following in our playwright config has seemed to fix the problem for us:

// limit the number of workers running. start with 1, and if your tests pass reliably, consider increasing to
// speed up runs. the new % option may be a good choice, e.g.  workers: '50%'
workers: 1,

use: {
    // set this to a large number, to account for pages occasionally loading more slowly in your pipeline
    // than they do locally
    actionTimeout: 12000,

Based on the comments above and our experience, my thought is that the vm that's running our tests in ci pipeline just gets a bit overwhelmed in terms of resources. Tons of workers spawning new tests, all running at once, and one just hangs up a bit because ram and cpu are scarce.

An additional source of this problem could be the fact locally, we're running tests on localhost; in our pipeline, we're running tests on a real staging website. Websites are fickle, and pages can sometimes load slowly. Increasing the actionTimeout may help with that.

If you're still getting failures, you could consider allowing retries. In an ideal world, tests that should pass would pass 100% of the time. In the real world, even if you're running your webapp within a container in your ci pipeline and testing against that (rather than running your tests against a real website), sometimes a page just doesn't load correctly.

retries: 1

[ChristianUlbrich]

Just to chime in a little bit on adding some insights, why your tests might fail on CI and seem to be flaky (or blaming Playwright for that matter) - for us, we are using pure ESM modules and if all of your dependencies are native ESM and are optimized for tree-shaking (meaning every tiny function is exposed as ESM module), if you do not bundle anything at all, this easily amounts to crazy amounts of requests being made:

• using @popperjs/core/lib/popper-lite.js roughly amounts to 40+ requests (while only tallying ~70kB)
• using even such simple things like lodash-es/isEqual.js amounts to another 30+ requests

In our scenario, where we "just" user 5 components from our UI library, this amounts to +150 requests. Browsers limit the amount of parallel HTTP requests and if HTTPS involved, this is not going to get any faster... So what I am saying is, that even my beefy (sorry veggies!) MacBook takes roughly a second for loading. We limited the Playwright timeouts to 4s and it seems, that hosted AzureDevOps Mac OS agents have pretty bad I/O performance, read by factor 5-10 slower, so this explains for us failed timeouts, because the load event is not triggered in time, because esm modules need to be "resolved" before actual DOM processing can happen.

We might think about using bundles for our tests; but for the time being, we solved this by having a platform-dependent global timeout set for Playwright.

[lavcraft]

Same issue in chromium with fresh playwright version 1.31.2 :( Also, it's a little bit flaky

[swoopgrandchamp]

Same issue with 1.32.3, out of 7 tests, 1 random one has always this problem.

[xiaoxiaocaiiao]

playwright 1.33.0, chrome still have this issue

[dtokarczyk]

I noticed that it happens only in tests run in a docker container and only if I run a lot of tests. Interestingly Linux users do not report issues, only mac users.

[jameslporter]

Can confirm this issue is affect linux users. I was setting up a docker container and trying playwright for the first time. Insanely frustrating. Finally figured out I'm not a total moron but simply a significant regression in playwright itself. I know npx is all the rage these days but it leads to users running the latest version. I was able to get my tests working by using npx [email protected] install and then npx [email protected] test after also adjusting the package.json dep to specifically 1.43.1 version.

[kuba-orlik]

In my case updating Playwright to the latest versoin solved the issue, fyi

[LuvDeluxe]

This is still present when executed in Bitbucket CI/CD... Locally I am unable to reproduce...

[dtokarczyk]

I noticed that docker system prune --volumes sometimes solve problems

[JorensM]

I think this happens because of redirects. Does anyone experiencing this issue have redirects by any chance?

[lucien-theron]

I also have this issue using Chrome and Ubuntu (also using official container). The video shows the page freeze or hang a second after opening. This only happens on our Ubuntu env tests.

[vladide]

I have performed some tests on local vs local docker vs k8s pod

Hence recommend that those who see random TIMEOUTS (Test timeout of 30000ms exceeded) - check the resource usage

[JorensM]

This happens for me on locally on Windows btw, less often on UI mode though. Also happens in GitLab CI with Linux

[lucien-theron]

I now also get these locally on Windows but a lot more rarely

[mateuswolkmer]

What fixed it for me on Windows was setting fullyParallel to false in the PlaywrightTestConfig, so it runs one test at a time. I guess my machine isn't strong enough for the parallel tests and it load indefinitely, causing the timeout.

[sdwvit]

Stuff is way funnier here (and it will go longer if I increase the timeout for loading the page):

[jonasclaes]

I'm experiencing the same issue on v1.50.1. In my case specifically, Firefox is getting stuck after running 4 tests.

[zijian-bytedance]

for me, this happens to some url, while others are fine.

[jonasclaes]

I've experienced this issue once more, but found the root cause in my case. It was due to a Vite dev server websocket not being able to be opened. On Firefox it executes the first test without any issues, but the second test fails with the load event due to the websocket connection still waiting to be opened by the previous browser page. When I turn off the dev server completely and run it in preview mode, it does not occur. Looks like there might be some cleanup missing here in between closing a page after a test and opening a new page when a new test starts?

[Mkots]

I can also reproduce this issue.

I'm using Playwright v1.51.1 with TypeScript, running both locally and on GitHub Actions (using the official image mcr.microsoft.com/playwright:v1.51.1-noble). But still, the page sometimes just doesn't load at all — exactly as described.

To work around it, I even implemented a helper that retries "goto":
https://gist.github.com/Mkots/2e8d9bb7b1417686786d576ec3d962c9
But even with that in place, 5–7 out of 100 tests still fail occasionally.

It seems to be non-deterministic and not specific to a particular url or page (because my tests use only one url and page) — any insights or potential fixes would be much appreciated.

I tried on Chrome and Firefox, Linux Ubuntu 24.04 and MacOS 15 Sequoia. I've used different LIRs with different bandwidth (from 100Mbps to 10G) — no effect.

My best guess is that bug is somehow related to "domcontentloaded" or "load" event listener.

[gund]

This affects Chrome not just Firefox and happens quite often in CI.
Can this be prioritized please?
People expect E2E tools to not be flaky 🙏

[shanelavezzo]

This also affects webkit. Only running into this in container. Please prioritize.

[noahkaminer]

I'm also seeing this with webkit in a docker container too. Very annoying and hard to switch browser types for our use case. Please fix this soon!

This also affects webkit. Only running into this in container. Please prioritize.

[dgozman]

Hey folks, we need your help to fix this issue!

If you struggle with this, please file a new issue with reproduction steps that we can run locally - fill in the "Bug Report" template and link to this issue.

If you do not have a reproduction that we can run locally, for example it uses a non-public url, or you cannot share your code, please do not file an issue. When in doubt, please refer to the filing issues guide.

Thank you everyone!

[zaling4]

@dgozman
Hey! I can share the code that reproduces the issue, but it’s only triggered during a real login flow with a healthcare insurance portal, which requires valid credentials—so it’s not something that can be run locally without access.
That said, I’m happy to either:

• Share the code and explain how it works
• Or, if that’s not helpful without being able to run it, I can provide detailed logs and a trace from the failing run

Let me know what works best!

[PAStheLoD]

Hello,

For anyone running into this and ends up here through a search engine, it's worth a shot to enable "browser" debugging. (I also tried "api", but that did not reveal much.)

Also, I recommend simply adding --retries 2 and use.video: "on-first-retry" to get an idea of what goes wrong.

DEBUG=pw:browser ./node_modules/.bin/playwright test --project=...

(For us adding --disable-gpu --disable-software-rasterizer --mute-audio to launchOptions.args for Chromium helped to get Playwright working in a docker container in a GitLab CI runner using docker executor with "docker service", with the docker:dind-rootless image.)

[dgozman]

Closing this issue as there is no actionable repro to address. If you hit this problem, consider filing an issue with a repro as described in this comment. Thank you!