STR: 1. Visit http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.html 2. Open page console, which reads pre-main prep time: 160 ms wasm_trap.html:1249:13 RuntimeError: integer divide by zero wasm_trap.js:1297:1 _main http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.js:1297:1 Module._main http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.js:2352:51 callMain http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.js:2488:15 doRun http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.js:2552:42 run/< http://clbri.com/dump/wasm_trap_uncaught/wasm_trap.js:2563:7 3. Click on the link "wasm_trap.js:1297:1" Observed: a. The link wasm_trap.js:1297:1 is incorrect, but should read something like wasm_trap.wasm:542545353534 b. Clicking on the link currently takes to the location of the parent JS function (the line where main() was called, see screenshot), but should instead open wasm debugger to point to the line of the instruction that generated the integer divide by zero.

I think part (b) is a dup of bug 1291409.

Entire issue is console related, moving it to the right component. Debugger breaks at right source location and opens correct source shows right operation (e.g. pause on exception is enabled).

Smaller test case is at https://mdn.github.io/webassembly-examples/js-api-examples/fail.html

If we implement WASM support in the debugger, we'd better support it as well in the console.

AFAICT the source coming from the engine (or at least, Services.console.getMessageArray()) is wrong. Here's what the frontend sends to the server when the console is first opened: {"to":"server1.conn0.child1/consoleActor2","type":"getCachedMessages","messageTypes":["PageError","ConsoleAPI"]} This message is a PageError, which hits [0] then [1] in the server js. Then this packet gets returned to the frontend: {"from":"server1.conn0.child1/consoleActor2","messages":[{"errorMessage":"RuntimeError: integer divide by zero","errorMessageName":"JSMSG_WASM_INT_DIVIDE_BY_ZERO","sourceName":"https://mdn.github.io/webassembly-examples/wasm-utils.js","lineText":"","lineNumber":68,"columnNumber":1,"category":"content javascript","timeStamp":1506372268074,"warning":false,"error":false,"exception":true,"strict":false,"info":false,"private":false,"stacktrace":null,"notes":null,"_type":"PageError"}]} After that, the frame component [2] renders it out as returned. [0]: https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webconsole.js#832 [1]: https://dxr.mozilla.org/mozilla-central/source/devtools/server/actors/webconsole/listeners.js#133 [2]: https://dxr.mozilla.org/mozilla-central/source/devtools/client/shared/components/frame.js

This now works, if the wasm module was compiled from a fetch()ed Response. That's probably good enough.