Browser source maps
gps at mozilla.com
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 Preprocessor.py 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
Preprocessor.py (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