Open
Bug 1297079
Opened 8 years ago
Updated 11 months ago
Prevent nested event loops from executing code in a compartment that's running code in the outer event loop
Categories
(Core :: JavaScript Engine, defect, P3)
Core
JavaScript Engine
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox51 | --- | affected |
People
(Reporter: till, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: triage-deferred)
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•8 years ago
|
||
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.
Updated•7 years ago
|
Keywords: triage-deferred
Priority: -- → P3
Updated•2 years ago
|
Severity: normal → S3
Updated•11 months ago
|
Blocks: sm-runtime
You need to log in
before you can comment on or make changes to this bug.
Description
•