[Bug]: Cannot run UI mode in docker using podman

[edumserrano]

Version

1.50.1

Steps to reproduce

1. Install podman on Windows. For instance: winget install --id RedHat.Podman
2. Run the playwright container in interactive mode with a shell: podman run --entrypoint /bin/sh -it mcr.microsoft.com/playwright:v1.50.1-noble
3. At this point you should be in a shell in a container running mcr.microsoft.com/playwright:v1.50.1-noble. Run playwright test in UI mode as per docs: npx --yes playwright test --ui-host=0.0.0.0.
4. You get an error.

Expected behavior

It should start UI mode without the error.

Actual behavior

This is the error you get:

Listening on http://0.0.0.0:44003
node:events:502
      throw er; // Unhandled 'error' event
      ^

Error: spawn /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe ENOENT
    at ChildProcess._handle.onexit (node:internal/child_process:285:19)
    at onErrorNT (node:internal/child_process:483:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21)
Emitted 'error' event on ChildProcess instance at:
    at ChildProcess._handle.onexit (node:internal/child_process:291:12)
    at onErrorNT (node:internal/child_process:483:16)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'spawn /mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe',
  path: '/mnt/c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe',
  spawnargs: [
    '-NoProfile',
    '-NonInteractive',
    '–ExecutionPolicy',
    'Bypass',
    '-EncodedCommand',
    'UwB0AGEAcgB0ACAAIgBoAHQAdABwADoALwAvAGwAbwBjAGEAbABoAG8AcwB0ADoANAA0ADAAMAAzACIA'
  ]
}

Node.js v22.13.1

Additional context

This only happens with podman, I've tried both rancher and docker desktop and those work fine.

I've tried to search online for this error and found people complaining of similar issues but no real explanation. I'll leave here a few links though that might help:

1. strapi/strapi#12479: the workaround from this comment also worked for me.
2. nuxt/nuxt/issues/13770: this issue seems to detail a similar problem where they root caused the bug to the is-wsl which is a dependency of open.
3. Searching the code of the open npm package I can see a bit of code that seems relevant to this issue. See https://github.com/sindresorhus/open/blob/2ea66da8e8b20880d235447cf4c94ba275da6a5a/index.js#L167-L172

else if (platform === 'win32' || (isWsl && !isInsideContainer() && !app)) {
  const mountPoint = await getWslDrivesMountPoint();
  command = isWsl
      ? `${mountPoint}c/Windows/System32/WindowsPowerShell/v1.0/powershell.exe`
      : `${process.env.SYSTEMROOT || process.env.windir || 'C:\\Windows'}\\System32\\WindowsPowerShell\\v1.0\\powershell`;

4. There seem to have been fixes in the open library that might be related to this. For instance: sindresorhus/open#218
5. I noticed that Playwright also uses the open package but you use an old version. I believe you are using version 8 and latest is version 10. If indeed the issue is related to the open package perhaps the latest version of the package doesn't contain this problem?

Why do I want to run with podman ?

Because of the license costs of using Docker Desktop my company has finally decided that they don't want to pay the licenses anymore and have mandate the switch to podman. I would like that Playwright works with podman as expected without having to perform any workaround, such as described in the first point above.

Environment

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 7800X3D 8-Core Processor
    Memory: 35.94 GB / 63.16 GB
  Binaries:
    Node: 22.13.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.22 - C:\Program Files\nodejs\yarn.CMD
    npm: 11.1.0 - C:\Program Files\nodejs\npm.CMD
  IDEs:
    VSCode: 1.97.0 - C:\Users\eduar\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD
  Languages:
    Bash: 5.1.16 - C:\Windows\system32\bash.EXE
  npmPackages:
    @playwright/test: ^1.50.1 => 1.50.1
    playwright-core: ^1.50.1 => 1.50.1

[mxschmitt]

I can confirm that updating to 'open': v10 fixes it. Its an ESM only package now tho which we can't use, since we are not an ESM project as of today.

[edumserrano]

@mxschmitt would it be out of scope to have a flag that we could pass to tell Playwright to not try and open a browser window when running in UI mode? In the scenarios where you run in Docker you'd likely always want to set that flag because you just want toe Playwright server to start and the you access it from a browser on the host.

[mxschmitt]

As a workaround today you could probably set PWTEST_UNDER_TEST=1 env var - not sure if it has other side effects but that would skip calling 'open'.

I think we are open introducing adding a new env var for it, haven't discussed it with the team tho.

[edumserrano]

not sure if it has other side effects but that would skip calling 'open'.

That isn't very reassuring 😅. I'd rather stick with this workaround instead because I'm sure it won't cause any side effects with the Playwright tests.

I think we are open introducing adding a new env var for it, haven't discussed it with the team tho.

If updating the open package is problematic then I think you should consider adding a cli option for this, not an env var, make it part of the "public API" for playwright test. So I can do something like:

playwright test --ui-host=0.0.0.0 --ui-no-open

I think it should be part of the cli option because:

1. It provides an option that most libraries that execute a command and then open browser pages have, which is the option to not open the page after the command is executed. There are many scenarios where this is useful, when running in a container is just one of them.
2. This in combination with updating the playwright docs about running UI mode in a container by changing the commands:

npx playwright test --ui-host=0.0.0.0 to npx playwright test --ui-host=0.0.0.0 --ui-no-open and npx playwright test --ui-port=8080 --ui-host=0.0.0.0 to npx playwright test --ui-port=8080 --ui-host=0.0.0.0 --ui-no-open

Would prevent other users from hitting this bug and essentially provide podman support.

Alternatively, you could consider not extending the test cli, though I like that option, and change the code so that, when running UI mode, you check if you are running in a container and NOT open the browser in the UI mode URL. I'm not sure there are any useful cases though where you'd want to open the browser with UI mode when running in a container, but if you follow this option then you remove support for those cases.

[pavelfeldman]

Why was this issue closed?

Thank you for your contribution to our project. This issue has been closed due to its limited upvotes and recent activity, and insufficient feedback for us to effectively act upon. Our priority is to focus on bugs that reflect higher user engagement and have actionable feedback, to ensure our bug database stays manageable.

Should you feel this closure was in error, please create a new issue and reference this one. We're open to revisiting it given increased support or additional clarity. Your understanding and cooperation are greatly appreciated.