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 27738 - Need to change name of 'message' event to avoid confusion.
Summary: Need to change name of 'message' event to avoid confusion.
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Adrian Bateman [MSFT]
QA Contact: HTML WG Bugzilla archive list
Whiteboard: API_Compatibility
Depends on:
Reported: 2015-01-03 23:22 UTC by Glenn Adams
Modified: 2015-01-21 00:36 UTC (History)
7 users (show)

See Also:


Description Glenn Adams 2015-01-03 23:22:39 UTC
HTML5, Server Socket Events (SSE), Web Messages, and WebSockets API all employ a "message" event, with MessageEvent interface type, as defined by [1]. It is bad form, confusing, and potentially ambiguous for EME to redefine "message" as being an entirely different event bound to a MediaKeyMessageEvent. Please change the name to something specific to EME, e.g, "keymessage".

Comment 1 David Dorwin 2015-01-07 21:16:51 UTC
Is this really a problem for someone that wants to handle the "message" event on a MediaKeySession?

As for potential alternative names, "keymessage" is misleading since it is unlikely to relate to a key. It's really a session message (redundant because it's fired at a session object) or message from the CDM ("CDM" is not an app-visible concept).
Comment 2 David Dorwin 2015-01-13 22:34:17 UTC
Web MIDI fires [1]:
* Events named "connect" and "disconnect" using the type MIDIConnectionEvent at MIDIAccess objects.
* An event named "disconnect" using the type MIDIConnectionEvent at MIDIPort.
* An event named "midimessage" using the type MIDIMessageEvent at MIDIInput.

The first two are "common" event names with custom event types. The last is a specific event name for a custom event type. Perhaps this is specifically to avoid the issue with MessageEvent, but it seems odd to special case this name and type rather than "scope" all event names using custom types.

[1] Search for "fire " in
Comment 3 Henri Sivonen 2015-01-15 10:18:39 UTC
Can we please get edits that are about naming things done (or rejected) ASAP so that the names won't keep changing after implementations have adopted the names? There's more value in not having vendor prefixes and not having naming churn after shipping than in ending up with perfect names some time in the future.
Comment 4 David Dorwin 2015-01-15 21:39:45 UTC
+Anne and Alex for general platform comments (see comment 2).

I agree with comment 3 - let's determine whether a change is necessary and move forward. I'll send an email to the list.
Comment 5 Anne 2015-01-16 08:27:27 UTC
Event types (commonly referred to as the name of an event) are not required to be globally unique. This only goes for event interfaces (nay classes) and even those can be reused by events that signify something else as long as the objects they are dispatched on are different. 

(And I would argue, as long as those objects have no relationship. E.g. we wouldn't want Text and Element nodes to use a "foo" event with a "FooEvent" interface for completely different reasons.)

So I don't really see a problem here.
Comment 6 David Dorwin 2015-01-21 00:34:03 UTC
Per comment 5, this is not a problem. As agreed in the telecon today, we will keep the name 'message'.
Comment 7 David Dorwin 2015-01-21 00:36:26 UTC
Telecon minutes: