Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mvdan opened this issue Sep 18, 2019 · 25 comments
Closed
Labels
DevExp anything around developer experience FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@mvdan
Copy link
Member

mvdan commented Sep 18, 2019

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

@mvdan mvdan added the DevExp anything around developer experience label Sep 18, 2019
@toothrot toothrot added this to the Go1.14 milestone Sep 18, 2019
@toothrot toothrot added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 18, 2019
@rsc rsc modified the milestones: Go1.14, Backlog Oct 9, 2019
@narqo
Copy link
Contributor

narqo commented Dec 5, 2019

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 catapult-project/catapult#4449 but it doesn't seem anything is moving now.

@stapelberg
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

hyangah commented Feb 10, 2020

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
Copy link
Contributor

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: josharian@a5a9f75#diff-f3a5f1780e7f702229cc143e633fd754R12.

@hyangah
Copy link
Contributor

hyangah commented Feb 10, 2020

@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 #34374 (comment) 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
Copy link
Contributor

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

@stapelberg
Copy link
Contributor

stapelberg commented Feb 10, 2020

@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
Copy link
Contributor

hyangah commented Feb 10, 2020

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
Copy link
Contributor

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
Copy link

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

@hyangah
Copy link
Contributor

hyangah commented Feb 11, 2020

@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
Copy link
Contributor

hyangah commented Feb 13, 2020

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
Copy link
Contributor

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

@mvdan mvdan changed the title cmd/trace: requires HTML imports, a deprecated feature that only works on Chrome cmd/trace: requires HTML imports, which doesn't work on any major browser anymore Feb 14, 2020
@kumakichi
Copy link
Contributor

kumakichi commented Feb 15, 2020

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
Copy link

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

@jpvillaseca
Copy link

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
Copy link
Contributor

hyangah commented Feb 20, 2020

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
Copy link

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
Copy link

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

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue Mar 2, 2020
…yfill

Old trace viewer stopped working with Chrome M80+ because the
old trace viewer heavily depended on WebComponents V0 which are deprecated.
Trace viewer recently migrated to use WebComponents V0 polyfill
(crbug.com/1036492). This CL brings in the newly updated trace_viewer_full.html
(sync'd @ 9508452e)
and updates the javascript snippet included in the /trace endpoint
to use the polyfill.

This brings in webcomponents.min.js copied from
https://chromium.googlesource.com/catapult/+/9508452e18f130c98499cb4c4f1e1efaedee8962/third_party/polymer/components/webcomponentsjs/webcomponents.min.js

That is necessary because the /trace endpoint needs to import
the vulcanized trace_viewer_full.html.

It's possible that some features are not working correctly with
this polyfill. In that case, report the issue to crbug.com/1036492.
There will be a warning message in the UI (yellow banner above the timeline)
which can be hidden by clicking the 'hide' button.

This allows to render the trace in browsers other than chrome in theory,
but I observed some buttons and functions still don't work outside
chrome.

Updates #34374.
Fixes #37342.

Change-Id: Ib575f756f5e6b22ad904ede6e4d224a995ebe259
Reviewed-on: https://go-review.googlesource.com/c/go/+/219997
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 75ea964)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220321
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
gopherbot pushed a commit that referenced this issue Mar 2, 2020
…yfill

Old trace viewer stopped working with Chrome M80+ because the
old trace viewer heavily depended on WebComponents V0 which are deprecated.
Trace viewer recently migrated to use WebComponents V0 polyfill
(crbug.com/1036492). This CL brings in the newly updated trace_viewer_full.html
(sync'd @ 9508452e)
and updates the javascript snippet included in the /trace endpoint
to use the polyfill.

This brings in webcomponents.min.js copied from
https://chromium.googlesource.com/catapult/+/9508452e18f130c98499cb4c4f1e1efaedee8962/third_party/polymer/components/webcomponentsjs/webcomponents.min.js

That is necessary because the /trace endpoint needs to import
the vulcanized trace_viewer_full.html.

It's possible that some features are not working correctly with
this polyfill. In that case, report the issue to crbug.com/1036492.
There will be a warning message in the UI (yellow banner above the timeline)
which can be hidden by clicking the 'hide' button.

This allows to render the trace in browsers other than chrome in theory,
but I observed some buttons and functions still don't work outside
chrome.

Updates #34374.
Fixes #37343.

Change-Id: I0f369b15349dd0f4718c261ec23dfab6a47ace2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/219997
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 75ea964)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220323
@yexm
Copy link

yexm commented Apr 5, 2020

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
Copy link

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

@xfoxawy
Copy link

xfoxawy commented May 25, 2020

#34374 (comment)
this solution worked like a charm on macos

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
DevExp anything around developer experience FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests