1949889 - In the profile JSON, include enough information so that the front-end can fetch Firefox-internal JS code from the source repository (map moz-src URLs to repo paths)

Status: NEW

(Core :: Gecko Profiler, enhancement, P3)

Description

[Markus Stange [:mstange]]

Steps to reproduce:

1. Capture a profile in a Firefox Nightly build with the Firefox profiler.
2. Upload the profile.
3. Load the uploaded profile in a new tab, or even in a different browser.
4. Find a JS frame for some Firefox JS, e.g. for tabbrowser.js on the parent process main thread.
5. Double click that JS frame in the call tree.

Expected results:

The profiler front-end should know how it can fetch the JS source for tabbrowser.js from the Firefox source repository. (e.g. from some hg.mozilla.org raw-file path at the moment)

Actual results:

The profiler front-end currently does not have enough information to be able to pull the file from a public server.

---

Bug 1945566 will remove the biggest roadblock here, which is that the path in the URL doesn't match the path in the repository, for example chrome://browser/content/tabbrowser/tabbrowser.js is really at browser/components/tabbrowser/content/tabbrowser.js.

My understanding is that, after bug 1945566, the profiler will instead see the URL moz-src:///browser/components/tabbrowser/content/tabbrowser.js for this JS frame.

---

How exactly should we do it?

The profile JSON already has a profile.meta.sourceURL field which, in the Nightly that I'm running at the moment, is set to https://hg.mozilla.org/mozilla-central/rev/54c1adbab9fb0376a3a0521762af1e52070bb2a5 . (The profiler gets this URL from nsIXULAppInfo.)

So in theory, once we have the moz-src URLs, we could add special handling to the front-end and have it combine the path it finds in a moz-src URL with the repository URL from profile.meta.sourceURL. But it would be nice if we didn't have to add new Firefox-specific knowledge to the front-end.

We could also piggy-back on the front-end's existing support for "special paths":

The front-end has special handling for paths which start with hg: or git: or s3: or cargo:. For example it knows that, if the path is git:github.com/rust-lang/rust:library/std/src/sys/unix/thread.rs:53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b , it can request the raw file from https://raw.githubusercontent.com/rust-lang/rust/53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b/library/std/src/sys/unix/thread.rs .

So we could do some translation in the Gecko profiler platform code during JSON serialization and translate all moz-src:// URLs into that syntax. For example, in my current build, moz-src:///browser/components/tabbrowser/content/tabbrowser.js would be translated to hg:hg.mozilla.org/mozilla-central:browser/components/tabbrowser/content/tabbrowser.js:54c1adbab9fb0376a3a0521762af1e52070bb2a5 .

But then we lose the original URL. The front-end would then only display browser/components/tabbrowser/content/tabbrowser.js (i.e. the "display path" it parsed from the "special path"), whereas the user might want to see the entire original URL including the moz-src:/// part, especially if it's a URL with a special "host" such as moz-src://privileged-content-process/ .

So we may want to think of a way to include two paths for a JS frame in the profile JSON, i.e. both the original URL and the mapped path.

Comment 1

[Markus Stange [:mstange]]

Another factor is that, at the moment, the profiler platform code doesn't actually know the URL of a JS frame - it just sees a frame name of the shape "functionName (URL:123:45)" and puts that string into the JSON as-is. The actual parsing of that string to separate it into a function name and a URL happens in the part of the front-end where we convert from the Gecko profile format into the processed profile format.