13 Terminology

The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of the more accurate "an object implementing the interface Foo".

The term DOM is used to refer to the API set made available to scripts in Web applications, and does not necessarily imply the existence of an actual Document object or of any other Node objects as defined in the DOM specifications. [DOM]

An IDL attribute is said to be getting when its value is being retrieved (e.g. by author script), and is said to be setting when a new value is assigned to it.

13.1 The WebSocket interface

enum BinaryType { "blob", "arraybuffer" };
[Constructor(DOMString url, optional (DOMString or DOMString[]) protocols), Exposed=Window,Worker]
interface WebSocket : EventTarget {
  readonly attribute DOMString url;

  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSING = 2;
  const unsigned short CLOSED = 3;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long bufferedAmount;

  // networking
           attribute EventHandler onopen;
           attribute EventHandler onerror;
           attribute EventHandler onclose;
  readonly attribute DOMString extensions;
  readonly attribute DOMString protocol;
  void close([Clamp] optional unsigned short code, optional DOMString reason);

  // messaging
           attribute EventHandler onmessage;
           attribute BinaryType binaryType;
  void send(DOMString data);
  void send(Blob data);
  void send(ArrayBuffer data);
  void send(ArrayBufferView data);
};

The WebSocket(url, protocols) constructor takes one or two arguments. The first argument, url, specifies the URL to which to connect. The second, protocols, if present, is either a string or an array of strings. If it is a string, it is equivalent to an array consisting of just that string; if it is omitted, it is equivalent to the empty array. Each string in the array is a subprotocol name. The connection will only be established if the server reports that it has selected one of these subprotocols. The subprotocol names must all be strings that match the requirements for elements that comprise the value of Sec-WebSocket-Protocol fields as defined by the WebSocket protocol specification. [WSP]

When the WebSocket() constructor is invoked, the UA must run these steps:

  1. Parse a WebSocket URL's components from the url argument, to obtain host, port, resource name, and secure. If this fails, throw a SyntaxError exception and abort these steps. [WSP]

  2. If secure is false but the origin specified by the entry settings object has a scheme component that is itself a secure protocol, e.g. HTTPS, then throw a SecurityError exception and abort these steps.

  3. If port is a port to which the user agent is configured to block access, then throw a SecurityError exception and abort these steps. (User agents typically block access to well-known ports like SMTP.)

    Access to ports 80 and 443 should not be blocked, including the unlikely cases when secure is false but port is 443 or secure is true but port is 80.

  4. If protocols is absent, let protocols be an empty array.

    Otherwise, if protocols is present and a string, let protocols instead be an array consisting of just that string.

  5. If any of the values in protocols occur more than once or otherwise fail to match the requirements for elements that comprise the value of Sec-WebSocket-Protocol fields as defined by the WebSocket protocol specification, then throw a SyntaxError exception and abort these steps. [WSP]

  6. Let origin be the ASCII serialization of the origin specified by the entry settings object, converted to ASCII lowercase.

  7. Return a new WebSocket object, but continue these steps asynchronously.

  8. Let the new object's client-specified protocols be the values (if any) given in protocols.

  9. Establish a WebSocket connection given the set (host, port, resource name, secure), along with the protocols list, an empty list for the extensions, and origin. The headers to send appropriate cookies must be a Cookie header whose value is the cookie-string computed from the user's cookie store and the URL url; for these purposes this is not a "non-HTTP" API. [WSP] [COOKIES]

    When the user agent validates the server's response during the "establish a WebSocket connection" algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the WebSocket connection.

    Following HTTP procedures here could introduce serious security problems in a Web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the Internet, even if the script checks that the URL has the right hostname.

    If the establish a WebSocket connection algorithm fails, it triggers the fail the WebSocket connection algorithm, which then invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.


