Source maps not working with Firefox

[graue]

Firefox has partial support for source maps. The Console tab doesn't use them yet, but ClojureScript's source maps are working fine for me in the Debugger tab. Browserify's do not.

The issue seems to be full pathnames in the source map's "sources" key:

    "sources": [
        "/home/graue/code/projectname/node_modules/browserify/node_modules/browser-pack/_prelude.js",
        "/home/graue/code/projectname/node_modules/backbone/backbone.js",
        "/home/graue/code/projectname/node_modules/bean/bean.js",
        "/home/graue/code/projectname/node_modules/browserify/node_modules/buffer/index.js",
        "/home/graue/code/projectname/node_modules/browserify/node_modules/buffer/node_modules/base64-js/lib/b64.js",
        "/home/graue/code/projectname/node_modules/browserify/node_modules/buffer/node_modules/ieee754/index.js",
        ...
    ]

If I remove the beginnings of each path so all the pathnames are relative to the project root, e.g.

        "node_modules/browserify/node_modules/browser-pack/_prelude.js",
        "node_modules/backbone/backbone.js",

then base64-encode the modified source map and stick it back into the Browserify bundle, Firefox's debugger is happy (and Chrome's still is, too).

I've done this manually but may be able to work on a PR for this later, if making Browserify use relative paths is seen as an acceptable change and the best way to go here. Let me know if that sounds like a good plan.

[486]

Would be very interested in that fix because Browserify code is basically not debuggable in Firefox right now.

[thlorenz]

@graue this looks like it's actually a bug in firefox, it should work.

However as a workaround you could use convert-source-map to fix them manually or the higher level mold-source-map which was made exactly for that purpose - specifically see this example.

Additionally could you please file a bug with firefox and link it here?

Thanks.

[michaelficarra]

@thlorenz: This is not a Firefox bug. The source should be (and is being) resolved against the source map location. If the source map is hosted anywhere but file:///..., the source path will be resolved relative to the host name/IP. If you want to include full filesystem paths, browserify needs the protocol as well to treat it as absolute rather than relative to the source map. Using relative paths is preferred in order to make the map agnostic to its hosting environment, though avoid using sourceRoot due to its poor support, particularly in Firefox.

[thlorenz]

@michaelficarra ok, I wasn't aware of that.

However browserify sourcemaps include the sourcesContent for each file, so the browser actually doesn't have to resolve/load them.

Does it still matter then?
However if theses paths are just plain wrong and chrome is happy either way we should fix it here. It should be a rather minor change.

[graue]

Can anyone else confirm running into the bug I described? @486 ?

I've been unsuccessful reproducing this bug with a different project.

What I described above was with a work codebase that I unfortunately can't open-source.

This small test-case is using the same version of Browserify, has similar absolute paths for the sources key in the source map, and I'm trying it with the same version of Firefox (27, on Linux), and yet, it works fine. And this medium-sized, open-source project using Browserify does not exhibit the problem, either.

So I'm very confused as to what may be different and why only one project would (consistently!) trigger this bug.

[graue]

Here's the full error I get in Firefox's Debugger window with the bug (part of the file path redacted):

Error loading source:
Could not load the source for http://localhost/home/graue/projectname/node_modules/browserify/node_modules/browser-pack/_prelude.js.
Error: "http://localhost/home/graue/projectname/node_modules/browserify/node_modules/browser-pack/_prelude.js" is not in the SourceMap.
Stack: SourceMapConsumer_sourceContentFor@resource://gre/modules/devtools/SourceMap.jsm:387
SA__getSourceText@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2418
resolve@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:118
then@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:43
then@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:153
SA_onSource@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2437
DSC_onPacket@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js:1019
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/transport.js:258
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/DevToolsUtils.js:75

Poking around in the Firefox devtools source has only left me more confused, since the line throwing the error apparently only executes if the source map has a sourceRoot set, but this source map does not set a sourceRoot.

[thlorenz]

@graue are you including sourcesContent in the bigger project as well?
I'm confused why Firefox would try to load the source for the files if it is already included for each file via that soucrcesContent array.

[486]

I have been using the browserify-grunt task to build. To make sure that this is not the problem, I made a build directly with browserify:

My project structure is:

Base path: ~/IdeaProjects/cdk-umbrella/cdk/client/src
src contains:
cdk,js (main file)
lib (dependencies)
Also I pull some dependencies from a node_modules folder on a higher level.

From src folder, I execute:

browserify --debug cdk.js --outfile browserified-cdk.js 

The built file is served via connect on a vhost with the name www.examplecdk.tld. I made a sample html where the built file is loaded.

• In the console, there is an error saying:

