Support source maps

[gregtatum]

Right now this seems viable in the DevTools recording panel mode. I think we should hold off on retaining source maps in the Gecko Profiler Addon, due to complexities of inlined sourcemaps.

┆Issue is synchronized with this Jira Task

[gregtatum]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1421403 for tracking.

[julienw]

I'm gonna reopen this issue just for the sake of tracking this. Maybe well have to discuss of the approach again.

[mstange]

I think it would be good to handle source maps like we handle symbolication: Give the raw profile to profiler.firefox.com first, and then resolve source maps asynchronously, with help from the browser. Resolving source maps requires the source map files, which need to be requested from the network. It would be unfortunate to block opening the profile on those network requests.

So, the full source map resolution workflow is:

• From the profile, find the list of JS URLs which are bundles with source maps. (This step is the one I'm most confused about; does this require getting the source code for every JS URL and checking if it starts with a source map indicator comment? Or does it require checking for every .js URL whether there exists a file at the corresponding .js.map URL?)
• For each of these URLs:
  • List all the source locations in the minified bundle which the profiler observed, i.e. all { lineNumber, columnNumber } pairs.
  • Fetch the source map file.
  • Resolve each location to { originalFunctionName, originalFilePath, originalLineNumber, originalColumnNumber }. (Or maybe to a list of those? Do source maps support "inlined" functions?)
  • Apply these mappings to the profile JSON.
  • The source map file also contains the source code for each originalFilePath.

So then the question is how to split the work between the browser and the web page. Should the browser just fetch the source map file and pass it along, or should it also do the resolution? And how much security checking should the browser do so that it only allows fetching files which it wants the profiler to have access to?

There's also the use case of "private source maps": A user who captures a profile may not have access to source maps, but then they send the profile to a developer who does have access to them. It would be great to give the developer the ability to add source maps to a profile manually. This supports the idea of doing source map resolution in the web page, rather than in the browser.

[sorin-davidoi]

This step is the one I'm most confused about; does this require getting the source code for every JS URL and checking if it starts with a source map indicator comment? Or does it require checking for every .js URL whether there exists a file at the corresponding .js.map URL?

I don't think there is a way to avoid fetching every JS URL, mostly because we can't assume that the potential sourcemap is external or that it has the same filename but suffixed with .map. I would imagine the decision tree for each such fetched file to be along the lines:

• does it have a source map indicator comment (it's usually at the end of the file, not sure if that is a spec requirement though)?
  • yes - is the sourcemap inlined?
    • yes - extract and process it
    • no - fetch and process it
  • no - display as is

[mstange]

I see, interesting. Well, the browser has to have fetched this JS before, because it's executing it. Maybe there's some efficient way to have that existing JS parsing detect source maps and tell the profiler about those URLs.

[mstange]

Indeed there is! The JS engine already detects source map URLs. They can be queried using ScriptSource::sourceMapURL. So we can put those source map URLs into the profile JSON.