1982271 - Unable to open `webpack-internal:///./` source from console stack trace

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P3)

Description

[mattheww]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0

Steps to reproduce:

I opened a page with the following, then clicked on the error line for test.js in the console.

<!DOCTYPE html>
<html>
<head>
<META charset="utf-8">
</head>
<body>
<script>
const runme = function() {
    throw new Error("oops");
}

runme();
//# sourceURL=webpack-internal:///./test.js
</script>
</body>
</html>

Actual results:

I was taken to the invalid URL page ("Hmm. That address doesn’t look right.")

Expected results:

I should have been taken to the specified location in the debugger.

I looked into this, and it appears that the debugger is receiving normalized URLs (ie webpack-internal:///test.js) but the stack trace and click handler are using the raw URL with the leading ./: webpack-internal:///./test.js.
I haven't tested with other schemas or with other approaches such as relative URLs or source maps.
I'm not sure it's related, but I think this is interfering with source mapping as well: in real life, the errors I've been encountering this bug on are occurring in application code and definitely not webpack.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'DevTools::Debugger' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Julian Descottes [:jdescottes]]

Bomsy, try to reproduce and if not ask for a complete test example.

Comment 3

[Julian Descottes [:jdescottes]]

Hi Matthew, can you share a small test case we can use to reproduce the bug?
Only the HTML page doesn't seem to be enough to reproduce the problem. Thanks

Comment 4

[mattheww]

Attachment: bug demo

Comment 5

[mattheww]

That's very strange. I downloaded the html snippet and was able to reproduce it just now in FF Nightly on MacOS 26. I'm also able to reproduce it in FF 142 on Windows 11 and on Linux. It doesn't seem to matter whether I serve the file or open it directly as a file:// url.

1. open the page
2. open devtools by hitting f12
3. go to the console tab
4. click the line on the left that says "runme webpack-internal:///./test.js:9"
5. get taken to view-source:webpack-internal:///test.js in a new tab, which shows an error message

The link on the right, ff-webpack-bug.html:9:11, works fine. So does setting a breakpoint in the debugger, or checking "Pause on Exceptions". It's only the individual lines in the stacktrace that don't work.
Stack trace links shown on requests in the Network tab also don't work - probably the same underlying bug?

Comment 6

[Julian Descottes [:jdescottes]]

Attachment: test_case.html

Comment 7

[Julian Descottes [:jdescottes]]

Attachment: test_case_2.html

Comment 8

[Alexandre Poirot [:ochameau]]

Attachment: Bug 1982271 - [devtools] Handle unresolved URLs when opening sources from the console. r=#devtools

It may only occur when using //# sourceURL= trick, but if any source URL
from the console isn't resolved, it won't match the source in the debugger
as the debugger always use resolved URLs.

Also the stacktraces objects are only exposing source URL+line+column
and no source object/actor, so we are using the URL fallback mechanism.
But ideally, the stacktrace would somehow expose the precise source object (bug 1641121).

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/aaf8f6039924
https://hg.mozilla.org/integration/autoland/rev/ac4bb917dee9
[devtools] Handle unresolved URLs when opening sources from the console. r=devtools-reviewers,bomsy

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/ac4bb917dee9