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.

Resolving as wont fix, plugin support deprecated in Firefox 85.