Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Source maps not working with Firefox #681

Closed
graue opened this issue Feb 27, 2014 · 35 comments
Closed

Source maps not working with Firefox #681

graue opened this issue Feb 27, 2014 · 35 comments
Labels

Comments

@graue
Copy link

@graue graue commented Feb 27, 2014

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

This comment has been minimized.

Copy link

@486 486 commented Mar 4, 2014

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

@thlorenz

This comment has been minimized.

Copy link
Collaborator

@thlorenz thlorenz commented Mar 4, 2014

@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

This comment has been minimized.

Copy link

@michaelficarra michaelficarra commented Mar 4, 2014

@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

This comment has been minimized.

Copy link
Collaborator

@thlorenz thlorenz commented Mar 4, 2014

@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

This comment has been minimized.

Copy link
Author

@graue graue commented Mar 4, 2014

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

This comment has been minimized.

Copy link
Author

@graue graue commented Mar 4, 2014

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

This comment has been minimized.

Copy link
Collaborator

@thlorenz thlorenz commented Mar 4, 2014

@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

This comment has been minimized.

Copy link

@486 486 commented Mar 5, 2014

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

This comment has been minimized.

Copy link

@adamfaulkner adamfaulkner commented Mar 11, 2014

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

This comment has been minimized.

Copy link

@kirbysayshi kirbysayshi commented Apr 4, 2014

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

This comment has been minimized.

Copy link

@aliwatters aliwatters commented May 30, 2014

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
browserify-firefox-sourcemaps

Chrome 35
browserify-chrome-sourcemaps

@TooTallNate

This comment has been minimized.

Copy link
Contributor

@TooTallNate TooTallNate commented Jun 3, 2014

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

@wprater

This comment has been minimized.

Copy link

@wprater wprater commented Jun 21, 2014

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

@QuentinFchx

This comment has been minimized.

Copy link

@QuentinFchx QuentinFchx commented Jul 22, 2014

any updates on this ?

@dminkovsky

This comment has been minimized.

Copy link

@dminkovsky dminkovsky commented Aug 13, 2014

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

@mattdesl

This comment has been minimized.

Copy link
Contributor

@mattdesl mattdesl commented Sep 15, 2014

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

This comment has been minimized.

Copy link

@WickyNilliams WickyNilliams commented Sep 22, 2014

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

@felixhammerl

This comment has been minimized.

Copy link

@felixhammerl felixhammerl commented Oct 20, 2014

👍

@kumarharsh

This comment has been minimized.

Copy link

@kumarharsh kumarharsh commented Oct 30, 2014

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

This comment has been minimized.

Copy link

@hydra1983 hydra1983 commented Nov 6, 2014

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

@kumarharsh

This comment has been minimized.

Copy link

@kumarharsh kumarharsh commented Nov 7, 2014

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

This comment has been minimized.

Copy link

@mechkit mechkit commented Nov 14, 2014

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

This comment has been minimized.

Copy link

@fitzgen fitzgen commented Jan 7, 2015

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

This comment has been minimized.

Copy link

@AbdullahDiaa AbdullahDiaa commented Jan 20, 2015

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 terinjokes added the support label Apr 24, 2015
@terinjokes

This comment has been minimized.

Copy link
Contributor

@terinjokes terinjokes commented Apr 24, 2015

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

This comment has been minimized.

Copy link

@jlongster jlongster commented May 18, 2015

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

This comment has been minimized.

Copy link
Collaborator

@jmm jmm commented May 18, 2015

@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

This comment has been minimized.

Copy link
Member

@zertosh zertosh commented May 19, 2015

@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

This comment has been minimized.

Copy link
Collaborator

@jmm jmm commented May 19, 2015

@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

This comment has been minimized.

Copy link
Member

@zertosh zertosh commented May 19, 2015

@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

This comment has been minimized.

Copy link
Collaborator

@jmm jmm commented May 19, 2015

@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

This comment has been minimized.

Copy link
Member

@zertosh zertosh commented May 19, 2015

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

This comment has been minimized.

Copy link
Collaborator

@jmm jmm commented Jun 25, 2015

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 comment has been minimized.

Copy link
Collaborator

@jmm jmm commented Jun 25, 2015

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

@jmm jmm closed this Jun 25, 2015
@Ghazgkull

This comment has been minimized.

Copy link

@Ghazgkull Ghazgkull commented Sep 10, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.