Browser source maps
gijskruitbosch at gmail.com
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 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
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! :-)
More information about the firefox-dev