[BUG] Error: NS_ERROR_CONNECTION_REFUSED while navigating to http://localhost:8000

[sylvesteraswin]

Context:

• Playwright Version: 1.0.2
• Operating System: Mac
• Node version: v12.16.1
• Browser: Firefix
• Extra: localhost:8000

Code Snippet

Help us help you! Put down a short code snippet that illustrates your bug and
that we can run and debug locally. For example:

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

(async () => {
  const browser = await instance.launch({
const browser = await instance.launch({
    headless: false
  });
  await browser.newContext(context);
  const page = await browser.newPage();

  await page.goto(`${BASE_URL}${slug}`, {
    waitUntil: "domcontentloaded"
  });
  await page.waitForSelector(".test-container", {
    state: "attached"
  });
  await page.screenshot({
    path: path.join(screenshotPath, name)
  });
  await browser.close();
})();

Describe the bug
When I try to open a localhost url in firefox I always get Error: NS_ERROR_CONNECTION_REFUSED while navigating to http://localhost:8000.

I am running webkit and chromium in the same process and it works as expected.
Add any other details about the problem here.

[arjunattam]

Thanks for reporting @sylvesteraswin. I was able to repro this on firefo – but only when there's nothing running on localhost:8000. If I run something on localhost:8000, it works for me. Could there be something different about your network configuration?

[shirshak55]

Yea it was issue on windows so I had to switch to chromium lol last week.

[sylvesteraswin]

@arjun27, sorry for the late reply. I kinda found the root cause.

These are the issues I faced.

Dev env

gatsby dev

Chromium

Everything seem to be good

Webkit

The socket.io connection never return a 200 when calling from playwright and I get a rejection after waiting for the timeout (default: 30s)

Firefox

The initial load of the browser is always NS_ERROR_CONNECTION_REFUSED, but when I refresh manually this works.

Prod setup

ngnix static HTML

All browsers seem to work as expected and I don't get any errors.

---

So I am guessing either there is some issue with gatsby or socket connection.

[pavelfeldman]

Looks like the issue was not on the Playwright side, so closing. @sylvesteraswin, did I understand this right?

[shirshak55]

@pavelfeldman like 1 month ago there was a issue when we open any link using juggler it would close the browser and throw error like NS_ERROR_CONNECTION_REFUSED. The strange thing is I made in osx and it was working fine but when i ported to windows pc it started showing this. And I had to change it to chromium which worked fine.

I do think this issue is fixed already. so we can close issue and if they are still having issue can reopen?

[gokhantaskan]

I'm using Windows 11 Pro 22H2.

I got the error for the first run:

Running 7 tests using 7 workers

  ✓  1 [Chrome] › home.spec.ts:7:1 › title (6.1s)
  ✓  2 [Microsoft Edge] › home.spec.ts:7:1 › title (7.0s)
  ✘  3 [Firefox] › home.spec.ts:7:1 › title (4.8s)
  ✓  4 [Safari] › home.spec.ts:7:1 › title (5.5s)
  ✓  5 [iPad (gen 6)] › home.spec.ts:7:1 › title (5.5s)
  ✓  6 [Mobile Safari] › home.spec.ts:7:1 › title (5.4s)
  ✓  7 [Mobile Chrome] › home.spec.ts:7:1 › title (4.2s)


  1) [Firefox] › home.spec.ts:7:1 › title ──────────────────────────────────────────────────────────

    Error: page.goto: NS_ERROR_CONNECTION_REFUSED
    =========================== logs ===========================
    navigating to "http://localhost:3030/", waiting until "load"
    ============================================================

      2 |
      3 | test.beforeEach(async ({ page }) => {
    > 4 |   await page.goto("/");
        |              ^
      5 | });
      6 |
      7 | test("title", async ({ page }) => {

        at C:\...\tests\e2e\home.spec.ts:4:14

  1 failed
    [Firefox] › home.spec.ts:7:1 › title ───────────────────────────────────────────────────────────
  6 passed (11.1s)

This is the second run:

Running 7 tests using 7 workers

  ✓  1 [Chrome] › home.spec.ts:7:1 › title (7.0s)
  ✓  2 [Microsoft Edge] › home.spec.ts:7:1 › title (7.3s)
  ✓  3 [Firefox] › home.spec.ts:7:1 › title (6.3s)
  ✓  4 [iPad (gen 6)] › home.spec.ts:7:1 › title (6.3s)
  ✓  5 [Mobile Chrome] › home.spec.ts:7:1 › title (5.0s)
  ✓  6 [Safari] › home.spec.ts:7:1 › title (6.4s)
  ✓  7 [Mobile Safari] › home.spec.ts:7:1 › title (6.2s)

  7 passed (12.1s)

[RomarioNijimAlmond]

@gokhantaskan how did you solve it?

[ai-trivera]

I am also getting the same problem on Windows/Firefox. Rerunning the test cases doesn't seem to solve the issue.

[RulixConception]

Same issue on Windows + Firefox for component tests. I was unable to find a fix so I had to remove Firefox from my tests 😞

[yeugeneu]

I noticed if you turn off headless mode, run in debug mode and break at the page.goto line. Stepping through the goto command to ensure the page is loaded. Then the following executions will work.

[MikaKarjunen]

Same issue on Windows + Firefox for component tests. I was unable to find a fix so I had to remove Firefox from my tests 😞

What I did was reduced the parallel test workers from default to 5. That did the trick.

[alamenai]

Same issue on Windows + Firefox for component tests. I was unable to find a fix so I had to remove Firefox from my tests 😞

What I did was reduced the parallel test workers from default to 5. That did the trick.

But Why?

[MikaKarjunen]

Same issue on Windows + Firefox for component tests. I was unable to find a fix so I had to remove Firefox from my tests 😞

What I did was reduced the parallel test workers from default to 5. That did the trick.

But Why?

Hey. Sorry for including my reasoning behind that, and it's good that you asked about it. So kudos to you buddy!

While dealing with this issue, I noticed that my development machine was struggling with performance. My hypothesis was that it was under so much stress that I couldn’t serve the tests quickly enough before the testing platform timed out. After reducing the number of parallel workers, the issue disappeared, so there seems to be some truth to that.