This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Similar to the resolution of MSE's issue 19531, we should add bool isTypeSupported() to MediaKeys and eliminate the changes to HTMLMediaElement's canPlayType(). This provides consistency and avoids confusion related to canPlayType(). It also concentrates the key system knowledge in the EME objects. This was agreed upon at TPAC 2012.
We discussed this on the 12/11 telcon: * At TPAC we discussed making isTypeSupported map to the equivalent MSE functionality to avoid changes to canPlayType(). * The desire is to make it clear that just because a UA supports playback of a certain content type with a media element it doesn't mean the UA supports playback of that content type with EME. isTypeSupported() should address this. * On the telcon, what we didn't agree is whether the "maybe" and "probably" types need to be part of isTypeSupported because here we need to also take into account the key system. For example, video.canPlayType("video/xyz") might return "probably" but MediaKeys.isTypeSupported("video/xyz","com.example.keysystem") might want to return "maybe" because the key system is only supported for a profile of "video/xyz". The question, which we didn't reach consensus on during the call, was whether applications would want to choose to do something different based on if they received true/false from isTypeSypported or ""/"maybe"/"probably".
I made the change in https://dvcs.w3.org/hg/html-media/rev/e12daef9305d. There is still an open issue of whether to return a bool or a string like canPlayType().
Based on the discussion at the F2F, we concluded that returning bool was the best approach. If the application wants the "maybe" vs. "probably" nuance they should use canPlayType. isTypeSupported simply gives an indication about whether the browser supports the content type/protection system combination. Resolving fixed for the original issue.