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}`); |
When using
chrome-launcherto start a browser via WSL, and that browser is also installed on the WSL OS,chrome-launcherstill replaces theuser-data-dirflag 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
userDataDirproperty to the launcher, and then also include--user-data-dir=<path>in theargsproperty to effectively overwrite whatchrome-launcherdoes 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.
chrome-launcher/src/chrome-launcher.ts
Line 178 in d6be1f3