Could Playwright for .NET leave a connection to the website open?

Question

Could Playwright for .NET leave a connection to the website open?

Rod Falanga 1,116

Tonight I was in a Starbucks. I wanted to test an application I wrote using Playwright for .NET which test a website I wrote. It has worked fine in the past, when I developed the app on my Windows 11 desktop. But when I cloned the repo to my laptop at the Starbucks, then tried to run it, I got errors because I hadn't installed the browser components to test it with Playwright for .NET. I tried to resolve that but had to give it up because the Internet speed at the Starbucks is abysmal. I had to give up, but later I tried to just bring it up in the browser on my laptop, but it timed out on every Playwright for .NET test. Even just trying to open the website in the browser met with delays. However, I am now on my desktop, and I got to the website fine.

So, now I'm wondering, could Playwright for .NET leave a connection to a website open, if something should fail or like what I had to do was stop the installation of the browser components in the Playwright for .NET project?

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Hi @Rod Falanga

Short answer: no. Playwright for .NET doesn't leave a connection open on the website's side, and nothing from your laptop run would carry over to another machine.

If a run crashes or you cancel it, the browser/driver process may stay alive on that machine. It's just a local orphaned process — you can kill it or reboot and it's gone. It doesn't lock the remote site or keep a session open against it.

What likely behind the timeout is

The browser binaries weren't fully installed. Since you stopped the install partway, I'd re-run it from the project folder on a stable connection and let it finish:

pwsh bin/Debug/net8.0/playwright.ps1 install

The public Wi-Fi. Throttling and packet loss can easily push you past Playwright's default 30s navigation timeout, which also lines up with the site being slow in a normal browser.
If your BaseUrl points at localhost, the app has to be running on that machine before the tests start. If it isn't, every test will time out no matter how good the network is.

A few things I'd suggest trying

Confirm which BaseUrl your test project is using — localhost or the remote site.
Re-run the browser install on a stable connection and make sure it completes.
On the laptop, check Task Manager for leftover chrome.exe / node.exe processes after a failed run and end them.

If it still times out after that, feel free to post the exact error text here along with whether the failing URL is localhost or the remote site, and I'll take a look and help narrow it down.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance or provide feedback.

Thank you.

Answer 2

AgaveJoe 31,706

When you run dotnet test, the test runner only executes the test assembly. Rod, did you remember to start the web host on your laptop before executing the test runner? What you describe is exactly what happens when you try to access localhost:port when the application server is not running.

I am also making the assumption that your development lifecycle requires successful testing locally on the dev machine before deploying to a remote server. We need to know what BaseUrl is configured in the test project:

Is the test project sending HTTP requests to localhost? If so, your Wi-Fi connection speed is irrelevant. If the local web server isn't actively running and listening on that exact port, every test (and manual browser attempt) will simply hang and time out. Take a look at the browser's address bar when the test runs.

If your intention is to run tests against a remote web server, is the BaseUrl configured for that remote endpoint? If so, why clone the application source code to the laptop? Just to run tests? Furthermore, public Wi-Fi networks frequently block non-standard ports, throttle traffic, or suffer high packet loss that easily triggers Playwright's default 30-second navigation timeouts.

Clarifying whether your target is localhost or remote—and verifying that the host process was actually active—will pinpoint why the laptop failed.

Rod Falanga 1,116 Reputation points

2026-08-22T15:56:23.45+00:00

Hi @AgaveJoe good questions. First, I was trying to test the live website, rather than a local instance of the website. During the last couple of weeks that website was unable due to it not having been imported from the previous web hosting company. Very odd, as it worked fine for months, then suddenly quit. I didn't even know that it hadn't been ported, until I started to debug what was going on and why.

Second point was I cloned the Playwright for .NET project, not the website, which is in a different repo. So, I was issuing a dotnet test command as a quick "let's see if Playwright can see the website" type of test. We did resolve this over the previous weekend, and it was working fine all this week, so I was surprised that trying to run the Playwright tests from the command line failed. But maybe it is as you said, problems and issues with Internet connectivity at Starbucks, rather than any real problem with the website or Playwright. My takeaway from this is to just launch a browser and try going to do website with that. I think doing anything from a Starbucks that isn't a simple go to this page and that page and issue HTTP GET commands, is a waste of time using the tools I was trying to us.
AgaveJoe 31,706 Reputation points

2026-08-22T16:19:51.3366667+00:00

My takeaway from this is to just launch a browser and try going to do website with that. I think doing anything from a Starbucks that isn't a simple go to this page and that page and issue HTTP GET commands, is a waste of time using the tools I was trying to us.

Rod, that statement is confusing because browser automation tools like Playwright are doing nothing other than standard HTTP GET and POST requests—exactly like any regular web browser. There is no special background network protocol happening.

Answer 3

Hi Rod,

I have definitely been there! Trying to download dependencies or run automation tests on public coffee shop Wi-Fi can be an incredibly frustrating experience.

To answer your question directly: No, it is highly unlikely that Playwright for .NET left a network connection open to your website that caused those timeouts.

Here is a breakdown of what likely happened behind the scenes:

The Installation Phase: When you run the Playwright browser installation (e.g., pwsh bin/Debug/netX/playwright.ps1 install), Playwright is only communicating with Microsoft's CDNs to download the Chromium, Firefox, and WebKit binaries. If you force-stopped this process due to slow internet, it never even attempted to reach out to your personal website.

Zombie Processes (Local Impact): If a Playwright test starts but is abruptly killed or crashes before it can properly execute browser.CloseAsync(), it can leave headless browser processes (like Chromium or MS Edge) running in the background of your laptop. These "zombie" processes consume local RAM and CPU. While they do not hold an active HTTP connection that locks up your web server, they can heavily bog down your laptop's local network stack and memory, making manual browsing feel terribly slow.

The Network Variable: The most likely culprit for the timeouts was the Starbucks Wi-Fi itself. Public networks often suffer from heavy packet loss, aggressive throttling, and unstable DNS routing. The fact that the website loaded perfectly when you returned to your desktop's stable network confirms that your web server was healthy and not locked up by a hung connection.

For future troubleshooting, if a Playwright test crashes and your machine feels sluggish, open your Task Manager and look for lingering, background instances of Chromium or Edge that Playwright may have orphaned, and manually end those tasks.