The url attribute must return the result of resolving the URL that was passed to the constructor, with the URL character encoding set to UTF-8. (It doesn't matter what it is resolved relative to, since we already know it is an absolute URL.)

The readyState attribute represents the state of the connection. It can have the following values:

CONNECTING (numeric value 0)
The connection has not yet been established.
OPEN (numeric value 1)
The WebSocket connection is established and communication is possible.
CLOSING (numeric value 2)
The connection is going through the closing handshake, or the close() method has been invoked.
CLOSED (numeric value 3)
The connection has been closed or could not be opened.

When the object is created its readyState must be set to CONNECTING (0).

The extensions attribute must initially return the empty string. After the WebSocket connection is established, its value might change, as defined below.

The extensions attribute returns the extensions selected by the server, if any. (Currently this will only ever be the empty string.)

The protocol attribute must initially return the empty string. After the WebSocket connection is established, its value might change, as defined below.

The protocol attribute returns the subprotocol selected by the server, if any. It can be used in conjunction with the array form of the constructor's second argument to perform subprotocol negotiation.

The close() method must run the following steps:

  1. If the method's first argument is present but is neither an integer equal to 1000 nor an integer in the range 3000 to 4999, throw an InvalidAccessError exception and abort these steps.

  2. If the method's second argument is present, then run these substeps:

    1. Let raw reason be the method's second argument.

    2. Let Unicode reason be the result of converting raw reason to a sequence of Unicode characters.

    3. Let reason be the result of encoding Unicode reason as UTF-8.

    4. If reason is longer than 123 bytes, then throw a SyntaxError exception and abort these steps. [ENCODING]

  3. Run the first matching steps from the following list:

    If the readyState attribute is in the CLOSING (2) or CLOSED (3) state

    Do nothing.

    The connection is already closing or is already closed. If it has not already, a close event will eventually fire as described below.

    If the WebSocket connection is not yet established [WSP]

    Fail the WebSocket connection and set the readyState attribute's value to CLOSING (2). [WSP]

    The fail the WebSocket connection algorithm invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

    If the WebSocket closing handshake has not yet been started [WSP]

    Start the WebSocket closing handshake and set the readyState attribute's value to CLOSING (2). [WSP]

    If the first argument is present, then the status code to use in the WebSocket Close message must be the integer given by the first argument. [WSP]

    If the second argument is also present, then reason must be provided in the Close message after the status code. [ENCODING] [WSP]

    The start the WebSocket closing handshake algorithm eventually invokes the close the WebSocket connection algorithm, which then establishes that the WebSocket connection is closed, which fires the close event as described below.

    Otherwise

    Set the readyState attribute's value to CLOSING (2).

    The WebSocket closing handshake is started, and will eventually invoke the close the WebSocket connection algorithm, which will establish that the WebSocket connection is closed, and thus the close event will fire, as described below.

The close() method does not discard previously sent messages before starting the WebSocket closing handshake — even if, in practice, the user agent is still busy sending those messages, the handshake will only start after the messages are sent.


The bufferedAmount attribute must return the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but that, as of the last time the event loop reached step 1, had not yet been transmitted to the network. (This thus includes any text sent during the execution of the current task, regardless of whether the user agent is able to transmit text asynchronously with script execution.) This does not include framing overhead incurred by the protocol, or buffering done by the operating system or network hardware. If the connection is closed, this attribute's value will only increase with each call to the send() method (the number does not reset to zero once the connection closes).

In this simple example, the bufferedAmount attribute is used to ensure that updates are sent either at the rate of one update every 50ms, if the network can handle that rate, or at whatever rate the network can handle, if that is too fast.

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
  setInterval(function() {
    if (socket.bufferedAmount == 0)
      socket.send(getUpdateData());
  }, 50);
};

The bufferedAmount attribute can also be used to saturate the network without sending the data at a higher rate than the network can handle, though this requires more careful monitoring of the value of the attribute over time.


When a WebSocket object is created, its binaryType IDL attribute must be set to the string "blob". On getting, it must return the last value it was set to. On setting, the user agent must set the IDL attribute to the new value.

This attribute allows authors to control how binary data is exposed to scripts. By setting the attribute to "blob", binary data is returned in Blob form; by setting it to "arraybuffer", it is returned in ArrayBuffer form. User agents can use this as a hint for how to handle incoming binary data: if the attribute is set to "blob", it is safe to spool it to disk, and if it is set to "arraybuffer", it is likely more efficient to keep the data in memory. Naturally, user agents are encouraged to use more subtle heuristics to decide whether to keep incoming data in memory or not, e.g. based on how big the data is or how common it is for a script to change the attribute at the last minute. This latter aspect is important in particular because it is quite possible for the attribute to be changed after the user agent has received the data but before the user agent has fired the event for it.

