x/build: add js/wasm Chrome/Firefox capable trybot

[myitcv]

Follow on from #26015 (comment)

With a Chrome and/or Firefox capable trybot we'd be able to do more interesting WASM tests in a headless browser-based JS VM, and so have access to the DOM etc.

This issue is to decide whether or not such a trybot would be useful and therefore worth the effort.

[bradfitz]

@neelance, would a browser-based builder be helpful for anything? I imagine yes, at least for DOM interaction.

[neelance]

Hmm... I don't expect the core packages to do much DOM interaction. That should all go into libraries.

[bradfitz]

In any case, since 99% of users will use Go's wasm support to target browsers, testing in browsers instead of Node still seems like it makes sense, even if v8 is the same in at least Chrome's case.

[agnivade]

This looked interesting, so I took a stab at this. I looked into headless Chrome and used the puppeteer library to interact with the browser through an API.

It took some fighting to figure out the kinks but now I have been able to run the tests completely using puppeteer. So all wasm tests are running completely inside the browser ! I am yet to run all the tests. But encoding/, strings/ run fine :)

I have 2 concerns

• The script needs the puppeteer library installed. So this needs the usual npm install/yarn add business. Adding a package.json would be ugly.
• And during go test, by default it looks for go_$GOOS_$GOARCH, so do I need to put this in a different folder ? Or do we set the -exec parameter manually ? The wasm_exec.js file is shared, so I would prefer both to remain in the same folder.

Thoughts ?

I can put up a DNS CL for people to play around, but just wanted to get the conversation going here.

[myitcv]

I looked into headless Chrome and used the puppeteer library to interact with the browser through an API.

Interesting @agnivade; for running GopherJS tests in browser with https://github.com/myitcv/gjbt (very alpha) I went with https://godoc.org/github.com/sclevine/agouti, on the basis it can drive any browser (although for now gjbt is hardcoded to work with Chrome). agouti requires chromedriver to work with Chrome, but no Javascript package dependency.

The script needs the puppeteer library installed. So this needs the usual npm install/yarn add business. Adding a package.json would be ugly.

Assuming we need an npm package, which might not be the case, there will still be a requirement to have Chrome/Firefox etc available on such a builder. So is this such an issue?

On the plus side, if we can get a good, robust setup in place it will, like misc/wasm/wasm_exec.js, be usable by library authors etc who also want to run their tests in browser (selfishly I'd be one such user).

Clearly this doesn't require that we ship something with the core Go distribution, but this brings us back to @bradfitz's comment in #26051 (comment)

I can put up a DNS CL for people to play around, but just wanted to get the conversation going here.

Would be interesting to have a look through, thanks.

[agnivade]

Ah nice, a Go solution is certainly preferred by me. Since we would like to have a common interface to drive any browser, how about https://github.com/tebeka/selenium ? Have you had any experience with it ? I was wondering if it is better than agouti or are they both kinda the same.

Assuming we need an npm package, which might not be the case, there will still be a requirement to have Chrome/Firefox etc available on such a builder. So is this such an issue?

It just adds the headache of maintaining an extra package.json. Otherwise, it is fine by me. In any case, I am going to investigate the Go based approaches first.

[myitcv]

how about https://github.com/tebeka/selenium ? Have you had any experience with it ?

Unfortunately not.

[bradfitz]

Presumably a browser-based trybot would let us test the net/http Fetch code and catch regressions like: https://go-review.googlesource.com/c/go/+/123537