WSL2 Support

[shamsalmon]

I get the following message in WSL2 because WSL does not support X-Windows. As you can interact with chrome via selenium server I figure the same must be possible with puppeteer. If we can configure it to connect to the browser remotely rather than trying to launch chromium it would probably work.

Error: Failed to launch the browser process!
[15561:15561:0520/125002.805120:ERROR:browser_main_loop.cc(1512)] Unable to open X display.


TROUBLESHOOTING: https://github.com/puppeteer/puppeteer/blob/master/docs/troubleshooting.md

    at onClose (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/gsts/node_modules/puppeteer/lib/Launcher.js:750:14)
    at ChildProcess.<anonymous> (/home/sam/.nvm/versions/node/v12.16.3/lib/node_modules/gsts/node_modules/puppeteer/lib/Launcher.js:740:61)```

[princepathria97]

Probably sending credentials via headless browser can help https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md

For now, I think only below one can run on WSL
https://github.com/cevoaustralia/aws-google-auth

[Baryczka]

@shamsalmon You can try to install vcxsrv Xserver on your machine to be able to start GUI apps. The app is starting but having other problems unfortunately

[ruimarinho]

I've been trying to fiddle with WSL2 to get this running but I need a bit more time. In the meantime, you should explore some options as mentioned on puppeteer/puppeteer#1837. It seems to be possible.

I've also added the required configuration variables in order to change the executable path in case you can get it running based on the comments of the thread above.

[ruimarinho]

Alright, I got it working under WSL1 @shamsalmon, but not without its caveats!

1. You're probably better off with WSL2, but unfortunately it's hard to test on macOS as it requires nested virtualization. WSL1 (or just "WSL") won't probably cut it because it brings a whole another set of problems with it. Even installing npm on WSL may require workarounds depending on which version of Windows 10 you're on.

2. I'm assuming you're ok with (or even prefer) running the Chrome/Chromium installation of the host system (Windows) instead of running it under Linux and using X for the display, although that comes with additional caveats.

Considering this, using Ubuntu 20.04 on WSL1 I had to:

sudo apt-get update
sudo apt-get install nodejs npm
sudo npm i -g gsts

Now, on the Windows host, install the recommended Chromium revision for the version of puppeteer bundled with gsts. Note this can change at any time, so you will need to make sure you keep the two in sync to avoid issues.

Back to the WSL Terminal, the following step will eventually make it to a command-line argument, but for the sake of testing, edit /usr/local/lib/node_modules/gsts with vim or equivalent text editor and change the const options = on L216 to:

  const options = {
    args: ['--disable-features=site-per-process', `--window-size=${device.viewport.width},${device.viewport.height}`],
    defaultViewport: device.viewport,
    headless: !argv.headful,
    ignoreDefaultArgs: ['--enable-automation'],
    userDataDir: 'C:\\Users\\User\\AppData\\Local\\Temp\\Chrome',
    executablePath: '/mnt/c/Users/User/AppData/Local/Chromium/Application/chrome.exe'
  };

Here, we customize userDataDir to launch with a host-based folder (otherwise puppeteer won't even start) and executablePath to the Windows host binary previously installed.

Now, to the caveats:

• On Windows, headful authentication is not available on headless executions. It has been flagged as an issue multiple times (userDataDir + headless = lost authorization puppeteer/puppeteer#921 Chrome headless (persistent) doesn't save/load cookies on windows microsoft/playwright#717). I've tried pretty much all workarounds and none seem to work. Solution: none at this time, authentication will always spawn a headful instance.
• Version 2.2.0 of puppeteer (at the moment the one that is bundled with gsts) is able to use headful cookies on subsequent runs and due to the way gsts works, it will automatically launch a headful window if cookies aren't authenticated on the headless version. However, it seems like the browser window doesn't close by itself automatically. Solution: call await browser.close(); after the line if (request.url().startsWith('https://console.aws.amazon.com/console/home?state')) { or downgrade manually to puppeter@2.0.0 which apparently does not suffer from this issue.

It would be great if you could test similar approaches on WSL2. It's probably a lot better.

[ruimarinho]

Good news on WSL2. It's a lot easier than WSL1.

• Install VcXsrv, allow firewall access to public networks and disable access control during setup.
• Export the DISPLAY variable using export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0 to connect to the host's X server.
• Install the Debian-based Chromium version based on the instructions available here. Replace Pin: release a=eoan by Pin: release a=focal for Ubuntu 20.04 LTS, which WSL2 uses by default.
• Set the executable path go gsts to /usr/bin/chromium via --puppeteer-executable-path=/usr/bin/chromium (you will need to npm install directly from GitHub until a release is out).

Let me know how it works for you!