The send(data) method transmits data using the connection. If the readyState attribute is CONNECTING, it must throw an InvalidStateError exception. Otherwise, the user agent must run the appropriate set of steps from the following list:

If the argument is a string

Let data be the result of converting the data argument to a sequence of Unicode characters. If the WebSocket connection is established and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a text frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. Any invocation of this method with a string argument that does not throw an exception must increase the bufferedAmount attribute by the number of bytes needed to express the argument as UTF-8. [UNICODE] [ENCODING] [WSP]

If the argument is a Blob object

If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the raw data represented by the Blob object. Any invocation of this method with a Blob argument that does not throw an exception must increase the bufferedAmount attribute by the size of the Blob object's raw data, in bytes. [WSP] [FILEAPI]

If the argument is an ArrayBuffer object

If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the data stored in the buffer described by the ArrayBuffer object. Any invocation of this method with an ArrayBuffer argument that does not throw an exception must increase the bufferedAmount attribute by the length of the ArrayBuffer in bytes. [WSP] [ECMA262]

If the argument is an object that matches the ArrayBufferView type definition

If the WebSocket connection is established, and the WebSocket closing handshake has not yet started, then the user agent must send a WebSocket Message comprised of data using a binary frame opcode; if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must flag the WebSocket as full and then close the WebSocket connection. The data to be sent is the data stored in the section of the buffer described by the ArrayBuffer object that data references. Any invocation of this method with this kind of argument that does not throw an exception must increase the bufferedAmount attribute by the length of data's buffer in bytes. [WSP] [ECMA262]


The following are the event handlers (and their corresponding event handler event types) that must be supported, as event handler IDL attributes, by all objects implementing the WebSocket interface:

Event handler Event handler event type
onopen open
onmessage message
onerror error
onclose close

13.2 Feedback from the protocol

When the WebSocket connection is established, the user agent must queue a task to run these steps:

  1. If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING (2), and abort these steps. [WSP]

  2. Change the readyState attribute's value to OPEN (1).

  3. Change the extensions attribute's value to the extensions in use, if is not the null value. [WSP]

  4. Change the protocol attribute's value to the subprotocol in use, if is not the null value. [WSP]

  5. Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor. [COOKIES] [ENCODING] [WSP]

  6. Fire a simple event named open at the WebSocket object.


When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps: [WSP]

  1. If the readyState attribute's value is not OPEN (1), then abort these steps.

  2. Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action. [HTML]

  3. Initialise event's origin attribute to the Unicode serialization of the origin of the URL that was passed to the WebSocket object's constructor.

  4. If type indicates that the data is Text, then initialise event's data attribute to data.

    If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data. [FILEAPI]

    If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data. [ECMA262]

  5. Dispatch event at the WebSocket object.

User agents are encouraged to check if they can perform the above steps efficiently before they run the task, picking tasks from other task queues while they prepare the buffers if not. For example, if the binaryType attribute was set to "blob" when the data arrived, and the user agent spooled all the data to disk, but just before running the above task for this particular message the script switched binaryType to "arraybuffer", the user agent would want to page the data back to RAM before running this task so as to avoid stalling the main thread while it created the ArrayBuffer object.

Here is an example of how to define a handler for the message event in the case of text frames:

mysocket.onmessage = function (event) {
  if (event.data == 'on') {
    turnLampOn();
  } else if (event.data == 'off') {
    turnLampOff();
  }
};

The protocol here is a trivial one, with the server just sending "on" or "off" messages.


When the WebSocket closing handshake is started, the user agent must queue a task to change the readyState attribute's value to CLOSING (2). (If the close() method was called, the readyState attribute's value will already be set to CLOSING (2) when this task runs.) [WSP]


When the WebSocket connection is closed, possibly cleanly, the user agent must queue a task to run the following substeps:

  1. Change the readyState attribute's value to CLOSED (3).

  2. If the user agent was required to fail the WebSocket connection, or if the the WebSocket connection was closed after being flagged as full, fire a simple event named error at the WebSocket object. [WSP]

  3. Create a trusted event that uses the CloseEvent interface, with the event type close, which does not bubble, is not cancelable, has no default action, whose wasClean attribute is initialised to true if the connection closed cleanly and false otherwise, whose code attribute is initialised to the WebSocket connection close code, and whose reason attribute is initialised to the result of applying the UTF-8 decoder to the WebSocket connection close reason, and dispatch the event at the WebSocket object. [WSP]

User agents must not convey any failure information to scripts in a way that would allow a script to distinguish the following situations:

  • A server whose host name could not be resolved.
  • A server to which packets could not successfully be routed.
  • A server that refused the connection on the specified port.
  • A server that failed to correctly perform a TLS handshake (e.g., the server certificate can't be verified).
  • A server that did not complete the opening handshake (e.g. because it was not a WebSocket server).
  • A WebSocket server that sent a correct opening handshake, but that specified options that caused the client to drop the connection (e.g. the server specified a subprotocol that the client did not offer).
  • A WebSocket server that abruptly closed the connection after successfully completing the opening handshake.

In all of these cases, the the WebSocket connection close code would be 1006, as required by the WebSocket Protocol specification. [WSP]

Allowing a script to distinguish these cases would allow a script to probe the user's local network in preparation for an attack.

In particular, this means the code 1015 is not used by the user agent (unless the server erroneously uses it in its close frame, of course).


The task source for all tasks queued in this section is the WebSocket task source.

13.3 Ping and Pong frames

The WebSocket protocol specification defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing, latency instrumentation, and so forth. These are not currently exposed in the API.

User agents may send ping and unsolicited pong frames as desired, for example in an attempt to maintain local network NAT mappings, to detect failed connections, or to display latency metrics to the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs whenever appropriate for the server's needs.

13.4 Parsing WebSocket URLs

The steps to parse a WebSocket URL's components from a string url are as follows. These steps return either a host, a port, a resource name, and a secure flag, or they fail.

  1. If the url string is not an absolute URL, then fail this algorithm.

  2. Resolve the url string, with the URL character encoding set to UTF-8. [ENCODING]

    It doesn't matter what it is resolved relative to, since we already know it is an absolute URL at this point.

  3. If the resulting parsed URL does not have a scheme component whose value is either "ws" or "wss", then fail this algorithm.

  4. If the resulting parsed URL has a non-null fragment component, then fail this algorithm.

  5. If the scheme component of the resulting parsed URL is "ws", set secure to false; otherwise, the scheme component is "wss", set secure to true.

  6. Let host be the value of the resulting parsed URL's host component.

  7. If the resulting parsed URL has a port component that is not the empty string, then let port be that component's value; otherwise, there is no explicit port.

  8. If there is no explicit port, then: if secure is false, let port be 80, otherwise let port be 443.

  9. Let resource name be the value of the resulting parsed URL's path component (which might be empty).

  10. If resource name is the empty string, set it to a single character U+002F SOLIDUS (/).

  11. If the resulting parsed URL has a non-null query component, then append a single U+003F QUESTION MARK character (?) to resource name, followed by the value of the query component.

  12. Return host, port, resource name, and secure.

13.5 The CloseEvent interfaces

[Constructor(DOMString type, optional CloseEventInit eventInitDict), Exposed=Window,Worker]
interface CloseEvent : Event {
  readonly attribute boolean wasClean;
  readonly attribute unsigned short code;
  readonly attribute DOMString reason;
};

dictionary CloseEventInit : EventInit {
  boolean wasClean;
  unsigned short code;
  DOMString reason;
};

The wasClean attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to false. It represents whether the connection closed cleanly or not.

The code attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to zero. It represents the WebSocket connection close code provided by the server.

The reason attribute must return the value it was initialised to. When the object is created, this attribute must be initialised to empty string. It represents the WebSocket connection close reason provided by the server.

13.6 Garbage collection

A WebSocket object whose readyState attribute's value was set to CONNECTING (0) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for open events, message events, error events, or close events.

A WebSocket object whose readyState attribute's value was set to OPEN (1) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for message events, error, or close events.

A WebSocket object whose readyState attribute's value was set to CLOSING (2) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for error or close events.

A WebSocket object with an established connection that has data queued to be transmitted to the network must not be garbage collected. [WSP]

If a WebSocket object is garbage collected while its connection is still open, the user agent must start the WebSocket closing handshake, with no status code for the Close message. [WSP]


If a user agent is to make disappear a WebSocket object (this happens when a Document object goes away), the user agent must follow the first appropriate set of steps from the following list:

If the WebSocket connection is not yet established [WSP]

Fail the WebSocket connection. [WSP]

If the WebSocket closing handshake has not yet been started [WSP]

Start the WebSocket closing handshake, with the status code to use in the WebSocket Close message being 1001. [WSP]

Otherwise

Do nothing.

13.7 Cross-document messaging

Web browsers, for security and privacy reasons, prevent documents in different domains from affecting each other; that is, cross-site scripting is disallowed.

While this is an important security feature, it prevents pages from different domains from communicating even when those pages are not hostile. This section introduces a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.

13.7.1 Introduction

For example, if document A contains an iframe element that contains document B, and script in document A calls postMessage() on the Window object of document B, then a message event will be fired on that object, marked as originating from the Window of document A. The script in document A might look like:

var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');

To register an event handler for incoming events, the script would use addEventListener() (or similar mechanisms). For example, the script in document B might look like:

window.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.origin == 'http://example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello', e.origin);
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then looks at the message, which it either displays to the user, or responds to by sending a message back to the document which sent the message in the first place.

