Mysterious Chrome webdriver bug

[oktaal]

The Travis-CI test fails with a rather unhelpful message:

ERROR [launcher]: Cannot start Chrome

It tries to do this a few more times and then gives up:

https://travis-ci.org/UUDigitalHumanitieslab/cookiecutter-webapp-deluxe/builds/587395445

I've already tried synchronizing the Chromedriver version with the Chrome version being used and disabled the sandboxing. Problem persists. Giving up for now.

[jgonggrijp]

Maybe the Chrome version on the build image has grown out of sync with the chromedriver version that yarn installs by default (most likely, the latter is "too new"). If this is the case, it can be fixed by pinning the version of chromedriver to install.

Otherwise, it is also possible to work around it by using only geckodriver for the time being so that at least we have a passing build. Call yarn test-func with -o webdriver=Firefox in order to do this.

[oktaal]

Installing the right synced version is what this should do:

https://github.com/UUDigitalHumanitieslab/cookiecutter-webapp-deluxe/blob/63d965b120e1fc76b5e7b46d57f4bffe43553a4e/.travis.yml#L23-L28

Or is there something else causing another version being installed?

[jgonggrijp]

@oktaal's discovery, but reproducing here for future documentation: indeed, the unittests probably depend on chromedriver, too.

[ar-jan]

I hadn't checked the issue queue at the time, but I think this was fixed with dff8bd595f90f0f5b27d20a0e8fffe73681f0cc1.

[jgonggrijp]

Well done @ar-jan. Feel free to close issues when you think you fixed them.

Tip: if you mention the issue number with the word "fix" or "close" before it in your commit message, and the commit is merged in the repo's default branch, the ticket is closed automatically.

[ar-jan]

I'm just discovering that I now have this problem locally (again). I'll update and/or close when I know more.

[ar-jan]

Well, after endless futile attempts ...

google-chrome-stable --no-sandbox --headless --disable-gpu --remote-debugging-port=9222 http://localhost &

DevTools listening on ws://127.0.0.1:9222/devtools/browser/6ea93742-ace7-4deb-901d-11aa7f19a7a0 [0126/160952.282892:ERROR:sandbox_linux.cc(378)] InitializeSandbox() called with multiple threads in process gpu-process.

The --no-sandbox appears to have no effect. This apparently has to do with graphics drivers which aren´t/cannot be sandboxed yet, and --disable-gpu doesn't solve this anymore. The --disable-software-rasterizer which is suggested in some places only resulted in yet another error:

ERROR:gpu_init.cc(457)] Passthrough is not supported, GL is disabled, ANGLE is

Adding --use-angle=gl-egl didn't work

Setting MESA_GLSL_CACHE_DISABLE=true as env variable didn't work

I've now found a "solution" in downgrading google-chrome-stable to v88 again.

wget https://dl.google.com/linux/chrome/deb/pool/main/g/google-chrome-stable/google-chrome-stable_88.0.4324.96-1_amd64.deb sudo apt-get install ./google-chrome-stable_88.0.4324.96-1_amd64.deb

[ar-jan]

While downgrading Chrome worked to solve the sandbox problem for me, the Xvfb solution for the Unable to open X display issue (sudo Xvfb -ac :99 -screen 0 1280x1024x16 & export DISPLAY=:99) did not work reliably for me. Instead, using xvfb-run yarn test works.

Closing this now, as it worked on Travis before and now locally as well. For Github Actions followup, #25.

[ar-jan]

Documenting for completeness: mysteriously I am now able to run tests locally with the latest version of chrome/chromedriver (v97) again, without sandbox / gpu issues. The xvfb-run command remains necessary, but is more convenient in any case: xvfb-run yarn test, xvfb-run ng test, etc.