This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25866 - "needkey" event name is misleading
Summary: "needkey" event name is misleading
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: LC
Assignee: David Dorwin
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2014-05-22 17:26 UTC by David Dorwin
Modified: 2014-08-12 21:35 UTC (History)
5 users (show)

See Also:


Description David Dorwin 2014-05-22 17:26:10 UTC
The "needkey" event was originally intended to indicate "this stream is (may be) encrypted" and provide some data about it. At one time, it was even possible to fire in response to not having the key for a block. Since then, the algorithm has changed, we've dropped MEDIA_ERR_ENCRYPTED, and put less focus on using this event to drive createSession() calls.

The event that is fired Initialization Data Encountered [1] does not necessarily mean that a key is needed (only the CDM knows this and the CDM is not involved in firing this event). Therefore, I think we should rename it to avoid confusion.

Since the event is fired at HTMLMediaElement, it should somehow indicate that it is related to EME/encrypted content. For example, "initdata" is too general and ambiguous. Possible options include "encrypted" and "encryptedinitdata".

Comment 1 Mark Watson 2014-06-12 17:03:13 UTC
Perhaps "encryptedmedia", since it is indicating that the file triggers the "Encrypted Media Extensions". More specific than 'encrypted' and less obscure than encryptedinitdata (also, the initdata is not the thing that is (might be) encrypted.
Comment 2 Chris Pearce 2014-06-23 19:58:20 UTC
"encrypted" would suffice I think. I think this is better than "encryptedmedia" as the "media" suffix is a bit superfluous, given that the event is targeted at the media element.
Comment 3 Jerry Smith 2014-06-30 16:52:06 UTC
I prefer "encryptedmedia" for the same reason Mark lists below.  It seems more complete and is clear.

We also need to update the needkey event interface and dictionary:

[Constructor(DOMString type, optional EncryptedMediaEventInit eventInitDict)]
interface EncryptedMediaEvent : Event {
  readonly attribute DOMString initDataType;
  readonly attribute ArrayBuffer? initData;

dictionary EncryptedMediaEventInit: EventInit {
  DOMString initDataType = "";
  ArrayBuffer? initData = null;
Comment 4 David Dorwin 2014-08-09 01:01:54 UTC
Summary: I'm leaning towards "encrypted" because anything longer is either inaccurate or too wordy.

* The event really means that the UA has encountered container data that indicates that media data blocks {are possibly | are potentially | may be} encrypted. The event type happens to provide that container data.
* Looking at other APIs, most event names appear to be one of the following:
 - actions (in various tenses)
 - noun-then-verb

"encryptedmedia" does not reflect the meaning or match the existing patterns. If anything, "mediaencrypted" would be more consistent, though this would imply that media was just encrypted.

"encryptedmediaencountered" would be better, but implies the UA has actually encountered encrypted media, which is not necessarily true - the UA just encountered a header.

The following are probably more accurate, though not very appealing:
* potentiallyencryptedmedia[data][encountered]
* encryptionheader[encountered]
* encryptiondata[encountered]
* initdataencountered

Lacking a good accurate and consistent name, "encrypted" seems the least misleading.
Comment 5 David Dorwin 2014-08-12 15:18:59 UTC
Agreed on "encrypted" in the telecon today.
Comment 6 David Dorwin 2014-08-12 21:35:45 UTC renames the "needkey" event to "encrypted" and updates related text.

I changed the event type name to MediaEncryptedEvent "EncryptedEvent" is too generic for the global namespace, and the "Media" prefix is consistent with MediaKeyMessageEvent. We could use a name containing "InitData", but that seems less flexible if the "encrypted" event ever needs to be extended to contain other attributes.