[Bug]: Debugging does not run when breakpoints are put on tests for file names containing Japanese characters.

[dinoss0809]

Version

1.45.2

Steps to reproduce

1.Create an environment by doing the following npm init playwright@latest

2. Rename the file example.spec.ts to include Japanese characters. example.spec.ts → テスト_example.spec.ts
3. Place breakpoints at appropriate locations.
4. Debugging tests from the Test Explorer

Expected behavior

Debugging runs and stops at breakpoints

Actual behavior

Debugging does not run. Also, the test remains running permanently, and VSCode must be exited once to run another test.

Additional context

The same applies even if the folder name is in Japanese.

Not reproduced in the following environments Playwright: 1.42.0

Environment

System:
    OS: Linux 5.15 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (8) x64 11th Gen Intel(R) Core(TM) i7-1165G7 @ 2.80GHz
    Memory: 5.87 GB / 7.58 GB
    Container: Yes
  Binaries:
    Node: 20.15.1 - ~/.nvm/versions/node/v20.15.1/bin/node
    npm: 10.7.0 - ~/.nvm/versions/node/v20.15.1/bin/npm
  IDEs:
    VSCode: 1.91.1 - /root/.vscode-server/bin/f1e16e1e6214d7c44d078b1f0607b2388f29d729/bin/remote-cli/code
  Languages:
    Bash: 5.1.16 - /usr/bin/bash
  npmPackages:
    @playwright/test: ^1.45.2 => 1.45.2 
    playwright: ^1.45.2 => 1.45.2

[dgozman]

@dinoss0809 Could you please provide a full repro so that we can debug the issue locally?

I also noticed that you are probably running in a container (based on the VSCode remote-cli). If so, perhaps you should enable UTF-8 support inside the container? This is what Playwright's image does. Let me know whether that helps.

[dinoss0809]

@dgozman Thank you for your suggestion. I encountered the same issue even when using the Docker image mentioned at Playwright's Docker documentation.

Here are the steps I followed:

1. Installed Ubuntu 22.04 on WSL.

2. Pulled the Playwright Docker image: sudo docker pull mcr.microsoft.com/playwright:v1.45.1-jammy

3. Added my user to the Docker group: sudo usermod -aG docker $USER

4. Ran the Docker container: sudo docker run -it --rm --ipc=host mcr.microsoft.com/playwright:v1.45.1-jammy /bin/bash

5. Used Remote-Containers: Attach to Running Container to access the running container.

6. Initialized a new Playwright project: npm init playwright@latest

• Selected TypeScript.
• Chose the default test directory.
• Opted out of adding a GitHub Actions workflow.
• Installed Playwright browsers.
• Did not install OS dependencies.

7. pened the root folder and installed the Playwright Test for VSCode extension.

8. Set a breakpoint at: await expect(page).toHaveTitle(/Playwright/); Used RUN TEST DEBUG, and it worked, stopping at the breakpoint.

9. Changed the test file name to include Japanese characters:

   • example.spec.ts → テスト_example.spec.ts

10. Set the same breakpoint as before and ran RUN TEST DEBUG again. The test did not run.

This issue occurs even when setting up the Playwright environment directly on Windows and attempting to debug tests with Japanese characters in file names.

[dinoss0809]

I added a breakpoint in node_modules/playwright/lib/runner/testServer.js and observed that it stopped at this line in runTestServer: if ((0, _configLoader.restartWithExperimentalTsEsm)(undefined, true)) return null;

The issue occurs when the file name contains Japanese characters and there is a breakpoint. It fails in the function within node_modules/playwright/lib/common/esmLoaderHost.js. (It works when there is no breakpoint.)

function registerESMLoader() {
  const { port1, port2 } = new MessageChannel();
  require('node:module').register(_url.default.pathToFileURL(require.resolve('../transform/esmLoader')), {
    parentURL: _url.default.pathToFileURL(__filename),
    data: { port: port2 },
    transferList: [port2]
  });
  loaderChannel = createPortTransport(port1);
  exports.esmLoaderRegistered = esmLoaderRegistered = true;
}

In version 1.42.0, this function did not get called because it returned early in node_modules/playwright/lib/common/configLoader.js: diff v1.42.0...v1.45.0

if (!force && !(0, _util.fileIsModule)(configFile)) return false;' I found that the check if (!force && !(0, _util.fileIsModule)(configFile)) was moved inside if (!require('node:module').register). In my environment, if (!require('node:module').register)returned false, leading to(0, _esmLoaderHost.registerESMLoader)();being executed.

[dgozman]

I have filed an upstream issue for the javascript debugger: https://github.com/microsoft/vscode-js-debug/issues/2043

[pavelfeldman]

I was redirected to a Node issue https://github.com/nodejs/node/issues/50516. I'll close as non-actionable in Playwright.