Browser source maps

Gijs Kruitbosch gijskruitbosch at gmail.com
Tue Oct 8 16:47:06 UTC 2013


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?
https://groups.google.com/d/msg/firefox-dev/iBfdJZe-4YU/6UwopdTBwhEJ
> 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.

> 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.
https://bugzilla.mozilla.org/show_bug.cgi?id=924448


>> 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? :-)

~ Gijs



More information about the firefox-dev mailing list