This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Typically, a DOM object has a single parent and 0-to-many child objects. When it is possible for a DOM Object to change parents (e.g. Node.appendChild(), TextTrack.addCue(), etc.) the new parent will first remove the child from it's existing parent. The normative section of HTMLMediaElement mediaKeys property should add a step to the effect of: "2. If the given /keys/ is already a HTMLMediaElement's /keys/, then remove the /keys/ from that HTMLMediaElement."
Ping. This is affecting implementation; the lifetime management issues implied by allowing MediaKeys to belong to multiple HTMLMediaElements are hairy.
I don't think there's any reason why a single MediaKeys object couldn't be used with more than one media element. It is possible you might want to share keys, especially when we resolve bug 19208 so that we know how to keep playing if you already have the key information you need. This could be a quality of implementation issue. Media engines in user agents may support key sharing up to a certain number of elements (perhaps that limit is 1). It is likely that early implementations would do so after setting once but we shouldn't unnecessarily constrain future implementations. I propose that we update the spec to throw QUOTA_EXCEEDED exception or something similar if the limit has been reached.
(In reply to comment #2) > I don't think there's any reason why a single MediaKeys object couldn't be > used with more than one media element. It is possible you might want to > share keys, especially when we resolve bug 19208 so that we know how to keep > playing if you already have the key information you need. There's at least one good reason, listed above: it makes object lifetime management very hairy. This would be the first and only DOM object which can have multiple parents. > This could be a quality of implementation issue. Media engines in user > agents may support key sharing up to a certain number of elements (perhaps > that limit is 1). It is likely that early implementations would do so after > setting once but we shouldn't unnecessarily constrain future > implementations. I propose that we update the spec to throw QUOTA_EXCEEDED > exception or something similar if the limit has been reached. If you want MediaKeys objects to share keys, you should make that an explicit feature of the specification, rather than a side effect of a non-standard ownership model.
I retract the statement about MediaKeys being the first DOM object with multiple parents. MediaController also has multiple HTMLMediaElement parents.
Additionally, some CDMs will have to be implemented by the media element itself. (This is currently the case with the WebKit Mac port.) By requiring that a MediaKeys object be associated with multiple HTMLMediaElements simultaneously, it would make that implementation at best much more complicated and at worst impossible. The benefit posed (sharing keys between media elements) is entirely speculative and could be achieved simply by adding the same key to two, separate MediaKeys objects.
We discussed this on the telcon: http://www.w3.org/2013/04/02-html-media-minutes.html#item01
Discussed in the F2F. Next steps: 1) Add a step that throws an exception from setMediaKeys if the media element would exceed the user agent's ability to share the MediaKeys object. 2) Add a note to the spec that explains that MediaKeys and MediaKeySession may not be functional in some implementations until the MediaKeys object is set to a media element.
Consider the related use case in bug 19156 as well. The above resolution may be sufficient.
Changeset -> https://dvcs.w3.org/hg/html-media/rev/f4d8dc9bdacc