Closed Bug 1090768 Opened 10 years ago Closed 9 years ago

Error loading source: loadSourceError when trying to load source maps

Categories

(DevTools :: Debugger, defect)

31 Branch
x86
macOS
defect
Not set
normal

Tracking

(firefox34 wontfix, firefox35 wontfix, firefox36 fixed, firefox37 fixed)

RESOLVED FIXED
Firefox 37
Tracking Status
firefox34 --- wontfix
firefox35 --- wontfix
firefox36 --- fixed
firefox37 --- fixed

People

(Reporter: nick, Assigned: jryans, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Attached file 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.
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
```
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.
getting the error using source map via Webpack, too.
With/without base64 encoding does not affect the result
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.
Assignee: nobody → jryans
Status: NEW → ASSIGNED
Attachment #8537959 - Flags: review?(nfitzgerald)
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
Attachment #8537959 - Flags: review?(nfitzgerald) → review+
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
Attachment #8538001 - Flags: review?(nfitzgerald)
Comment on attachment 8538001 [details] [diff] [review]
Update to source-map 0.1.41

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

Thanks!
Attachment #8538001 - Flags: review?(nfitzgerald) → review+
https://hg.mozilla.org/integration/fx-team/rev/2c56d1e64245
Flags: in-testsuite+
Keywords: checkin-needed
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/2c56d1e64245
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 37
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
Attachment #8538001 - Flags: approval-mozilla-beta?
Attachment #8538001 - Flags: approval-mozilla-aurora?
Attachment #8538001 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
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.
Attachment #8538001 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
hmm, i’m using firefox 36.1 and still only see

Error loading source:
loadSourceError

is this a separate bug?
(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..
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.
(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?
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.
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.
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/"}
(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!
Flags: needinfo?(brian.feister)
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.