Have you read the FAQ and checked for duplicate open issues?
Yes
Is your feature request related to a problem? Please describe.
The EME editor's draft is adding an enum called MediaKeySessionClosedReason. Values of this type will be used to resolve the closed Promise in MediaKeySession.
Describe the solution you'd like
We should use this information, when available, to react to session closures and handle certain cases specially. For example, the proposed hardware-context-reset value would require us to create new sessions to replace the ones that were closed by the CDM. As spec'd, this could happen when a device goes to sleep and wakes up again.
Describe alternatives you've considered
The first alternative is the status quo. If we ignore this extra info, applications may have to do more work to resume playback after certain adverse events such as hibernation. Also, they have to do this work without useful information to drive their decisions.
A slightly different approach to using an allow-list approach looking for something like hardware-context-reset might be to use a deny-list approach by ignoring closures with reasons resource-evicted or closed-by-application. In all other cases, we might want to recreate sessions automatically.
Additional context
EME spec PR (which has not yet landed): w3c/encrypted-media#487
Have you read the FAQ and checked for duplicate open issues?
Yes
Is your feature request related to a problem? Please describe.
The EME editor's draft is adding an enum called
MediaKeySessionClosedReason. Values of this type will be used to resolve theclosedPromise inMediaKeySession.Describe the solution you'd like
We should use this information, when available, to react to session closures and handle certain cases specially. For example, the proposed
hardware-context-resetvalue would require us to create new sessions to replace the ones that were closed by the CDM. As spec'd, this could happen when a device goes to sleep and wakes up again.Describe alternatives you've considered
The first alternative is the status quo. If we ignore this extra info, applications may have to do more work to resume playback after certain adverse events such as hibernation. Also, they have to do this work without useful information to drive their decisions.
A slightly different approach to using an allow-list approach looking for something like
hardware-context-resetmight be to use a deny-list approach by ignoring closures with reasonsresource-evictedorclosed-by-application. In all other cases, we might want to recreate sessions automatically.Additional context
EME spec PR (which has not yet landed): w3c/encrypted-media#487