Concrete things:

- the "version" command returns a dict that contains, among other things, "WebKit-Version" (https://cs.chromium.org/chromium/src/content/browser/devtools/devtools_http_handler.cc?l=572). Can we just remove that? After https://chromium-review.googlesource.com/c/chromium/src/+/1369629 , that'd be enough to remove GetWebKitVersion()

- GetWebKitRevision() is called in three places:
1. DevToolsUI::GetRemoteBaseURL() which computes a string like https://chrome-devtools-frontend.appspot.com/serve_file/$rev
2. DevToolsHttpHandler::GetFrontendURLInternal which computes a string like http://chrome-devtools-frontend.appspot.com/serve_rev/$rev/inspector.html
3. BrowserHandler::GetVersion() which in the end is one of the fields returned by called by Browser.getVersion(). This should probably receive the same handling as the "version" command above.


For the URLs, the "content hash of devtools files" seems like it could work from a distance. For the two version commands, that could work too but it'd be a bit nicer to remove this information altogether if feasible, since protocol version in theory should be enough.

Browser.getVersion returns the version of the browser, that's unrelated to DevTools frontend. We'd like to return whatever is visible on chrome://version - is that a problem? Are we removing version/hash information from chrome://version?

If we leave BrowserHandler::GetVersion, would it be a problem to also reference that for DevTools frontend hash? Otherwise, we'll have to change the backend as well, and also figure out how to switch in backwards-compatible way, so that newer Chrome can load older DevTools frontends, currently addressed by the commit hash.

> Are we removing version/hash information from chrome://version?

Not clear to me, see issue 872407 -- if we remove it, it'll be the last thing we remove though. Why does devtools need to expose that though?

We expose this for automation scenarios. For example, when running headless chromium in the cloud, it's useful to be able to automatically get version for the binary instead of retrieving it through the side-channel.

Reading issue 872407, we can expose revision through ContentClient, which should make content component (in terms of component build) resilient to hash changes. Test binaries can even hardcode something instead of reporting the real revision. Would that address the issue?

The motivation here is to run fewer needless tests, see e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=869348&desc=2#c74

In https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Win%207%20Tests%20x64%20%281%29/45949 we trigger 111 test binaries. None of them contain any new information, yet we only dedupe 76 of the 111 runs, 35 are not deduped. Your suggestion of putting this in the ContentClient would help with all the binaries above the chrome/ layer (content_browsertests etc), so it'd be better than what we currently have. So if that's easy to do, let's do that first.

It'd mean that content_shell-based things couldn't talk to the devtools server. Is that fine? If not, we'd have to something else (e.g. the js source hash thing I suggested).

If we do the hash thing for RemoteBaseURL(), could we expose that as version field? Or is it important that that version matches the browser's revision?

> It'd mean that content_shell-based things couldn't talk to the devtools server. Is that fine?
That's alright. We bundle devtools frontend in content_shell - no need to fetch from remote.

For RemoteBaseURL(), I'd prefer to keep existing hash solution. It sits at the top of food chain (in chrome/), and should not affect that much.

On a side note, perhaps we could just hardcode the hash in test binaries vs providing a real one in product binaries?

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.