The setMediaKeys() algorithm currently says that the “keys” attribute is set, but there are other things that should happen and corner cases we should at least give guidance on.

tl;dr: I recommend adding:
  * A step related to Using the Newly Attached MediaKeys Object (first section)
  * Implementation of Option #2 related to Detaching (and re-attaching) a MediaKeys Object (second section).
    + That is, setMediaKeys() may throw an exception if a change involving either the HTMLMediaElement or MediaKeys is already in progress.
  * Adding a note that Detaching/Replacing a MediaKeys Object During Playback (third section) is a quality of implementation issue but likely to result in a bad user experience or exception.


*** Using the Newly Attached MediaKeys Object ***
First, it seems that there should be some attempt to use the keys in the MediaKeys object’s session(s) if appropriate. For example, createSession() says:
  “If the associated media element(s) are waiting for a key, queue a task to attempt to resume playback.
  “In other words, resume playback if the necessary key is provided.
  “The user agent may choose to skip this step if it knows resuming will fail (i.e. no usable key was added).”

Like createSession(), this should probably occur in a task, which means it is asynchronous and may not affect the very next frame.


*** Detaching a MediaKeys Object ***
The algorithm does not address the replacement/detaching of a previously set MediaKeys object.

== Detaching is Asynchronous ==
Like attaching, replacement/detaching is probably asynchronous since the media pipeline must be disrupted.

Because the setMediaKeys() method is synchronous, when replacing non-null MediaKeys A with non-null MediaKeys B:
I. An HTMLMediaElement implementation could have references to two CDM instances at the same time.
II. Immediately passing the disconnected MediaKeys A to setMediaKeys() on another HTMLMediaElement could be difficult to handle (the previous HTMLMediaElement is still disconnecting from it).

Scenario II above may be okay in situations where the MediaKeys object was NOT being used by the maximum number of HTMLMediaElements. However, with the maximum expected to be one in many cases, it could be a problem.

Note that even a null MediaKeys B could be a problem if a non-null MediaKeys C is specified before Media Keys A is detached.

== Questions ==
The following questions may be helpful for discussing and understanding the issues:
1. Is detaching expected to be supported or is it a quality of implementation issue?
2. Under what conditions is detaching/replacement allowed?
  2.1. What should happen in case II when a detach is pending and the maximum number of HTMLMediaElements are using the MediaKeys implementation?
3. What should happen if either is disallowed?
4. How can the application know that it is safe to call setMediaKeys() on an HTMLMediaElement or with a MediaKeys object?
5. What happens if a session is detached during the asynchronous attachment process?
6. Is it okay for implementations to only support A -> null -> B instead of A -> B? (This probably provides no value as explained earlier.)
7. Is it okay for implementations to only support detaching after setting src to null? (Even then, it’s not clear when it can be attached to a new media element.)
8. Is it okay for implementations to not allow detaching once attached?

Whether some of these things can be supported is probably a quality of implementation detail, but we know there will be implementations that don’t support them and we should define a consistent behavior for applications to expect.

== Options ==
Many of the issues relate to the window between when setMediaKeys() is called and when the underlying media stack starts using or stops using the CDM. We either need to make setMediaKeys() be asynchronous (#2 and #3 below) such that serially attaching and detaching among media elements is not expected to be supported or ensure that setMediaKeys() can run synchronously (#1 below).

I’m leaning toward #2 with the possibility of extending it to #3 in the future if there are use cases where events are useful. At the moment, #3 seems like more specification and implementation that is necessary, especially for such an unlikely use case. #2 provides a clear definition of what implementations should do in these corner cases.

#1 seems too limiting, though I can’t think of a good use case that it prevent. #2 certainly allows a user agent to implement #1.

For all options except maybe #1, we may need to note that *detaching* might be disallowed by some implementations in some or all cases. We should specify that such implementations might throw {pick one of NO_MODIFICATION_ALLOWED_ERR, INVALID_MODIFICATION_ERR, or INVALID_ACCESS_ERR}.  We may even want to be more explicit and add a step that says if the currently attached object cannot be *detached*, throw the exception. This 

+ Option #1: Only allow detaching when stopped (null .src?). Throw an exception in all other cases.
This is simplest for implementations since the CDM would not be in use and should allow detaching to be synchronous.
Are there realistic uses for detaching when not stopped?
Does this cover all cases?

+ Option #2: Note that setMediaKeys() may throw an exception if a change involving either the HTMLMediaElement or MediaKeys is already in progress.
Step 1 already says to throw a QUOTA_EXCEEDED_ERR exception when the MediaKeys is “in use and the user agent is unable to re-use it”. We could add text to note that this may include objects that have been detached and are not (yet) available for reuse. In other words, “in use” does not necessarily mean “currently attached” from the application’s point of view.

This is reasonably broad and should cover the asynchronous detaching cases. However, applications have no way (other than trial and catch) to know when they can attach to another HTMLMediaElement.

Depending on what other changes we make to the algorithm, we might define internal states to help in the definition of algorithms related to throwing the exception.

+ Option #3: Define event(s) on the MediaKeys object related to (dis)connection.
This is similar to #2 but provides a formal way for applications to know when the MediaKeys can be attached to another HTMLMediaElement and vice versa.

We could define a single event on MediaKeys for when detaching is complete. Applications need not wait for the event since an implementation could support attaching to multiple HTMLMediaElements. However, if setMediaKeys() throws QUOTA_EXCEEDED_ERR, the application could wait for this event.

(If we disallow A -> B (Option #4)): Since the event is always fired - regardless of whether more attachments are supported - applications could also use it to know when the HTMLMediaElement is ready to accept a new object.)

Note that the name of the event needs to focus on a detach occurring rather than the state of the MediaKeys because we need to allow implementations to support attaching a MediaKeys to more than one HTMLMediaElements.

My understanding is that such an event is similar to MSE, which asynchronously closes the MediaSource object when it is detached and does not allow it be attached to a new HTMLMediaElement until it is in the closed state. See https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#mediasource-attach.

+ Option #4: Disallow A -> B transitions and require A -> null -> B.
It’s unclear that this actually solves anything since the two operations could be executed back-to-back.


*** Playback Experience When Detaching/Replacing a MediaKeys Object  During Playback ***
(This section specifically covers the playback experience and assumes the mechanics have been addressed in the previous section. It does not apply if Option #1 above is selected.)
Unless playing a large amount of clear content, the MediaKeys object is required for playback. The CDM it represents is also likely to be decoding content, which means detaching it could disconnect the decoder(s). (This is why it is recommended that applications attach a MediaKeys object before providing the content. [https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/encrypted-media.html#dom-setmediakeys]).

Questions:
1. Are applications allowed to attach/detach a MediaKeys object from an HTMLMediaElement while the latter is “potentially playing” (or various other states with a valid source)?
2. If so, what is the behavior when this happens?
  2.1. Should applications expect to be able to seamlessly switch from one MediaKeys to another?
  2.2. Is this a quality of implementation issue (playback may stop, briefly stall, etc.)?

To allow implementation flexibility, we probably want to allow implementations to throw an exception in this case. See the discussion of such an exception in the previous section.