This is a 0x1 deref. But something about this bug rubs me the wrong way, so I'm marking it as security-sensitive for now.

Nightly: bp-54133d29-200f-4942-a169-e991d2121026

What does it mean that content sees a [xpconnect wrapped nsIDOMNode] instead of an [object Something]? Is that bad on its own?

Huh, when I run this now I get: x is a [xpconnect wrapped nsIDOMNode @ 0x119d58b30 (native @ 0x11b62fde0)] WARNING: IDL methods marked with [implicit_jscontext] or [optional_argc] may not be implemented in JS: file /Users/amccreight/mz/cent/js/xpconnect/src/XPCWrappedJSClass.cpp, line 1154 JavaScript error: file:///Users/amccreight/mz/tests/805879.html, line 15: IDL methods marked with [implicit_jscontext] or [optional_argc] may not be implemented in JS Line 15 is |x.cloneNode(false);|

That was added in bug 809674, so I guess this was another instance of a malformed call or whatever the heck that was.

Filed bug 817567 on the nonsensical error message.

The error message is being produced on the line with the call to cloneNode, so that makes sense at least. jst looked at the test example, and says that what he thinks is happening is that the empty object that gets passed in as an argument to initMutationEvent, but XPC just happily wraps it into a node-implemented-by-JS, so it is "implementing" a node. That's why the dump looks like [xpconnect wrapped nsIDOMNode]. Then, later, we can call cloneNode because it is implementing a node, but when XPConnect tries to look through the wrapper to get the implementation, it hits the check that this method can't be implemented by JS, and we get the error.