Browser source maps

Gregory Szorc gps at
Tue Oct 8 15:53:46 UTC 2013

On 10/8/13 1:12 PM, Gijs Kruitbosch wrote:
> After the discussion on this list about the possibility of making an
> add-on to write browser patches from the browser itself, I figured that
> one thing that'd make this easier would be having source maps for the
> preprocessed browser chrome JS, so you could actually debug/see what
> would normally be in hg.

Which discussion was this? In build system land, we were actually 
talking about a build mode where Firefox developers could use a 
pre-built libxul so they wouldn't have to spend time compiling all the 
C++ in the tree. If we went this route, developers would presumably have 
the source tree available and source maps back to hg wouldn't be necessary.

> I was halfway writing a patch (to and friends) for this
> when I realized this is sort of the "wrong way around": you need to be
> able to get the processed version based on changes from the original
> source, and seeing the original for stuff that's already processed is
> somewhat orthogonal, unless the maps can be used to map changes made to
> the processed version back to changes that would need to be made to the
> original version. I don't think that's easily possible, but Nick might
> know more?
> In any case, I was intrigued by the possibility of having these maps. At
> this point, I have a working patch that produces source maps.

We also will need source maps if we ever minify packaged JS (bug 
903149). There is also other work in build land that touches (bug 924343). Can you please get a bug on file and 
ensure it's chained up to a Build Config component so relevant people 
see it? Otherwise, bit rot is in all of our futures.

> It needs cleaning, but before I do that I figured I would stop and think
> about if/how we would/should want to integrate this. In particular:
> - do other people see value in having this available?
> - where should these maps live?
> - where should the original source files live? Can we host these
> remotely? (Nick, would anything break/complain if we had
> chrome://browser/content/browser.js have an http(s) sourceMappingURL, or
> perhaps a chrome:// hosted source map that referenced remote source files?)

I was talking to dcamp about source maps for chrome JS for bug 903149 
and apparently something currently loads source maps using synchronous 
I/O. So remote hosted source maps [with high latency] will probably 
result in a bad time. Supposedly there is a bug somewhere for the 
components to grow the appropriate async APIs.

We should investigate hosting source maps like we do debug symbols.

> - shipping this to release-channel end-users sounds like something that
> wouldn't be worth the extra package size. Would we want to include them
> on nightly (aurora?) to ease debugging etc.?

You are correct that shipping is likely a non-starter for at least 
release channels because of packaged size. We're talking about shipping 
assets that are only useful for <1% of the population. The packages are 
already too large - we shoudln't be making the problem worse. I think 
the ideal solution involves baking source map discovery into the client, 
in every channel.

> - or (wild idea) should we make the build process produce an add-on that
> includes all these extra bits, that people can opt in to installing?

I was thinking something like this. Although it would possibly be 
exposed as a developer tool of some kind (don't we have add-ons for 
devtools or something?). I believe dcamp had ideas when I talked to him.

More information about the firefox-dev mailing list