13.7.2 Security

Use of this API requires extra care to protect users from hostile entities abusing a site for their own purposes.

Authors should check the origin attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites.

Furthermore, even after checking the origin attribute, authors should also check that the data in question is of the expected format. Otherwise, if the source of the event has been attacked using a cross-site scripting flaw, further unchecked processing of information sent using the postMessage() method could result in the attack being propagated into the receiver.

Authors should not use the wildcard keyword (*) in the targetOrigin argument in messages that contain any confidential information, as otherwise there is no way to guarantee that the message is only delivered to the recipient to which it was intended.


Authors who accept messages from any origin are encouraged to consider the risks of a denial-of-service attack. An attacker could send a high volume of messages; if the receiving page performs expensive computation or causes network traffic to be sent for each such message, the attacker's message could be multplied into a denial-of-service attack. Authors are encouraged to employ rate limiting (only accepting a certain number of messages per minute) to make such attacks impractical.

13.7.3 Posting messages

window . postMessage(message, targetOrigin [, transfer ] )

Posts a message to the given window. Messages can be structured objects, e.g. nested objects and arrays, can contain JavaScript values (strings, numbers, Dates, etc), and can contain certain data objects such as File Blob, FileList, and ArrayBuffer objects.

Objects listed in transfer are transferred, not just cloned, meaning that they are no longer usable on the sending side.

If the origin of the target window doesn't match the given origin, the message is discarded, to avoid information leakage. To send the message to the target regardless of origin, set the target origin to "*". To restrict the message to same-origin targets only, without needing to explicitly state the origin, set the target origin to "/".

Throws a DataCloneError exception if transfer array contains duplicate objects or if message could not be cloned.

When posting a message to a Window of a browsing context that has just been navigated to a new Document is likely to result in the message not receiving its intended recipient: the scripts in the target browsing context have to have had time to set up listeners for the messages. Thus, for instance, in situations where a message is to be sent to the Window of newly created child iframe, authors are advised to have the child Document post a message to their parent announcing their readiness to receive messages, and for the parent to wait for this message before beginning posting messages.

13.8 Channel messaging

13.8.1 Introduction

To enable independent pieces of code (e.g. running in different browsing contexts) to communicate directly, authors can use channel messaging.

Communication channels in this mechanism are implemented as two-ways pipes, with a port at each end. Messages sent in one port are delivered at the other port, and vice-versa. Messages are asynchronous, and delivered as DOM events.

To create a connection (two "entangled" ports), the MessageChannel() constructor is called:

var channel = new MessageChannel();

One of the ports is kept as the local port, and the other port is sent to the remote code, e.g. using postMessage():

otherWindow.postMessage('hello', 'http://example.com', [channel.port2]);

To send messages, the postMessage() method on the port is used:

channel.port1.postMessage('hello');

To receive messages, one listens to message events:

channel.port1.onmessage = handleMessage;
function handleMessage(event) {
  // message is in event.data
  // ...
}

Data sent on a port can be structured data; for example here an array of strings is passed on a MessagePort:

port1.postMessage(['hello', 'world']);
13.8.1.1 Examples

In this example, two JavaScript libraries are connected to each other using MessagePorts. This allows the libraries to later be hosted in different frames, or in Worker objects, without any change to the APIs.

