If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
JavaScript Engine
P3
normal
a year ago
3 days ago

People

(Reporter: till, Unassigned)

Tracking

({triage-deferred})

Trunk
triage-deferred
Points:
---

Firefox Tracking Flags

(firefox51 affected)

Details

(Reporter)

Description

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