1297079 - Prevent nested event loops from executing code in a compartment that's running code in the outer event loop

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Till Schneidereit [:till]]

In bug 1283924, Luke encountered a situation where a currently running call to Promise#then was interrupted by an AsyncTask callback:

[T]o ensure my runnable was always dispatchable
back to the worker thread, I was told to use a ControlRunnable.
However ControlRunnables attempt to run *immediately* by using
RequestInterrupt and running from the interrupt handler.  Thus, in
this one bad interleaving, I was interrupting the `then` self-hosted
code by running the `resolve` self-hosted code :)

There doesn't seem to be a good reason for this to be allowed, and it's probably an accidental byproduct of the nested event loop stuff we need for dialogs and sync XHR.

Perhaps we can at least assert against running code in an already active compartment, though? I'm not sure where exactly we'd do this, but it seems like it should be possible inside of SpiderMonkey.

Comment 1

[Luke Wagner [:luke]]

To be clear, in comment 0, I was causing this behavior via a bug in Gecko code I wrote, but this error certainly would have made it quicker to find.  I believe this can technically happen via plain content, though.

Also, this seems similar to our current js::EnterDebuggeeNoExecute functionality; maybe we could reuse and generalize this to be a general "lock compartment against execution" feature.