Browser source maps

Fitzgerald, Nick nfitzgerald at
Tue Oct 8 21:17:39 UTC 2013

On 10/8/13 9:47 AM, Gijs Kruitbosch wrote:
> On 08/10/13 17:53 , Gregory Szorc wrote:
>> 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.
> Source maps only indicate what bits of a processed source file
> translate to which bits of (an) original source file(s). This is
> useful even if you do have a tree, because it gets you
> original-source-based stacks/debugging, rather than
> processed-source-based stacks/debugging.


> Caveat emptor: I believe that currently, the error console doesn't use
> source maps yet. Again, Nick would know more.

Correct. We only have an API to get the source mapping url when spider
monkey is in debug mode. I talked with Eddy Bruel about possibly
maintaining a map of generated url -> source mapping url inside
spidermonkey, even when not in debug mode. In order to prevent leaks we
could just cap it at a fixed size.

Eddy, do you still think this is a possible solution? We really need
source maps in our console.

>> 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.
> This sounds sensible to me, but we'd need several things to come
> together to make this happen, not least is loading the source maps
> lazily.
>>> - 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.
> Dave? :-)

More information about the firefox-dev mailing list