1090768 - Error loading source: loadSourceError when trying to load source maps

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[(not reading bugmail) Nick Desaulniers [:\n]]

Attachment: crash.zip

I keep getting the following error in the debugger when browsing the source tab under the debugger tab when using source maps generated from emscripten:

Error loading source:
loadSourceError

in Nightly 36.0a1 (2014-10-28), though not in FF 33.0.  See attached case.  The debugger can correctly identify the source files as esUtil.c and Hello_Triangle.c rather than CH02_HelloTriangle.js, just not show the source.

Comment 1

[Kumar Harsh]

I'm getting this error in FF 33.0.2

I have bundled my app files with Browserify, and the generated source maps are embedded into the bundled code as a base-64 encoded url starting as:

```
//# sourceMappingURL=data:application/json;base64,ey........fQ==
```

Chrome correctly reads the sourcemap and shows the original coffee files,
but in the Firefox DevTools, only the original `*.js` files are shown, but all `*.coffee` files show the error 

```
Error loading source:
loadSourceError
```

Comment 2

[David Caldwell]

I am getting this error, too. FF 35 and 36 on Mac OS X.

I noticed something though: My browserify source maps get the "loadSourceError" message, but my uglify source maps work correctly. After poking around I determined that my browserify "loadSourceError" was caused by the "sourcesContent" key in the source map JSON (browserify adds that key to the maps it generates, but uglify doesn't). If I remove the "sourcesContent" key from my browserify source maps then Firefox loads them correctly.

I don't know what specifically about sourcesContent is causing Firefox to barf, though.

Comment 3

[Zimon Dai [:zimonD]]

getting the error using source map via Webpack, too.
With/without base64 encoding does not affect the result

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Allow ./ prefix in source paths

This allows the source content to appear for the test case in comment 0.

However, it's not enough for breakpoints to hit in the original sources.  I am guessing that is a separate problem to resolve.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8537959 [details] [review]
Allow ./ prefix in source paths

Nick approved and merged the PR.

https://github.com/mozilla/source-map/commit/ad8c0757ce3b8611d7a612ac66a1fdfe24dd1159

Comment 6

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Update to source-map 0.1.41

Merge the updated source-map library with fix.

This fixes the case in comment 0 of sources not appearing at all.  It does not make breakpoints work for the original sources.  I am told by fitzgen that this is being worked on in other bugs.

If this does not work for the other commenters here, please file separate bugs and attach test cases.

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=481e167ce24e

Comment 7

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Comment on attachment 8538001 [details] [diff] [review]
Update to source-map 0.1.41

Review of attachment 8538001 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/2c56d1e64245

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2c56d1e64245

Comment 10

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Comment on attachment 8538001 [details] [diff] [review]
Update to source-map 0.1.41

Approval Request Comment
[Feature/regressing bug #]: Seems like a longstanding bug in our source map implementation
[User impact if declined]: Certain types of source maps fail to load in the debugger, leaving a vague error
[Describe test coverage new/current, TBPL]: Landed in m-c with tests
[Risks and why]: Low, updating our source-map library with a well tested API
[String/UUID change made/needed]: None

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 8538001 [details] [diff] [review]
Update to source-map 0.1.41

Not enough significant user impact to justify taking this so late in Beta cycle, would prefer to avoid unnecessary churn and let this ride from 36.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/8fdaee948874

Comment 13

[flying sheep]

hmm, i’m using firefox 36.1 and still only see

Error loading source:
loadSourceError

is this a separate bug?

Comment 14

[Zimon Dai [:zimonD]]

(In reply to flying sheep from comment #13)
> hmm, i’m using firefox 36.1 and still only see
> 
> Error loading source:
> loadSourceError
> 
> is this a separate bug?

As the bug says, target version is firefox 37, so 36.1 may still be effected. I didn't test that..

Comment 15

[flying sheep]

developer edition is also affected so that can’t be it.

the thing going wrong is that the source path doesn’t point to a valid file (resolving the path leads to a 404 page)

the error message should reflect that, not be this generic.

Comment 16

[Zimon Dai [:zimonD]]

(In reply to flying sheep from comment #15)
> developer edition is also affected so that can’t be it.
> 
> the thing going wrong is that the source path doesn’t point to a valid file
> (resolving the path leads to a 404 page)
> 
> the error message should reflect that, not be this generic.

Maybe you could provide a test case?

Comment 17

[flying sheep]

you can easily trigger it by loading any source map without creating a server.

the map itself is loaded from a file:// URL, but the source .js files aren’t.

Comment 18

[Mateus Zitelli]

I'm still having a problem with evaluated embedded source maps generated by Webpack, in the following format:

//# sourceMappingURL=data:application/json;base64,...

When some error is displayed the devtools shows a reference link to the place of occurrence like this:

main.js line 88 > eval:43:69

That redirects to the folowing link /assets/main.js%20line%2088%20%3E%20eval, resulting in a not found file.

Decoding the base64 JSON the source reference is:

"sources": [
    "webpack:///./src/scripts/routes.js?3a00"
  ]

Just to notice this exact error is well referenced by chromium and it was tested in Firefox 39.0a2.

Comment 19

[bmf]

This is not fixed for me in Firefox 39.0.  Given the following file, called "content.js.map", I get the error:

Error loading source:
loadSourceError

Here is the file content:

{"version":3,"sources":["app/content/content.js"],"names":[],"mappings":"AAAA,OAAO,SAAS,CAAC,WAAW,oBAAoB,uCAAuC,wBAAwB,iBAAiB,mBAAmB,UAAU,SAAS;EACpK,IACK,SAEA,UAKD;EAPJ,OAAO;IACL,SAAS,CAAC,UAAU,UAAU;MAD3B,UAAO,SAAA;OAGP,UAAU,kBAAkB,IAAI,UAAU,mCAAmC;MAD7E,WAAQ,kCAAA;OAGR,UAAU,oBAAoB,IAAI,UAAU,aAAa,IAAI,UAAU,aAAa;IACvF,SAAS,YAAY;MARzB;;MASM,gBAAgB,QAAQ,OAAO,WAAW,CAC9C,SAAS,MACT,gCACA;;MAGF,cAAc,0BAAO,UAAS,gBAAe;QAC3C,eAAe,MAAM,WAAW;UAC9B,KAAK;UACL,aAAa;UACb,YAAY;UACZ,cAAc;UACd,cAAc;;;;MAEZ,QAAQ,WAEC;;;GACZ","file":"app/content/content.js","sourcesContent":["'use strict';\n\nimport angular from 'angular';\nimport 'angular-material';\nimport mainwrap from 'common/directives/mainwrap/mainwrap';\nimport './content.controller';\nimport './content.tpl';\nimport './content.css!';\n\nconst contentModule = angular.module('content', [\n  mainwrap.name,\n  'app/content/content.tpl.html',\n  'content.controller.js'\n]);\n\ncontentModule.config(function($stateProvider){\n  $stateProvider.state('content', {\n    url: '/content',\n    templateUrl: 'app/content/content.tpl.html',\n    controller: 'ContentCtrl',\n    controllerAs: 'contentCtrl',\n    authenticate: true\n  });\n});\n\nexport default contentModule;\n"],"sourceRoot":"/source/"}

Comment 20

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to bmf from comment #19)
> This is not fixed for me in Firefox 39.0.  Given the following file, called
> "content.js.map", I get the error:
> 
> Error loading source:
> loadSourceError
> 
> Here is the file content:
> 
> {"version":3,"sources":["app/content/content.js"],"names":[],"mappings":
> "AAAA,OAAO,SAAS,CAAC,WAAW,oBAAoB,uCAAuC,wBAAwB,iBAAiB,mBAAmB,UAAU,SAAS;EACpK,
> IACK,SAEA,UAKD;EAPJ,OAAO;IACL,SAAS,CAAC,UAAU,UAAU;MAD3B,UAAO,SAAA;OAGP,UAAU,
> kBAAkB,IAAI,UAAU,mCAAmC;MAD7E,WAAQ,kCAAA;OAGR,UAAU,oBAAoB,IAAI,UAAU,aAAa,
> IAAI,UAAU,aAAa;IACvF,SAAS,YAAY;MARzB;;MASM,gBAAgB,QAAQ,OAAO,WAAW,CAC9C,SAAS,
> MACT,gCACA;;MAGF,cAAc,0BAAO,UAAS,gBAAe;QAC3C,eAAe,MAAM,WAAW;UAC9B,KAAK;UACL,
> aAAa;UACb,YAAY;UACZ,cAAc;UACd,cAAc;;;;MAEZ,QAAQ,WAEC;;;GACZ","file":"app/
> content/content.js","sourcesContent":["'use strict';\n\nimport angular from
> 'angular';\nimport 'angular-material';\nimport mainwrap from
> 'common/directives/mainwrap/mainwrap';\nimport
> './content.controller';\nimport './content.tpl';\nimport
> './content.css!';\n\nconst contentModule = angular.module('content', [\n 
> mainwrap.name,\n  'app/content/content.tpl.html',\n 
> 'content.controller.js'\n]);\n\ncontentModule.
> config(function($stateProvider){\n  $stateProvider.state('content', {\n   
> url: '/content',\n    templateUrl: 'app/content/content.tpl.html',\n   
> controller: 'ContentCtrl',\n    controllerAs: 'contentCtrl',\n   
> authenticate: true\n  });\n});\n\nexport default
> contentModule;\n"],"sourceRoot":"/source/"}

Thanks for the report! I just filed a new bug to track your issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1188697

Can you add your test case there? It would be really helpful if you could provide a complete web page we could load and reproduce the bug on instead of just the source map. Also which source(s) are failing to load, etc. Thanks again!