Say for example you have the following structure:

1. A simple index.html
2. It creates a <script> tag loading from a URL
3. That script then has a //# sourceMappingURL=data:application/json;base64,... comment with a sourcemap as a data URL

That sourcemap will have an array of source file URLs like project/app.js and such, or as is also common with Webpack webpack:///project/app.js.

If we look at this "original file" source URL, what is the full absolute URL to render in the sidebar? webpack:///project/app.js is already an absolute URL, so that's not too bad at least. But what about project/app.js? It's in JSON file whose URL is a data: URL, so you can't exactly make the final URL absolute because data: URLs are not valid as a base URL.
The debugger currently works around this by recognizing that it isn't a valid base, and instead using the URL of the JS file itself instead.

The question then is, what if the JS file is also not something that can be used as a base URL, like data: or blob:?

This currently causes some users to get errors like this:

Source map error: Error: Invalid URL: .

Resource URL: blob:https://localhost:3001/1a388914-e241-41d0-8283-066b5706216f

Source Map URL: data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJzb3VyY2VzIjpbIndlYnBhY2s6Ly8vd2VicGFjay9ib290c3RyYXAiLCJ3ZWJwYWNrOi8vLy4vbm9kZV9tb2R1bGVzL2NvbG9yL2luZGV4LmpzIiwid2VicGFjazovLy8uL25vZGVfbW9kdWxlcy9jb2xvci1uYW1lL2luZGV4LmpzIiwid2VicGFjazovLy8uL25vZGVfbW9kdWxlcy9jb2xvci1jb252ZXJ0L2NvbnZlcnNpb25zLmpzIiwid2VicGFjazovLy8uL3NyYy93b3JrZXJzL2NvbG9yLXNoaWZ0Lndvcmtlci5qcyIsIndlYnBhY2s6Ly8vLi9ub2RlX21vZHVsZXMvY29sb3Itc3RyaW5nL2luZGV4LmpzIiwid2VicGFjazovLy8uL25vZGVfbW9kdWxlcy9zaW1wbGUtc3dpenpsZS9pbmRleC5qcyIsIndlYnBhY2s6Ly8vLi9ub2RlX21vZHVsZXMvc2ltcGxlLXN3aXp6bGUvbm9kZV9tb2R1bGVzL2lzLWFycmF5aXNoL2luZGV4LmpzIiwid2VicGFjazovLy8uL25vZGVfbW9kdWxlcy9jb2xvci1jb252ZXJ0L2luZGV4LmpzIiwid2VicGFjazovLy8uL25vZGVfbW9kdWxlcy9jb2xvci1jb252ZXJ0L3JvdXRlLmpzIl0sIm5hbWVzIjpbImluc3RhbGxlZE1vZHVsZXMiLCJfX3dlYnBhY2tfcmVxdWlyZV9fIiwibW9kdWxlSWQiLCJleHBvcnRzIiwibW9kdWxlIiwiaS…

because there is some tooling, like https://github.com/webpack-contrib/style-loader/issues/303#issuecomment-547223707 and probably others, that specifically creates blob-URL script elements.

To handle this, we could consider going one step further up and using the URL of the document that contains the script, if the script is a valid base. If it's not valid but it's in an iframe and is about:blank page or data:, we could go even further by trying to use the URL of its owner document, potentially traversing all the way up through all same-origin iframes?

None of this is specified, but Chrome does do at least some of this where we do not, which is why tooling like the style-loader case above work on Chrome but not Firefox.

The priority flag is not set for this bug.
:jlast, could you have a look please?

For more information, please visit auto_nag documentation.

Depends on D72104

Depends on D72105

Depends on D72106

Depends on D72107

Depends on D72115

Backed out for causing xpc failures on xpcshell/test_objectgrips-13.js. CLOSED TREE

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception&revision=15642af7fdbdc2e30a5dbc7bc3585bc791969c02&searchStr=xpc&selectedJob=299181826

Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=299181826&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/1f5dca62d40284dc15d3472233e4c1da588fd9bd

Looks like the failures are Windows-only, so maybe something in URL parsing varies by OS? :(

https://hg.mozilla.org/mozilla-central/rev/4a35dd55dfe7
https://hg.mozilla.org/mozilla-central/rev/54d0bf5e487b
https://hg.mozilla.org/mozilla-central/rev/9ee00a06fd78
https://hg.mozilla.org/mozilla-central/rev/68336664883a
https://hg.mozilla.org/mozilla-central/rev/c9955025d4a5