Currently, the asm.js compiler emits warnings on all successful and unsuccessful compilation attempts. This helps developers know that they are hitting their target and, if not, why. Devs wanting to play around with asm.js may want to use scratchpad or webconsole. One problem is that the informative warnings seem to be suppressed (I can see the JS engine sending them out to the error reporter but they aren't showing up in the UI). Could we un-suppress them?

In the web console case, do you know if the warnings are associated with the inner window ID of the current tab? I know there are (used to be?) some similar warnings/errors that didn't appear in the web console due to this missing ID in the past.

Just to be clear: the warnings are being generated from running code in the webconsole/scratchpad itself. I don't know what window ID gets associated with code run in this context. From the JS engine's perspective, we just call an "error reporter" black box which is somewhere in DOM-land.

Luke: how do you get the web console to turn on the asmjs target?

In scratchpad and in the web console we currently use a Cu.Sandbox to execute code and afaik that's js1.8 (please correct me if I am wrong). With bug 783499 we'll no longer use Cu.Sandbox in the web console. We will start using DebuggeeObject.evalWithBindings() and evalInGlobalWithBindings().

I'm not quite sure I understand your question. Here's the STR: 1. open web console 2. enter: "function f() { "use asm"; function g() {} return g }" While compiling the code in (2), we emit the warning: "warning: asm.js type error: Disabled by javascript.options.experimental_asmjs in about:config" Now, the fact that asm.js is disabled is bug 851885. However, once that bug is fixed, we'll still emit a warning (notifying of successful compilation) which needs to show up. So, either way, we need to find out why these warnings are getting squelched.

I expect the problem is a missing inner window ID for the JS warning. We need to retest once bug 783499 lands.

Did some investigation here: Build with latest fx-team repo shows no warning in the web console, nor in the error console. How is the warning emitted? I have javascript.options.experimental_asmjs set to false. I also tried with the patch from bug 783499 and its dependencies - same behavior, I didn't see any warning. Anything I'm missing?

Hmm, maybe the error propagation is getting stopped in C++ before it gets to the code you're looking at. I'll take a look at this in a little bit to see where the propagation stops.

Well, here's the problem, and it's from hg@1: http://hg.mozilla.org/mozilla-central/file/4ff1e574e509/js/xpconnect/src/XPCWrappedJSClass.cpp#l809 Bobby,Blake: is there a good reason to avoid forwarding errors and warnings to the JS console service? Why is xpcWrappedJSErrorReporter necessary, could we just call NS_ScriptErrorReporter instead.

I've always been told this stuff is totally insane and haven't dug into it. NeedInfo-ing mrbkap, who will presumably say "it's insane".

This stuff is, in fact, insane. It might actually be possible to call NS_ScriptErrorReporter instead, although the context in question might not be correct (see http://hg.mozilla.org/mozilla-central/file/b842d26dd5f0/dom/base/nsJSEnvironment.cpp#l492) and therefore not work as intended.

Oh... the reason that we didn't use NS_ScriptErrorReporter from the beginning was probably because we couldn't see content/ or dom/ from js/src/xpconnect/ (a problem which has been resolved separately with libxul).

Jim: is there anything we can do here? We now use the debugger API to eval js in scratchpad and in the web console.

You might be able to set an onExceptionUnwind handler on evaluation: that gets called as soon as an exception is generated. You can then walk the stack and look for isInCatchScope, to guess whether anything would catch that exception. If not, then you've got something you could print out early, even before the stack is unwound. But this is pretty ugly; if something is going wrong and we're eating the exception, that's the bug. Fixing that would make the console work as expected, without changes or complexity. You can look at toolkit/devtools/server/actors/script.js for an example of isInCatchScope being used to implement our "pause on uncaught exception" feature.

Does the exception have to do with the warning? AFAICT warnings are uncatchable and invisible from running scripts.

I'm sorry --- please ignore comment 14 altogether. I didn't read from the beginning, and thought we were talking about exception propagation. Warnings are something Debugger has nothing to do with. So there are no hacks available there that would help with this.

Thanks Jim for your replies. Sounds like the warnings need correct inner window ID. Maybe this bug needs to move to the right Core component.

moving to something closer to asm.js land.

Really, I think the bug is somewhere in the DOM goo that goes between here. From the JS engine's POV, we're doing our part by reporting the error, it's just not propagating all the way.

I will take patches, but I'm not personally going to work on error reporting until this stuff is no longer so intimately tied up with JSContexts.

Actually, I just looked at this again and the message does appear for both Web Console and Scratchpad, but it appears in the Browser Console. For Scratchpad, this makes sense. For Web Console, you might hope it'd appear in the content Web Console. Mihai, do you see any way to redirect warning spew? A quick test case is to type into the error console: function f() { "use asm"; return {} }

(back from vacation) The browser console shows all of the warnings and errors without any filtering, that's why you see the warnings there. We cant redirect those messages to the correct tab, correct webconsole, without knowing the inner window ID, or some other way to identify the tab of origin.

Does a Web Console have an associated inner window id?

Not sure what you mean by that. We only know the inner window id that we work with (of the tab). The webconsole actor itself is window-less and evals happen using the debugger api for the target window.

Heh, I'm not sure either :) Anyhow, it seems like the bug reported in comment 0 has been fixed, so I'll close this bug.