<script src="contacts.js"></script> <!-- exposes a contacts object -->
<script src="compose-mail.js"></script> <!-- exposes a composer object -->
<script>
 var channel = new MessageChannel();
 composer.addContactsProvider(channel.port1);
 contacts.registerConsumer(channel.port2);
</script>

Here's what the "addContactsProvider()" function's implementation could look like:

function addContactsProvider(port) {
  port.onmessage = function (event) {
    switch (event.data.messageType) {
      'search-result': handleSearchResult(event.data.results); break;
      'search-done': handleSearchDone(); break;
      'search-error': handleSearchError(event.data.message); break;
      // ...
    }
  };
};

Alternatively, it could be implemented as follows:

function addContactsProvider(port) {
  port.addEventListener('message', function (event) {
    if (event.data.messageType == 'search-result')
      handleSearchResult(event.data.results);
  });
  port.addEventListener('message', function (event) {
    if (event.data.messageType == 'search-done')
      handleSearchDone();
  });
  port.addEventListener('message', function (event) {
    if (event.data.messageType == 'search-error')
      handleSearchError(event.data.message);
  });
  // ...
  port.start();
};

The key difference is that when using addEventListener(), the start() method must also be invoked. When using onmessage, the call to start() is implied.

The start() method, whether called explicitly or implicitly (by setting onmessage), starts the flow of messages: messages posted on message ports are initially paused, so that they don't get dropped on the floor before the script has had a chance to set up its handlers.

13.8.1.2 Ports as the basis of an object-capability model on the Web

Ports can be viewed as a way to expose limited capabilities (in the object-capability model sense) to other actors in the system. This can either be a weak capability system, where the ports are merely used as a convenient model within a particular origin, or as a strong capability model, where they are provided by one origin provider as the only mechanism by which another origin consumer can effect change in or obtain information from provider.

For example, consider a situation in which a social Web site embeds in one iframe the user's e-mail contacts provider (an address book site, from a second origin), and in a second iframe a game (from a third origin). The outer social site and the game in the second iframe cannot access anything inside the first iframe; together they can only:

The contacts provider can use these methods, most particularly the third one, to provide an API that can be accessed by other origins to manipulate the user's address book. For example, it could respond to a message "add-contact Guillaume Tell <tell@pomme.example.net>" by adding the given person and e-mail address to the user's address book.

To avoid any site on the Web being able to manipulate the user's contacts, the contacts provider might only allow certain trusted sites, such as the social site, to do this.

Now suppose the game wanted to add a contact to the user's address book, and that the social site was willing to allow it to do so on its behalf, essentially "sharing" the trust that the contacts provider had with the social site. There are several ways it could do this; most simply, it could just proxy messages between the game site and the contacts site. However, this solution has a number of difficulties: it requires the social site to either completely trust the game site not to abuse the privilege, or it requires that the social site verify each request to make sure it's not a request that it doesn't want to allow (such as adding multiple contacts, reading the contacts, or deleting them); it also requires some additional complexity if there's ever the possibility of multiple games simultaneously trying to interact with the contacts provider.

Using message channels and MessagePort objects, however, all of these problems can go away. When the game tells the social site that it wants to add a contact, the social site can ask the contacts provider not for it to add a contact, but for the capability to add a single contact. The contacts provider then creates a pair of MessagePort objects, and sends one of them back to the social site, who forwards it on to the game. The game and the contacts provider then have a direct connection, and the contacts provider knows to only honor a single "add contact" request, nothing else. In other words, the game has been granted the capability to add a single contact.

13.8.1.3 Ports as the basis of abstracting out service implementations

Continuing the example from the previous section, consider the contacts provider in particular. While an initial implementation might have simply used XMLHttpRequest objects in the service's iframe, an evolution of the service might instead want to use a shared worker with a single WebSocket connection.

If the initial design used MessagePort objects to grant capabilities, or even just to allow multiple simultaneous independent sessions, the service implementation can switch from the XMLHttpRequests-in-each-iframe model to the shared-WebSocket model without changing the API at all: the ports on the service provider side can all be forwarded to the shared worker without it affecting the users of the API in the slightest.

13.8.2 Message channels

[Constructor, Exposed=Window,Worker]
interface MessageChannel {
  readonly attribute MessagePort port1;
  readonly attribute MessagePort port2;
};
channel = new MessageChannel()

