Go: cmd/trace: requires HTML imports, which doesn't work on any major browser anymore

[mvdan]

go version devel +d3595f7171 Wed Sep 18 07:29:33 2019 +0000 linux/amd64

This affects "View trace" on the web UI when running go tool trace. It doesn't matter what the contents of the trace are; they can be from any test, for example via go test -trace=trace.out.

On Chromium 77.0.3865.75 it works, although with some warnings:

[Deprecation] HTML Imports is deprecated and will be removed in M80, around February 2020. Please use ES modules instead. See https://www.chromestatus.com/features/5144752345317376 and https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade for more details.
trace_viewer_html:3455 [Deprecation] document.registerElement is deprecated and will be removed in M80, around February 2020. Please use window.customElements.define instead. See https://www.chromestatus.com/features/4642138092470272 and https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade for more details.
(anonymous) @ trace_viewer_html:3455
(anonymous) @ trace_viewer_html:3455
trace_viewer_html:3635 [Deprecation] Element.createShadowRoot is deprecated and will be removed in M80, around February 2020. Please use Element.attachShadow instead. See https://www.chromestatus.com/features/4507242028072960 and https://developers.google.com/web/updates/2019/07/web-components-time-to-upgrade for more details.
_createLocalRoot @ trace_viewer_html:3635
_setupRoot @ trace_viewer_html:3607
_ready @ trace_viewer_html:3487
_tryReady @ trace_viewer_html:3487
_initFeatures @ trace_viewer_html:3930
__initialize @ trace_viewer_html:3438
createdCallback @ trace_viewer_html:3435
(anonymous) @ trace:94

On Firefox 69.0, it simply doesn't work at all. http://localhost:$PORT/trace appears as a blank page. The log shows why:

ReferenceError: tr is not defined trace:59:5
    onResult http://[::]:8080/trace:59
    onreadystatechange http://[::]:8080/trace:43

The underying cause is that FireFox, as well as many other browsers, don't support HTML imports. I'm not sure if they were ever widespread, but they're clearly deprecated and non-portable at the moment. See https://caniuse.com/#feat=imports and https://developer.mozilla.org/en-US/docs/Web/Web_Components/HTML_Imports.

I realise that the docs say:

Note that while the various profiles available when launching 'go tool trace' work on every browser, the trace viewer itself (the 'view trace' page) comes from the Chrome/Chromium project and is only actively tested on that browser.

However, I don't find that to be a good long-term plan. The tool shouldn't depend on deprecated non-portable features, and it should work on all major browsers.

I've been recommending that Go developers make use of go tool trace alongside go tool pprof, but it feels much less useful if it needs a "only works on Chrome" footnote :)

/cc @hyangah

[narqo]

In this document, Google Chrome team describes the steps required to move a project from WemComponents v0.

I think the change in existing trace-viewer was expected in https://github.com/catapult-project/catapult/issues/4449 but it doesn't seem anything is moving now.

[stapelberg]

With Chrome 80 now being stable, this means go tool trace cannot display traces anymore, and the issue just got a lot more urgent :)

[stapelberg]

See also https://crbug.com/1021137

Workaround:

1. Get an origin trial token for WebComponents V0 for http://127.0.0.1:8003 from https://developers.chrome.com/origintrials/#/register_trial/2431943798780067841
2. Insert your token into src/cmd/trace/trace.go’s templTrace like so:
   <meta http-equiv="origin-trial" content="YOUR_TOKEN_GOES_HERE">
3. Rebuild using (cd src && ./make.bash)
4. Run with -http=127.0.0.1:8003, e.g.:

% go tool trace -http=127.0.0.1:8003 test.trace         
2020/02/09 13:41:51 Parsing trace...
2020/02/09 13:41:51 Splitting trace...
2020/02/09 13:41:51 Opening browser. Trace viewer is listening on http://127.0.0.1:8003

[stapelberg]

Perhaps, as a stop-gap, a member of the Go team could register such a token and commit it? I’m not sure if it’s okay for me to get a token and use it like that.

[hyangah]

Sigh. We can do that, but I often had to run multiple instances of execution trace viewer and allowing a single port limits its usability. Is it an option to fork the repo and apply changes like https://chromium-review.googlesource.com/c/1093433?

[josharian]

Is the problem here how we get the data from the http request into a place where the trace viewer can render it?

If so, one solution is to have go trace emit a single standalone file, with the data embedded in it. (See also the various links in that issue.) I did this as part of a different effort, killed by Russ, back around Go 1.8 days: https://github.com/josharian/go/commit/a5a9f7595338afbfd5f814956b17dc60e0bc586e#diff-f3a5f1780e7f702229cc143e633fd754R12.

[hyangah]

@josharian Reading the bug @stapelberg linked, the problem seems to be that the traceviewer itself heavily depends on the deprecated features and requires migration. traceviewer doesn't sound trivial reading https://crbug.com/1021137.

I also tried to manually load the jsontrace output from chrome://tracing but that also failed. Maybe we fall into one of those niche use cases the mentioned crbug is talking about.

@stapelberg does the workaround https://github.com/golang/go/issues/34374#issuecomment-583840806 work for you? I still couldn't make it working :-(

I found https://chromium-review.googlesource.com/c/catapult/+/1906771/10/tracing/tracing_examples/trace_viewer.html
where the token for localhost:8003 is being used already. how this origin trial works and whether we can reuse it.

[josharian]

@egonelbre investigated rebuilding traceviewer in #11520. Hopefully it won't come to that, though.

[stapelberg]

@stapelberg does the workaround #34374 (comment) work for you? I still couldn't make it working :-(

Yeah, it works for me. Did you register an origin trial for 127.0.0.1? Need to use that, not localhost. go tool trace always opens 127.0.0.1, even if you specify e.g. localhost:8003.

(Or open localhost:8003 explicitly in your browser.)

[hyangah]

Thanks. that works for me.
Another alternative is to start a chrome --enable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImports flag.

I was told that the traceviewer dev is working on a fix which may be available within one or two weeks. Not sure if we can make it before 1.14 release though.

We also need a long term transition plan. Chrome/android are moving away from trace viewer and transitioning to perfetto.dev.

[stapelberg]

Another alternative is to start a chrome --enable-blink-features=ShadowDOMV),CustomElementsV0,HTMLImports flag.

Ah, cool. Are you suggesting go tool trace does that? That’d solve the issue for a little while without restricting port selection.

We also need a long term transition plan. Chrome/android are moving away from trace viewer and transitioning to perfetto.dev.

I briefly looked at perfetto today and it seemed super complex. I’m guessing they mean a stripped-down, self-contained version of parts of perfetto’s ui?

[gopherbot]

Change https://golang.org/cl/219117 mentions this issue: cmd/trace: add origin-trial tokens for port 8000-8003

[hyangah]

@stapelberg Looking at the cmd/internal/browser... I want to avoid all the browser launch business. It's tricky to start a chrome from mac with a complete new set of flag (without killing the existing instance). the cl/219117 follows your proposal. I am not sure whether the fix trace viewer team is talking about will address our issue.

[hyangah]

I am waiting for the progress on the trace viewer side - we are still not sure if that will fix our and other trace viewer users issue that depend on embedding the vulcanized trace viewer.
Depending on the progress and the scope of the fix, we will create a cherrypick request for the next point releases.

For now, please fetch/build with https://golang.org/cl/219117 and use the ports 8000-8003 of 127.0.0.1. Or launch a chrome with the suggested flag: --enable-blink-features=ShadowDOMV0,CustomElementsV0,HTMLImport

Sorry for the inconvenience.

[choleraehyq]

On safari 13.0.5, http://localhost:$PORT/trace also appears as a blank page because of "ReferenceError: Can't find variable: tr".

[kumakichi]

Hi, guys, I created a repository following the steps given by @stapelberg :

Update: use official patches now, https://go-review.googlesource.com/q/Ib575f756f5e6b22ad904ede6e4d224a995ebe259

https://github.com/kumakichi/patch-go-tool-trace

just go get and run (maybe sudo is needed)

[gopherbot]

Change https://golang.org/cl/219997 mentions this issue: cmd/trace: update to use WebComponents V0 polyfill

[jpvillaseca]

In case someone is on a rush, to apply the fix without delving in Gerrit, you can download the commit that fixes the issue of Go Trace from the official repository https://go.googlesource.com/go/+/47881b88c4f68bac7a002ea26753b7f042ee720a (download the .tgz)
and you just need to replace the following files in your Go dir from the downloaded tgz: (Go dir is not %GOPATH%)

misc/trace/trace_viewer_full.html
misc/trace/webcomponents.min.js
src/cmd/trace/trace.go

Running go install cmd/trace makes the updated tool available to use normally in go trace. The fix that Hana (Hyang-Ah) Kim uploaded makes use of 3 tokens available for ports 8001:8003 with a polyfill for the deprecated WebComponents V0, without the need to run Chrome with special flags.

[hyangah]

I just submitted cl/219997. We think this is too risky to include to 1.14. We plan to add it to the first patch release. Meanwhile, you can compile or download the latest developer version of Go (e.g. https://godoc.org/golang.org/dl/gotip) and use the execution tracer included in it.

@gopherbot please backport to 1.13 and 1.14

[gopherbot]

Backport issue(s) opened: #37342 (for 1.13), #37343 (for 1.14).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[gopherbot]

Change https://golang.org/cl/220323 mentions this issue: [release-branch.go1.14] cmd/trace: update to use WebComponents V0 polyfill

[gopherbot]

Change https://golang.org/cl/220321 mentions this issue: [release-branch.go1.13] cmd/trace: update to use WebComponents V0 polyfill

[yexm]

See also https://crbug.com/1021137

Workaround:

1. Get an origin trial token for WebComponents V0 for http://127.0.0.1:8003 from https://developers.chrome.com/origintrials/#/register_trial/2431943798780067841
2. Insert your token into src/cmd/trace/trace.go’s templTrace like so:
   <meta http-equiv="origin-trial" content="YOUR_TOKEN_GOES_HERE">
3. Rebuild using (cd src && ./make.bash)
4. Run with -http=127.0.0.1:8003, e.g.:

% go tool trace -http=127.0.0.1:8003 test.trace         
2020/02/09 13:41:51 Parsing trace...
2020/02/09 13:41:51 Splitting trace...
2020/02/09 13:41:51 Opening browser. Trace viewer is listening on http://127.0.0.1:8003

thank you

[oliverpool]

This is pretty cool, because it now works in Firefox as well :tada:

[xfoxawy]

https://github.com/golang/go/issues/34374#issuecomment-586553451
this solution worked like a charm on macos