Browser source maps

Gijs Kruitbosch gijskruitbosch at
Tue Oct 8 11:12:40 UTC 2013

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.

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.

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?)
- 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.?
- 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'm not sure what the answers to any of these questions should be, but 
I'm hoping some of you do! :-)

~ Gijs

More information about the firefox-dev mailing list