Returns a new MessageChannel object with two new MessagePort objects.

channel . port1

Returns the first MessagePort object.

channel . port2

Returns the second MessagePort object.

13.8.3 Message ports

Each channel has two message ports. Data sent through one port is received by the other port, and vice versa.

[Exposed=Window,Worker]
interface MessagePort : EventTarget {
  void postMessage(any message, optional sequence<Transferable> transfer);
  void start();
  void close();

  // event handlers
           attribute EventHandler onmessage;
};
// MessagePort implements Transferable;
port . postMessage(message [, transfer] )

Posts a message through the channel. Objects listed in transfer are transferred, not just cloned, meaning that they are no longer usable on the sending side.

Throws a DataCloneError exception if transfer array contains duplicate objects or the source or target ports, or if message could not be cloned.

port . start()

Begins dispatching messages received on the port.

port . close()

Disconnects the port, so that it is no longer active.

13.8.4 Broadcasting to many ports

The API described in this section is controversial, as, in an attempt to solve an architectural memory leak, it instead exposes the details of Garbage Collection. This is a lose-lose scenario. A better solution is really needed here.

Broadcasting to many ports is in principle relatively simple: keep an array of MessagePort objects to send messages to, and iterate through the array to send a message. However, this has one rather unfortunate effect: it prevents the ports from being garbage collected, even if the other side has gone away.

To avoid this problem, the PortCollection object can be used. It acts as an opaque array of MessagePort objects, thus allowing the objects to be garbage collected when they stop being relevant, while still allowing scripts to iterate over the MessagePort objects.

[Constructor, Exposed=Window,Worker]
interface PortCollection {
  void add(MessagePort port);
  void remove(MessagePort port);
  void clear();
  void iterate(PortCollectionCallback callback);
};

callback PortCollectionCallback = void (MessagePort port);
portCollection = new PortCollection()

Returns a new empty PortCollection object.

portCollection . add(port)

Adds port to the collection, if it isn't already present.

portCollection . remove(port)

Removes port from the collection, if it is present.

portCollection . clear()

Removes all ports from the collection.

portCollection . iterate(callback)

Calls callback for each port in the collection.

13.8.5 Ports and garbage collection

Authors are strongly encouraged to explicitly close MessagePort objects to disentangle them, so that their resources can be recollected. Creating many MessagePort objects and discarding them without closing them can lead to high transient memory usage since garbage collection is not necessarily performed promptly, especially for MessagePorts where garbage collection can involve cross-process coordination.

13.9 Broadcasting to other browsing contexts

Pages on a single origin opened by the same user in the same user agent but in different unrelated browsing contexts sometimes need to send notifications to each other, for example "hey, the user logged in over here, check your credentials again".

For elaborate cases, e.g. to manage locking of shared state, to manage synchronisation of resources between a server and multiple local clients, to share a WebSocket connection with a remote host, and so forth, shared workers are the most appropriate solution.

For simple cases, though, where a shared worker would be an unreasonable overhead, authors can use the simple channel-based broadcast mechanism described in this section.

[Constructor(DOMString channel), Exposed=Window,Worker]
interface BroadcastChannel : EventTarget {
  readonly attribute DOMString name;
  void postMessage(any message);
  void close();
           attribute EventHandler onmessage;
};
broadcastChannel = new BroadcastChannel(channel)

Returns a new BroadcastChannel object via which messages for the given channel can be sent and received.

broadcastChannel . name

Returns the channel ID (as passed to the constructor).

broadcastChannel . postMessage(message)

Sends the given message to other BroadcastChannel objects set up for this channel. Messages can be structured objects, e.g. nested objects and arrays.

broadcastChannel . close()

Closes the BroadcastChannel object, opening it up to garbage collection.

Suppose a page wants to know when the user logs out, even when the user does so from another tab at the same site:

var authChannel = new BroadcastChannel('auth');
authChannel.onmessage = function (event) {
  if (event.data == 'logout')
    showLogout();
}

function logoutRequested() {
  // called when the user asks us to log them out
  doLogout();
  showLogout();
  authChannel.postMessage('logout');
}

function doLogout() {
  // actually log the user out (e.g. clearing cookies)
  // ...
}

function showLogout() {
  // update the UI to indicate we're logged out
  // ...
}