Error: https://www.examplecdk.tld/dist/browserified-cdk.js is being assigned a //# sourceMappingURL, but already has one

• When opening the FF debugger, all the dependencies are listed separately, i.e. client.js. But when clicking on client.js, the content section says:

Could not load the source for https://www.examplecdk.tld/home/user486/IdeaProjects/cdk-umbrella/cdk/client/src/cdk/client.js.
Error: "https://www.examplecdk.tld/home/user486/IdeaProjects/cdk-umbrella/cdk/client/src/cdk/client.js" is not in the SourceMap.
Stack: SourceMapConsumer_sourceContentFor@resource://gre/modules/devtools/SourceMap.jsm:387
SA__getSourceText@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2418
resolve@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:118
then@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:43
then@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/commonjs/sdk/core/promise.js:153
SA_onSource@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2437
DSC_onPacket@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js:1019
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/transport.js:258
@resource://gre/modules/devtools/dbg-server.jsm -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/DevToolsUtils.js:75

• I must admit that I haven't a good understanding of source maps so, I guess the path in the stack trace above is correct?
• In Chrome, all works fine.
• Unfortunately, I cannot post the code as it is a commercial project.

One interesting thing to note:
Before, my vhost was www.example-cdk.tld (note the minus). With that, the path in the above error message read:

https://www.example/home/user486/IdeaProjects/cdk-umbrella/cdk/client/src/cdk/client.js

Note that "-cdk.tld" is absent.

[adamfaulkner]

Hi, I'm having the same problem, and thought I'd chime in here.

It looks like Firefox has some issue using the sourcesContent array when using an absolute file path. I found a couple of issues for this on Mozilla's bug tracker (https://bugzilla.mozilla.org/show_bug.cgi?id=882986 and https://bugzilla.mozilla.org/show_bug.cgi?id=852792), both of which are supposedly fixed. However, I'm still having this problem even in the Aurora build of Firefox.

I was able to work around this problem by using mold-source-map to change the paths to relative file paths. The actual paths didn't matter, as long as they were relative.

[kirbysayshi]

I just had the same problem in FF Aurora 30a2, using mold-source-map did the trick:

brfs.bundle({ debug: true })
  .pipe(mold.transformSourcesRelativeTo(__dirname))

In my case I was serving a browserified file so I was using browserify programmatically.

[aliwatters]

Ran into this problem on Firefox 29.0.1- @adamfaulkner @kirbysayshi - thanks, your fix also worked for me using gulp and https://github.com/thlorenz/mold-source-map

Additionally - although you can see the code in Chrome - the sources include the full path
I wonder if more people haven't run into this because they are running the browser and server on the same host (which I'm not)

Screen shots from https://github.com/aliwatters/sandbox/tree/master/2014/20140526-browserify-jquery
Firefox 29

Chrome 35

[TooTallNate]

@substack Any update on this? Is mold-source-map the officially sanctioned solution?

[wprater]

yeah, interested as well. the solution gets me past the error, but source maps are still not functioning in FF.

[QuentinFchx]

any updates on this ?

[dminkovsky]

Read this thread, and still not sure why this is happening. Is nobody debugging in Firefox or something?

[mattdesl]

Hmmm what's the deal with this? Still broken for me. mold-source-map isn't giving me source maps, but maybe my paths are wrong?

[WickyNilliams]

Don't know whether it's useful information but WebPack doesn't seem to have this issue

[felixhammerl]

👍

[kumarharsh]

I'm getting this error in Firefox 33.0.2:

Error loading source:
loadSourceError

I thought it was an issue with the base64 encoded source-map, so I used exorcist to take it out into another file, but still the same error is being shown for my main app.coffee file (although Firefox is correctly splitting the rest of the code into separate files in the debugger)

[hydra1983]

@kumarharsh get same error with browserify + es6ify. However, works in Chrome Version 38.0.2125.111

[kumarharsh]

Yes, I can confirm it works with Chrome.

But in firefox, the *.coffee files show this same error, although the *.js files map correctly.
Even using exorcist with browserify and taking out the sourcemap to a separate file doesn't help in that case.

[mechkit]

I get the same debugger error..

Error loading source:
loadSourceError

..in Firefox Developer Edition 35.0a2 (2014-11-14), and no mapping in console messages.
Not a great sign for a "developer edition". I guess it is back to Chrome.

[fitzgen]

I suspect this is https://bugzilla.mozilla.org/show_bug.cgi?id=1090768 / mozilla/source-map#145 and if so should be fixed in 36+

If anyone can still reproduce in Nightly, please file a bug with the test case: https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&component=Developer%20Tools%3A%20Debugger

[AbdullahDiaa]

