You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
When using
chrome-launcher
to start a browser via WSL, and that browser is also installed on the WSL OS,chrome-launcher
still replaces theuser-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 theargs
property to effectively overwrite whatchrome-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.
chrome-launcher/src/chrome-launcher.ts
Line 178 in d6be1f3
The text was updated successfully, but these errors were encountered: