Docs for 6014 EXPIRED seem inaccurate

[chrisfillmore]

The docs for EXPIRED say:

The license has expired. This is triggered when playback is stalled on a 'waitingforkeys' event and there are any expired keys in the key status map of any active session.

I think this explanation has a couple issues:

• Shaka doesn't listen for waitingforkey (also, no s), it listens for keystatuseschange, then checks if keys are expired
• EXPIRED will only get fired if all key statuses are expired ("any expired keys" in the docs is not correct)

Have I misunderstood? I can submit a PR to update if you agree.

[chrisfillmore]

However, I just noticed this in the spec (emphasis added):

The key is no longer usable for decryption because its expiration time has passed. The time represented by the expiration attribute MUST be earlier than the current time. All other keys in the session MUST have this status.

https://www.w3.org/TR/encrypted-media/#dom-mediakeystatus-expired

[joeyparrish]

The part about 'waitingforkey' is clearly out of date and should be fixed. We used to listen for 'waitingforkey' events specifically to detect a situation when the license server or proxy had a bug and the wrong keys were delivered. We ultimately had to remove that feature because of false negatives.

I think the other details are out of date, as well.

As you noted, all keys in a session have the same expiration time, so they all become expired at once. But keys in different sessions can expire separately.

Although our docs say "any key in any active session", the current behavior is that we fire the EXPIRED error when every known key from every MediaKeySession in this playback (including ones from the past which we closed already) have the "expired" status. So it would be better to say something like:

The license has expired. This is triggered when all keys in the key status map have a status of 'expired'.

What do you think?

[joeyparrish]

(Happy to have a PR, BTW)

[chrisfillmore]

Sounds good.

[joeyparrish]

Cherry-picked for v2.3.3.