This is actually the intended behavior. The motivation was to fix  issue 599588 .

You can see the comment here: https://cs.chromium.org/chromium/src/content/browser/media/cdm_registry_impl.cc?rcl=28daf3ae46c6b86aebb17190fb6b92db2acc245e&l=35

The change was made here:
https://chromium-review.googlesource.com/c/chromium/src/+/889982

Basically, if we start to use the new CDM immediately, there's a chance of information mismatch, which we try to avoid. I felt it's not an issue even for chromium-based browsers, since it'll only affect the update case, so user should not notice any difference. For new installs (or other cases where there was no CDM), the updated CDM will take effect immediately.

Is there any strong reason you want the newly updated CDM to be used immediately?

I agree information mismatch, where the browser knows about one set of capabilities, but the CDM actually loaded has another set of possibilities, is best avoided.

However, I think the current solution to this problem backfires when there is an emergency update of the CDM that is required to make it even work.  It's probably OK to expect the user to reload the page when there is a problem with video playback.  Expecting them to know to restart the browser might be too much.

Would it be completely impractical to spawn a new utility process to host the updated CDM?

Thanks for explaining BTW ;)

I see your point. Thanks for the explanation! Again there's not perfect solution here, which is why we chose the simplest one, which also makes sense in most cases IMHO.

> Would it be completely impractical to spawn a new utility process to host the updated CDM?

If you revert my CL mentioned above, the new CdmInfo will be put on the top of CdmRegistry, such that if there's no existing CDM service running, the new CDM will be used in the CDM/utility process. Again, this can cause info mismatch. Also, if the user already has another tab open that uses the CDM, then refreshing the page will never get to use the new CDM since we only have one CDM service/process running in the system.

> Expecting them to know to restart the browser might be too much.

We never had issues urgent enough that the user cannot wait for a browser restart :) But I'd like to learn otherwise.

> Other possible solutions.

If we really want to achieve what you described, and avoid the info mismatch at the same time, we should register render processes that queried EME capability, and setup some kind of RenderProcessObserver, such that only after all those render processes went away, that we can use the new CDM. Again, I am not sure whether that's worth the effort.

Right.  I'm not sure either and I can see how there are different requirements that may be hard to meet at the same time.  I would still like to clarify my point further.

>> Would it be completely impractical to spawn a new utility process to host the updated CDM?
>
> If you revert my CL mentioned above, the new CdmInfo will be put on the top of CdmRegistry,
> such that if there's no existing CDM service running, the new CDM will be used in the
> CDM/utility process. Again, this can cause info mismatch. Also, if the user already has
> another tab open that uses the CDM, then refreshing the page will never get to use the new
> CDM since we only have one CDM service/process running in the system.

In my imagination, a CDM process instance would be tied to a CDM version.  A new CDM version installed by the component updater would get a new CDM process instance.  Any renderers still using the old CDM version would talk to the previous CDM process instance that would still be running.  I don't know if this is feasible.  And maybe it's overkill anyway and your renderer observer idea would be sufficient.

> We never had issues urgent enough that the user cannot wait for a browser restart :) But I'd
> like to learn otherwise.

There was this issue recently where something went wrong with 1.4.10.1088 in that it didn't work at all, and it had to be repushed to the update server as 1.4.10.1089.  This is actually the reason I've been thinking about scenarios like this.

You imagination is mostly correct except for two things that needs to be clarified:
1. In requestMediaKeySystemAccess(), no CDM process is launched or used. This is why there could be info mismatch.
2. Currently there's only one CDM process. It's doable to use version as a key to support multiple CDM processes for different versions. But again, we'd like to keep the solution simple unless some important use case is broken.

The problem with 1.4.10.1088 can be seen from both ways. Those users who got 1.4.10.1088 and didn't restart the browser will not see the problem immediately, and chances are when before they restart the browser, the CDM has already been updated to 1.4.10.1089...

That's a good point, and it does lower the severity of the problem.

Anyway, I have no additional arguments in favor of using a new CDM immediately.

There's another easier way to solve this. If the capability of the new CDM is strictly a superset of the capability of the old CDM, then we can just launch the new CDM without worrying about info mismatch. But it can get tricky how you define a capability superset but should be manageable in practice.

We still have no plan to implement this at this point. But that could be an option in the future.

Mark as WontFix for now. We can reopen in the future if needed. Thanks for the discussion!