Skip to content

user-data-dir improperly replaced with Win32 path when running in WSL #334

Description

@dever23b

When using chrome-launcher to start a browser via WSL, and that browser is also installed on the WSL OS, chrome-launcher still replaces the user-data-dir flag with a UNC path instead of using the supplied path. This causes the browser to create bizarre folder names (\\wsl.localhost\...\...\...) inside of the current working directory, resulting in a lot of temp files that don't get removed properly when exiting the browser.

It seems like this code assumes that, when WSL is a factor, we are launching the Windows application and pointing it at config files in the WSL directory. But, now that WSL supports GUI apps natively, this assumption is no longer safe to make. The launcher effectively breaks the flag whenever it is used.

My workaround so far is to specify the userDataDir property to the launcher, and then also include --user-data-dir=<path> in the args property to effectively overwrite what chrome-launcher does to break the flag.

It would be helpful if the launcher could somehow detect whether the binary is running in WSL rather than simply the code that called the launcher.

flags.push(`--user-data-dir=${isWsl ? toWin32Path(this.userDataDir) : this.userDataDir}`);

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions