(The following description is for the Android model only. The model on desktop is similar and is subject to the same problem.)

The renderer process hosts a MojoCdm, which owns the media::mojom::ContentDecryptionModulePtr (CdmPtr). The MojoCdm is owned by the Javascript MediaKeys object.

In the remote process, MojoCdmService implements media::mojom::CDM, and is hosted in MediaService in the GPU process.

The MediaService owns a mojo::StrongBindingSet of media::mojom::InterfaceFactory implementations, which is media::InterfaceFactoryImpl. The corresponding media::mojom::InterfaceFactoryPtr is owned by the RenderFrameHostImpl in the browser process (see MediaInterfaceProxy). The renderer process needs the help of the browser to setup the connection.

InterfaceFactoryImpl owns a mojo::StrongBindingSet of media::mojom::ContentDecryptionModule, talking to the MojoCdm running in the render process.

Now, during teardown, before JS MediaKeys is destroyed or cleaned up. It's possible that RenderFrameHostImpl in the browser process is killed first. Then InterfaceFactoryImpl get a connection error and is destroyed, which will then destroy all MojoCdmService instances, causing a connection error on the MojoCdm, which could trigger some error conditions, e.g. MediaKeySession closed.

User will probably not notice this since this is during teardown. But Javascript may see it, and we see from UMA metrics. This is annoying since it'll contaminate metrics both for the JS app and Chrome. For example, the JS app cannot differentiate whether the closed MediaKeySession is a fatal error, or just work as expected during page teardown process.

Similar issue could also happen to other remote media components, e.g. audio/video decoders, causing decode errors during teardown.

Historically in the IPC world, if RenderFrameHostImpl is destroyed first, IPC messages sent from the renderer process simply will not be replied. This will not cause any error. With mojo, since we have connection error, and WrapCallbackWithDefaultInvokeIfNotRun, the callbacks will be run with failure conditions, and we could see this pattern more often.

ISTM the ultimate fix is to tighten the life time between RenderFrameImpl and RenderFrameHostImpl. For example, all JS objects (ActiveDomObjects) tied to the frame needs to be stopped before RenderFrameHostImpl destruction happens. However, I chat with dcheng@ offline on this, and this seems will not happen any time soon, or forever. 

Another potential fix is to not destroy InterfaceFactoryImpl when RenderFrameHostImpl is destroyed. This means that we cannot store InterfaceFactoryImpl in the mojo::StrongBindingSet as is, and need some additional logic so that after all MediaCdmServices are destructed, we have a way to destruct InterfaceFactoryImpl. I'll have to think more about it.