Latest version of `chromedp` breaks `vugu` testing

[owenwaller]

This issue tracks this issue in the chromedp project.

The first thing to say is that vugu still works. This issue will only impact you if you are a contributor to vugu. If you are a normal user of vugu and do not run the vugu tests themselves then this issue may not impact you.

However if you also make use of the chromedp project to test your vugu projects then you are very likely going to to be impacted by the same issues that the vugu has been.

The vugu project uses the chromedp package for testing that the wasm files that the *.go and *.vugu` files ultimately generates does what we expect when executed in a browser.

The testing process works like this (slightly simplified):

• A Go test the runs locally connects to http://vugu-chromedp:9222
• vugu-chromedp:9222 is a docker container containing a headless version of chrome. This container will be started by the build process before the test is run. The vugu-chromesp is the hostname given to the container when it is created.
• The locally running Go tests then tells the headless chrome via the chromedp package to connect to http://vugu-nginx:8888/<test-name>
• Again the vugu-nginx:8888 is a separate container running nginx that will serve the wasm and html files from the tests local directory. The build system ensures that the nginx container has been started with the correct name.
• The locally running Go test then queries the DOM in the headless chrome to see if we have the changes to the DOM that we expect.

There is now an issue upstream of the vugu project in the chromedp project which prevents the locally running vugu Go test from connecting to the headless chrome in the container that is started by the build process.

The upstream issue details in the chromedp project are here.

The issue in the chromedp project may be caused by a further upstream change in the chrome project itself. See the issue linked above for the details, but an option that the chromedp package relies on --remote-debug-address appears to have been removed in the upstream chrome project.

We can confirm this is not an issue with vugu or the vugu tests or build system because both @bradleypeabody and myself can consistently reproduce the issue using only docker and curl commands.

@bradleypeabody and myself now need to consider what to do. In the short term we a can pin the version of chromedp that we use in for testing to a version that does work, from about a May 2024. But as time passes, unless the upstream projects resolve their issues that version of Chrome will become progressively more outdated. This does not seem to be an ideal situation for the vugu community in the medium to long term.

Any long term options will require further discussion.

We will keep this issue updated as and when things change in the upstream chromedp project.

Owen

[owenwaller]

it looks like the upstream chromedp project has resoled this issue.

Details here.

So everything should be working again.

[owenwaller]

Closing as this appears to be fixed upstream.