Removing my home folder path from [preludePath and row.sourceFile] in node_modules/gulp-browserify/node_modules/browserify/node_modules/browser-pack/index.js solved the problem temporarily till the new update is pushed to firefox developer edition.

sourcemap.addFile(
{ sourceFile: preludePath, source: prelude },
{ line: 0 }
);
...
sourcemap.addFile(
{ sourceFile: row.sourceFile, source: row.source },
{ line: lineno }
);

[terinjokes]

I'm not sure why Firefox would fetch the content when they're included already, and the linked bug suggests it's fixed in Firefox 37. A PR can probably be opened up against browser-pack to make the paths relative for older versions.

[jlongster]

I believe this is still a bug in our end of the Firefox debugger. Looks like we aren't correctly checking the inlined source content of the sourcemap. I will fix this. See https://bugzilla.mozilla.org/show_bug.cgi?id=1166048

Note that the source URLs included in a browserify sourcemap do have a bug though: a file URL is include like /Users/james/foo/bar but it should be file:///Users/james/foo/bar. That is a webpack bug, it needs to be a URL. The reason most people don't notice is because it also inlines the source content.

[jmm]

@jlongster

Note that the source URLs included in a browserify sourcemap do have a bug though: a file URL is include like /Users/james/foo/bar but it should be file:///Users/james/foo/bar.

What values are you referring to, the elements of sources?

That is a webpack bug, it needs to be a URL.

Do you mean browserify?

[zertosh]

@jlongster Ah yeah don't set a sourceRoot. That's an easy fix. We already pass it to browser-pack, but don't do anything with it there. I'll test it later and merge a fix.

[jmm]

@zertosh

@jlongster Ah yeah don't set a sourceRoot. That's an easy fix. We already pass it to browser-pack, but don't do anything with it there. I'll test it later and merge a fix.

I'm not sure there's actually a bug here. I think the sources elements are always considered to be URLs (without protocol they're just relative to some base). And if the user agent never requests them, it doesn't matter to this degree what their values are. (A separate issue that does matter is if they leak information you don't want exposed, like absolute local paths).

[zertosh]

@jmm looking at the source map spec, i think you're right:

Line 4: An optional source root, useful for relocating source files on a server or removing repeated values in the “sources” entry. This value is prepended to the individual entries in the “source” field.

so source root is optional.

If the sources are not absolute URLs after prepending of the “sourceRoot”, the sources are resolved relative to the SourceMap (like resolving script src in a html document).

and the default behavior is sane. though we should use sourceRoot if provided in browser-pack, and remove it from the row.

[jmm]

@zertosh

though we should use sourceRoot if provided in browser-pack, and remove it from the row.

I haven't looked into it, but if browser-pack is supposed to accept a sourceRoot param and it's disregarding one passed to it, that does sound like a bug (and something that needs to be documented [you can see I currently have it stubbed in the pipeline docs]). Seems odd for that to be a row prop though -- seems more appropriate as an opt. Is that what you meant by "remove it from the row"?

As long as browserify is generating source maps with sourcesContent I don't think it should automatically be populating file:// in either sourceRoot or sources.

[zertosh]

Seems odd for that to be a row prop though -- seems more appropriate as an opt. Is that what you meant by "remove it from the row"?

Yup and yup.

As long as browserify is generating source maps with sourcesContent I don't think it should automatically be populating file:// in either sourceRoot or sources.

It should just be an option. I'll add it in browser-pack

[jmm]

I previously said:

As long as browserify is generating source maps with sourcesContent I don't think it should automatically be populating file:// in either sourceRoot or sources.

In case this comes up again in the future, I can't think of a reason for file:// or any URI scheme to be included in the source map output by default, with or without sourcesContent. By default the output should be setup so that the scheme flows from the base URL used in the specification's resolution algorithm.

[jmm]

This issue has become too dated and muddled to be actionable at this point and there's at least one open bug on Firefox that may be the problem. Also, I don't know when it changed, but by default browserify currently generates source maps with relative sources values. For those reasons I'm closing this issue. To anyone who is still having a problem in Firefox >= 37:

If it seems to be a Firefox bug, please follow up there.

Otherwise, please open a new issue here with a minimal reproduction in a repo and any other relevant information, such as Firefox version.

See:
https://bugzilla.mozilla.org/show_bug.cgi?id=1166048
https://bugzilla.mozilla.org/show_bug.cgi?id=882986
https://bugzilla.mozilla.org/show_bug.cgi?id=852792
https://bugzilla.mozilla.org/show_bug.cgi?id=1090768

[Ghazgkull]

Looks like this problem was just fixed by Firefox in version 42.0a2. (Download the FirefoxDeveloperEdition)