Browser source maps

Fitzgerald, Nick nfitzgerald at
Tue Oct 8 20:52:12 UTC 2013

On 10/8/13 4:12 AM, 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.
> 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?

Assuming that and friends are the tool that takes files
with "#include blah" and sticks the other file's text into the built
version of the file, then yes, this is where you should be making changes.

Maybe this article I wrote for hacks.m.o might help you:

Regarding mapping changes: Once built, the generated JS file has a "//#" which links to its source map. The source
map provides bi-directional mapping between {generatedLine,
generatedColumn} and {originalSource, originalLine, originalColumn}. As
soon as you change either the generated JS file, or the original
sources, those mappings become invalid. Source maps don't work with
changes, it is assumed that you are (a) not changing generated files by
hand, and (b) recreating the generated file and source map whenever you
change the original sources.

> 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.

Cool! Can you link some test output from so I can see what the
mappings look like?

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

I don't work with preprocessed files in our code base, so it wouldn't
make a large difference to me, but I imagine that if I did, I would be
going crazy without source maps.

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

One possible solution is to embed the text of the original sources into
the source map via the "sourcesContent" property, and then to embed the
whole source map into the generated source via a data URI. This way, we
can unask the above questions, and don't need to worry about maintaining
source maps and original sources for every build.

This is what browserify and a few other build tools do with great
success when you know you are making a build that isn't going to production.

> - 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.?

Of course, if we embed the source maps, we probably shouldn't do it for
the releases.

> - 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