Testcase: http://htmlpad.org/console-source-url/ Note that `console.log(foo)` does respect //# sourceURL but uncaught errors that get logged to the console do not.
Gentle ping, FF 51 would still fail to show the sourceURL file when the inlined script throws or logs and error, e.g. <script> var s; s = document.createElement('script'); s.textContent = `x.y.z = a.b.c;\n//# sourceURL=script-0.js\n`; document.body.appendChild(s); s = document.createElement('script'); s.textContent = `x.y.z = a.b.c;\n//# sourceURL=script-1.js\n`; document.body.appendChild(s); </script> ^ does show in the console that there are 2 errors, but only shows script-0 in the stack (instead of considering them as separate errors coming from 2 files).
console.log works because, ultimately, the URL for the stack entry comes from this code, which uses the display URL when available: https://dxr.mozilla.org/mozilla-central/rev/bdb2387396b4a74dfefb7c983733eed3625e906a/js/src/vm/SavedStacks.cpp#1570-1571 The stack trace for the error shows the display URL as well, for the same reason. I still haven't found where the location associated with the ReferenceError line itself is computed. Perhaps using the displayURL at the lowest level like this is maybe not the best approach, though. This approach makes the "script-1.js" text un-clickable in the console, because the source isn't known to the debugger - but maybe if we did client-side remapping like we do for source maps, we could show the display name and have clicking work.
> I still haven't found where the location associated with the ReferenceError line itself is computed. Maybe here, just based on reading code, didn't try the debugger: https://dxr.mozilla.org/mozilla-central/rev/bdb2387396b4a74dfefb7c983733eed3625e906a/js/src/jsexn.cpp#1044-1046