- From: <bugzilla@jessica.w3.org>
- Date: Tue, 11 Nov 2014 01:34:10 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24874 --- Comment #6 from Joe Steele <steele@adobe.com> --- (In reply to David Dorwin from comment #5) > (In reply to Joe Steele from comment #4) > > > For when an attempt is made to set video.src to a source that does not > > support EME when video.mediaKeys is already set: I think when video.src is > > set, we should always clear the current mediaKeys (and fire the close() > > event if we end up doing that). > > Are you saying setting video.src ALWAYS clears mediaKeys or only when EME is > not supported? The former is not an option - this is an expected pattern. I am saying setting the video.src member would automatically clear the video.mediakeys element. Regardless of the source. > For the latter, I think it's inappropriate for setting one attribute to > change another. Ok, fair enough. It would be unusual agreed - but we could give guidelines. > Ideally, we'd throw an exception in response to "video.src = <URL>", but > it's not clear how we can do that. (See comment #1.) If we don't throw exceptions - what happens when we try to play? * I would expect that content that is unencrypted will just play and the UA will ignore _mediakeys_ if set. * I would expect that content that is encrypted will try to play, but with no usable key ids available to decrypt, the browser will fail with MEDIA_ERR_DECODE. Both of those seem like reasonable behaviors. Would this work for your implementation? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 11 November 2014 01:34:11 UTC