Don't stop plugins synchronously (delayed stop)

ASSIGNED
Assigned to

Status

()

Core
Plug-ins
ASSIGNED
5 years ago
5 years ago

People

(Reporter: johns, Assigned: johns)

Tracking

(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

5 years ago
We should ideally never synchronously stop a plugin, as it may spin the event loop at very bad times, such as document destruction (bug 785348)

Comment 1

5 years ago
You should assume that *any* RPC call into a plugin can spin the event loop. That's why we've moved to async painting, because we're not prepared to handle arbitrary reentry during paint calls. Everything else, though, needs to be prepared for reentry through npruntime or spinning a nested event loop. I'm not sure I entirely understand all of bug 785348; perhaps we need to re-audit the potential entry points to make sure they are safe?
(Assignee)

Comment 2

5 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> You should assume that *any* RPC call into a plugin can spin the event loop.
> That's why we've moved to async painting, because we're not prepared to
> handle arbitrary reentry during paint calls. Everything else, though, needs
> to be prepared for reentry through npruntime or spinning a nested event
> loop. I'm not sure I entirely understand all of bug 785348; perhaps we need
> to re-audit the potential entry points to make sure they are safe?

I believe plugin destruction can happen at times that other npruntime calls cannot (though I could be wrong), and it is one of the few places we can sanely make always asynchronous. Even if we decide not to flip it on, the delayed stop codepath should still be cleaned up or entirely removed.
(Assignee)

Updated

5 years ago
Depends on: 851378
You need to log in before you can comment on or make changes to this bug.