1848936 - console.error() called from sourcemapped WASM does not show resolved file name and line number in console

Status: UNCONFIRMED

(DevTools :: Console, defect, P3)

Description

[Mark Tolmacs]

Attachment: firefox-wasm-panic.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Built and ran a WASM example app at https://github.com/mtolmacs/wasm2map/tree/firefoxtest then checked the devtools web console for the error stack.

The WASM app issues a console.error call to test sourcemap name resolution.

Actual results:

The console message for the stack frames from the sourcemapped WASM does not resolve the original file name and line number as Chrome devtools can.

Curiously, clicking on the links takes me to the proper source file in the debugger.

Expected results:

The stack frames from the sourcemapped WASM show the original file names and line numbers.

Comment 1

[Mark Tolmacs]

Attachment: Same effect in Chrome devtools resolve properly

Comment 2

[Mark Tolmacs]

It seems that the issue is that in devtools/client/shared/source-map-loader/source-map.js the getOriginalLocationSync(...) flips the wasm column and line number when the sourcemap is queries. I saw that the tests already use a devtools\client\shared\source-map-loader\utils\wasmRemap.js wrapper for the 'map' parameter, so applying that in the getOriginalLocationSync() fixes the source file, line and column resolution.

Unfortunately the WASM file sourcemap is not loaded, unless it is opened in the debugger and the whole window is reloaded. I also found a reference to this behavior as being the intended way in the tests (devtools\client\debugger\test\mochitest\browser_dbg-features-wasm.js).

Comment 3

[Mark Tolmacs]

TL;DR: Even with the line-column transpose the sourcemap for WASM is not loaded, unless the debugger loaded it. I'd like to make a case below to allow lazy loading the WASM to extract the sourceMappingURL when the user explicitly intends to use it.

--

Additionally, most likely because of 093bfc2ab581 [1] the sourceMappingURL custom section is not parsed (and subsequently the sourcemap URL service's resource listener won't get the sourceMapURL attribute for WASM sources), unless the WASM is loaded into the debugger. I've found indications to this at the Debugger.Source documentation and in the debugger source code, and comments in the patch referred above suggest that this is still the intended behavior due to memory concerns regarding the debug representation in the debugger.

However the source map URL service could selectively load the WASM from cache and extract the sourceMappingURL section when it's missing, without a significant memory overhead (to my understanding). Since the source mapping service is only invoked when the user is explicit about seeing debug information (in this case, opening the console and/or a stack trace), arguably there is user intent behind it and only affect a subset of users who use the console.

I'm happy to contribute a patch if this is an acceptable solution. Otherwise I'll just address the line-column transpose. Please let me know.

[1] Thanks for pointing me to it nchevobbe from chat.mozilla.com!