Closed Bug 818785 Opened 12 years ago Closed 3 years ago

Don't stop plugins synchronously (delayed stop)

Categories

(Core Graveyard :: Plug-ins, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: johns, Assigned: johns)

References

Details

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)
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?
(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.
Depends on: 851378
Resolving as wont fix, plugin support deprecated in Firefox 85.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.