1161587 - Have GMPs fire PluginCrashed events in the content process in a better way

Status: NEW

(Core :: Audio/Video: GMP, defect, P4)

Description

[Mike Conley (:mconley) (:⚙️)]

Bug 1146955 landed to enabled plugin crash reporting for GMP's, and in doing so, worked around the fact that PluginCrashed doesn't fire for GMPs in the content that's using them.

It works around it by having the PluginCrashReporter send a message down to all content processes saying that the GMP has crashed. PeerConnection.js listens for that message, and fires the PluginCrashed event if appropriate.

I really don't think PluginCrashReporter is the right place to do this in the long run. I think something similar to what NPAPI does might be appropriate - where the GMP code in the content process realizes that the GMP process has gone away via ActorDestroy, and then triggers PluginCrashed to be dispatched on any content that was using the GMP.

I'm not familiar enough with the GMP architecture to know if that's even possible or practical, but it's probably a more comprehensive approach than what I went with in bug 1146955.

Comment 1

[Chris Peterson [:cpeterson]]

This is a regression from peterv's e10s support for GMP.

Comment 2

[Chris Pearce [:cpearce (Not reading bugmail)]]

gerald can work on this, though he'll probably need guidance as to what is appropriate from mconley.

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

Could WebRTC use the same system I introduced for EME in bug 1135541?

Basically, when a plugin is first used in a page, a GeckoMediaPluginService::PluginCrashCallback-derived object is registered with GeckoMediaPluginService, and when a plugin crashes all relevant callbacks are called. It's all done in C++ land, no js involved.
In the EME case, the callback checks that the page&document in which the plugin was used still exist, and displays the PluginCrashed drop-down in that page. We could move this code to a more central place, to be reused in WebRTC and others.

I know very little about WebRTC, so this may not be possible/practical. What do you think, Mike?

Comment 4

[Mike Conley (:mconley) (:⚙️)]

Wow, I've reeeeeeally let this needinfo languish. I'm sorry about that - mixture of PTO and some other things.

And I'm afraid I'm not providing much useful information here - I don't know much about WebRTC's architecture, beyond the hack that I did in order to make crash reporting work in PeerConnection.js. :/

It might be better to pose this question to rjesup or someone from #media.

Comment 5

[Chris Pearce [:cpearce (Not reading bugmail)]]

Going to officially deprioritize this. It doesn't need to be done in order to ship EME.

Comment 6

[Maire Reavy [:mreavy]]

Low priority - we already have a list of all active PeerConnections in PeerConnection.js, and it's simple to ask them if they're using the GMP process on a crashreport.

Comment 7

[Bulk Bug Changes for mreavy's org]

Mass change P3->P4 to align with new Mozilla triage process.