Closed Bug 1340748 Opened 8 years ago Closed 8 years ago

StopPluginInstance should use async IPC

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox54 affected)

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox54 --- affected

People

(Reporter: mstange, Unassigned)

References

(Blocks 1 open bug)

Details

In this profile https://perfht.ml/2lWIv42 we're waiting for 85ms for a plugin to stop, from an asynchronous CheckPluginStopEvent. This looks like it could easily be made asynchronous.
Careful, here be dragons!

Back when I was working on async plugin init, I spoke to Adobe people about making plugin destruction async, but it sounds like Flash allows its content scripts to call back into the browser during NPP_Destroy.
... wow.

How should we approach this? Could we add telemetry to find out how often this happens, and if it's not used for important things, disallow it?
We're approaching this by making Flash click-to-activate and blocking Flash on advertising domains. I don't think we should try to engineer async plugin shutdown because of the high risk of regressions.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.