Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
dever23b opened this issue Jul 11, 2024 · 0 comments
Open

Comments

@dever23b
Copy link

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}`);

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant