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.
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.
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.