User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36 Steps to reproduce: My company combo-loads TypeScript compiled files and generates sourcemaps to mapped to sections of the combo-loaded file. Here is an snippet of a source map: { "version":3, "sections": [ ... { "offset": {"line":6,"column":0}, "map": { "version":3, "file":"View.js", "sourceRoot":"/usermanagement/GeneratedScripts/App/", "sources":["../../Scripts/App/View.ts"], "names":[], "mappings":"AAAA,6CAA6C" (and many others...) } }, { "offset": {"line":45,"column":0}, "map": { "version":3, "file":"AppApi.js", "sourceRoot":"/usermanagement/GeneratedScripts/App/", "sources":["../../Scripts/App/AppApi.ts"], "names":[], "mappings":"AAAA,+CAA+C (and many others...) } } ... ] } The relevant file structure of the sources: /usermanagement /Scripts /App View.ts AppApi.ts The relevant file structure of the generated files: /usermanagement /GeneratedScripts /App View.js AppApi.js These sourcemaps work in Chrome, but when opening the Debugger tab (Firefox 59.0) and clicking one of the original source files the following error appears: Error while fetching an original source: Error: "http://localhost:10400/usermanagement/Scripts/App/View.ts" is not in the SourceMap. Source URL: http://localhost:10400/usermanagement/Scripts/App/View.tsx However, the file does exist, i.e. navigating to the address in the error hits the appropriate file. I did some digging into the source code and it appears that the source content lookup follows the SourceContent spec and resolves the source url relative to the sourceroot. https://github.com/mozilla/gecko-dev/blob/b2624cd00e53604315c2b0946ad38d97dc4fd77e/toolkit/devtools/sourcemap/SourceMap.jsm#L361 However, when the sources object is created, the original source urls are stored as a concatentation of the source url and sourceroot instead of a relative resolution: https://github.com/mozilla/gecko-dev/blob/b2624cd00e53604315c2b0946ad38d97dc4fd77e/toolkit/devtools/sourcemap/SourceMap.jsm#L132, so it makes sense that the original source does not seem to be in the sourcemap if we are looking it up with a differently constructed key. If this is a bug, util.join is also used in this context on #331 and #475 of the same file as opposed to 8 uses of util.relative to construct the source url. Actual results: The source file tree correctly appeared, but when clicking on a source file the following error appeared: Error while fetching an original source: Error: "http://localhost:10400/usermanagement/Scripts/SearchBar.tsx" is not in the SourceMap. Source URL: http://localhost:10400/usermanagement/Scripts/SearchBar.tsx However, the file does exist, i.e. navigating to the address in the error hit the appropriate file. Expected results: Clicking on a mapped file should open the original source.

Hi Jason, I'm not sure if I understand correctly the issue, but can you please help me out with this report? Should it be moved to the "Developer Tools: Debugger" component? If yes, can you please guide me with the next actionable steps?

Yes, this is a debugger bug. Happy to look into it soon

Thanks egallagher. Two questions: 1) does this still appear on nightly? 2) do you think you could create a small test case for this? It could easily be an app with typescript/ tsx that you publish to github. These small apps make a huge difference for us when it comes to testing

FWIW there are plenty of other small examples here: https://github.com/tromey/source-map-examples Sometimes it's easy to modify one of these to suit.