9.4.1. 序論

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

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

9.4.2. 保安

9.4.3. ~messageの投函-法

%window . `postMessage(message, targetOrigin [, transfer ] )$m

%message を %window へ投函する。 %message は有構造~objにもなり得る。 例えば次のものを包含できる：

• 入子にされた~objや配列
• ~JS値（ `string^jT, `number^jT, `Date$jT ~obj, 等々）
• `File$I, `Blob$I, `FileList$I, `ArrayBuffer$I などの，ある種の~data~obj

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

%transfer 内に~listされた~objは、~cloneされるのみならず転送される — すなわち，送信-側からは、それ以降，それらを利用できなくなる。 ◎ Objects listed in transfer are transferred, not just cloned, meaning that they are no longer usable on the sending side.

宛先 %window の生成元が，生成元 %targetOrigin に合致しない場合、情報~漏洩を避けるため，~messageは 破棄される。 生成元に関わらず，~messageを宛先に送信したければ、 %targetOrigin に `*^l を与える。 生成元を明示的に与えずに ~messageを同一生成元の宛先のみに制約したければ、 %targetOrigin に `/^l を与える。 ◎ 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 "/".

次の場合は `DataCloneError$E が投出される ⇒ %transfer 配列が同じ~objを重複して包含する場合／ %message を~cloneできなかった場合 ◎ Throws a "DataCloneError" DOMException if transfer array contains duplicate objects or if message could not be cloned.

注記： ~navigateされたばかりの`閲覧文脈$に属する新たな `Document$I の `Window$I に，~messageを投函した場合、その~messageは，意図された受信者に受信されない見込みが高い — 宛先 `閲覧文脈$内の~scriptは、~messageに対する~listenerを設定しておく時間を要するので。 したがって，具体例として、~messageが 新たに作成された子 `iframe$e の `Window$I に送信される状況においては、作者には、子 `Document$I から先に，受信する用意が整った旨を親~宛に公告する~messageを投函させ、親は，この~messageを待機してから~messageを投函し始めるようにすることを勧める。 ◎ 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.

`Window$I ~obj上の `postMessage( message, targetOrigin, transfer )@m の被呼出時には、次の手続きを走らせ~MUST： ◎ The postMessage(message, targetOrigin, transfer) method, when invoked on a Window object must run the following steps:

1. %宛先~window ~LET 此れ ◎ Let targetWindow be this Window object.
2. %宛先~Realm ~LET %宛先~window の`~Realm$ ◎ Let targetRealm be targetWindow's Realm.
3. %現任の設定群 ~LET `現任の設定群~obj$ ◎ Let incumbentSettings be the incumbent settings object.
4. %宛先~生成元 ~LET ε ◎ ↓
5. ~IF［ %targetOrigin ~EQ U+002F （ `/^l ） ］ ⇒ %宛先~生成元 ~SET %現任の設定群 の`生成元$enV ◎ If targetOrigin is a single U+002F SOLIDUS character (/), then set targetOrigin to incumbentSettings's origin.

6. ~ELIF［ %targetOrigin ~NEQ U+002A （ `*^l ） ］： ◎ Otherwise, if targetOrigin is not a single U+002A ASTERISK character (*), then:

   1. %解析済み~URL ~LET `~URL構文解析する$( %targetOrigin ) ◎ Let parsedURL be the result of running the URL parser on targetOrigin.
   2. ~IF［ %解析済み~URL ~EQ `失敗^i ］ ⇒ ~THROW `SyntaxError$E ◎ If parsedURL is failure, then throw a "SyntaxError" DOMException.
   3. %宛先~生成元 ~SET %解析済み~URL の`生成元$url ◎ Set targetOrigin to parsedURL's origin.
7. %転送-を伴う直列化-結果 ~LET `StructuredSerializeWithTransfer$jA( %message, %transfer ) （例外投出あり） ◎ Let serializeWithTransferResult be StructuredSerializeWithTransfer(message, transfer). Rethrow any exceptions.

8. `投函-済み~message~task源$から，次を走らす`~taskを~queueする$： ◎ Queue a task on the posted message task source to run the following steps:

   1. ~IF［ %宛先~生成元 ~NEQ ε ］~AND［ ( %宛先~window に`結付けられている文書$の`生成元$, %宛先~生成元 ) は`同一生成元$でない ］ ⇒ ~RET ◎ If the targetOrigin argument is not a single literal U+002A ASTERISK character (*) and targetWindow's associated Document's origin is not same origin with targetOrigin, then return.
   2. %生成元 ~LET `生成元を直列化する$( %現任の設定群 の`生成元$enV ) ◎ Let origin be the serialization of incumbentSettings's origin.
   3. %~source ~LET `WindowProxy$I ~objの対応している【？】 %現任の設定群 の`大域~obj$enV （ `Window$I ~obj） ◎ Let source be the WindowProxy object's corresponding to incumbentSettings's global object (a Window object).

   4. %逆直列化-~record ~LET `StructuredDeserializeWithTransfer$jA( %転送-を伴う直列化-結果, %宛先~Realm ) ◎ Let deserializeRecord be StructuredDeserializeWithTransfer(serializeWithTransferResult, targetRealm).

      ここで例外が投出されたときは、~catchして： ◎ If this throws an exception, catch it,＼

      1. %宛先~window に向けて，名前 `messageerror$et の`~eventを発火する$ — `MessageEvent$I を利用し，次のように初期化して ⇒＃ `origin$m 属性 ~SET %生成元, `source$m 属性 ~SET %~source ◎ fire an event named messageerror at targetWindow, using MessageEvent, with the origin attribute initialized to origin and the source attribute initialized to source, and then＼
      2. ~RET ◎ abort these steps.
   5. %~message~clone ~LET %逆直列化-~record . `Deserialized^sl ◎ Let messageClone be deserializeRecord.[[Deserialized]].
   6. %新~port~list ~LET %逆直列化-~record . `TransferredValues^sl 内の すべての `MessagePort$I ~objからなる，同順の新たな`凍結~配列$ ◎ Let newPorts be a new frozen array consisting of all MessagePort objects in deserializeRecord.[[TransferredValues]], if any, maintaining their relative order.
   7. %宛先~window に向けて，名前 `message$et の`~eventを発火する$ — `MessageEvent$I を利用し，次のように初期化して ⇒＃ `origin$m 属性 ~SET %生成元, `source$m 属性 ~SET %~source, `data$m 属性 ~SET %~message~clone, `ports$m 属性 ~SET %新~port~list ◎ Fire an event named message at targetWindow, using MessageEvent, with the origin attribute initialized to origin, the source attribute initialized to source, the data attribute initialized to messageClone, and the ports attribute initialized to newPorts.

9.5.1. 序論

`~channel~messaging$ 【channel messaging （ “~channelを介した~messageの送信-法” ）】 を利用すれば、作者は，独立な~code片どうし（例えば，異なる`閲覧文脈$内で走っているもの）を 直に通信させれる。 ◎ To enable independent pieces of code (e.g. running in different browsing contexts) to communicate directly, authors can use channel messaging.

この仕組みにおける通信~channelは、両端に~portを伴う，二重化された~pipeとして実装される。 一方の~portに送信される~messageは，他方の~portに送達され、逆も同様になる。 各~messageは、走っている`~task$を中断したり阻むことなく，~DOM~eventとして送達される。 ◎ 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 delivered as DOM events, without interrupting or blocking running tasks.

接続（ “連絡された” 2 個の~port）を作成するためには、 `MessageChannel()$m 構築子を~callする： ◎ To create a connection (two "entangled" ports), the MessageChannel() constructor is called:

var %channel = new MessageChannel();

一方の~portは 局所~portとして保たれ、他方の~portは ~remote~codeへ送信される — 例えば `window.postMessage()$m を用いて： ◎ 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', 'https://example.com', [%channel.port2]);

~messageを送信するためには、局所~port上の ``postMessage()$m ~methodを利用する： ◎ To send messages, the postMessage() method on the port is used:

%channel.port1.postMessage('hello');

~messageを受信するためには、 `message$et ~eventを~listenする： ◎ To receive messages, one listens to message events:

%channel.port1.onmessage = handleMessage;
function handleMessage(%event) {
  /* 
~messageは %event の`data$m 属性~内にある
◎
message is in event.data
 */
  // ...
}

~portに送信する~dataは、有構造~dataも可能である。 例えば，次では、一連の文字列からなる配列が `MessagePort$I に渡される： ◎ Data sent on a port can be structured data; for example here an array of strings is passed on a MessagePort:

%channel.port1.postMessage(['hello', 'world']);

<script src="contacts.js"></script> <!-- 
%contacts ~objを公開する
◎
exposes a contacts object
 -->
<script src="compose-mail.js"></script> <!-- 
%composer ~objを公開する
◎
exposes a composer object
 -->
<script>
 var %channel = new MessageChannel();
 %composer.addContactsProvider(%channel.port1);
 %contacts.registerConsumer(%channel.port2);
</script>

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;
      // ...
    }
  };
};

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();
};

9.5.2. ~message~channel

[Constructor, Exposed=(Window,Worker)]
interface `MessageChannel@I {
  readonly attribute `MessagePort$I `port1$m;
  readonly attribute `MessagePort$I `port2$m;
};

%channel = new `MessageChannel()$m

2 個の新たな `MessagePort$I ~objが伴われた，新たな `MessageChannel$I ~objを返す。 ◎ Returns a new MessageChannel object with two new MessagePort objects.

%channel . `port1$m

1 個目の `MessagePort$I ~objを返す。 ◎ Returns the first MessagePort object.

%channel . `port2$m

2 個目の `MessagePort$I ~objを返す。 ◎ Returns the second MessagePort object.

`MessageChannel()@m

この構築子の被呼出時には、次を走らせ~MUST： ◎ When the MessageChannel() constructor is called, it must run the following algorithm:

1. %port1 ~LET `~MessagePort~objを作成する$( `現任の設定群~obj$ ) ◎ Create a new MessagePort object whose owner is the incumbent settings object, and let port1 be that object.
2. %port2 ~LET `~MessagePort~objを作成する$( `現任の設定群~obj$ ) ◎ Create a new MessagePort object whose owner is the incumbent settings object, and let port2 be that object.
3. `~portを連絡する$( %port1, %port2 ) ◎ Entangle the port1 and port2 objects.
4. %~channel ~LET 新たな `MessageChannel$I ~obj ◎ Instantiate a new MessageChannel object, and let channel be that object.
5. %~channel の `port1$m 属性 ~SET %port1 ◎ Let the port1 attribute of the channel object be port1.
6. %~channel の `port2$m 属性 ~SET %port2 ◎ Let the port2 attribute of the channel object be port2.
7. ~RET %~channel ◎ Return channel.

`port1@m

`port2@m

いずれの取得子も、此れの作成-時にあてがわれた値を返さ~MUST。 ◎ The port1 and port2 attributes must return the values they were assigned when the MessageChannel object was created.

9.5.3. ~message~port

各~channelは、 2 個の~message~portを持つ。 一方の~portから送信された~dataは，他方の~portに受信され、逆も同様になる。 ◎ Each channel has two message ports. Data sent through one port is received by the other port, and vice versa.

[Exposed=(Window,Worker,AudioWorklet) `Transferable$]
interface `MessagePort@I : `EventTarget$I {
  void ``postMessage$m(any %message, optional sequence<`object$I> %transfer = []);
  void ``start$m();
  void ``close$m();

  // event handlers
  attribute `EventHandler$I ``onmessage$m;
  attribute `EventHandler$I ``onmessageerror$m;
};

%port . ``postMessage( message [, transfer] )$m

~channelを通して~messageを投函する。 %transfer 内に~listされた~objは、~cloneされるのみならず転送される — すなわち，送信-側からは、それ以降，それらを利用できなくなる。 ◎ 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.

次の場合は `DataCloneError$E が投出される ⇒ %transfer が 同じ［ ~obj／~port ］を重複して包含する場合 ／ %message を~cloneできなかった場合 ◎ Throws a "DataCloneError" DOMException if transfer contains duplicate objects or port, or if message could not be cloned.

%port . ``start()$m

この~portに受信される／された~messageを配送させ始める。 ◎ Begins dispatching messages received on the port.

%port . ``close()$m

この~portを切断する。 以降、この~portは 作動中でなくなる。 ◎ Disconnects the port, so that it is no longer active.

ある~port %P の`~port~message~queue$ %Q が可能化されたときは、 `~event-loop$は， %Q をその`~task源$の一つとして利用し~MUST。 %P の`所有者$が指定する`担当の~event-loop$が`閲覧文脈~event-loop$である場合、 %Q に~queueされた`~task$に結付けられる文書は，［ %P の`所有者$が指定する`担当の文書$ ］にされ~MUST。 ◎ When a port's port message queue is enabled, the event loop must use it as one of its task sources. When a port's owner specifies a responsible event loop that is a browsing context event loop, all tasks queued on its port message queue must be associated with the responsible document specified by the port's owner.

注記： ~portの`所有者$が指定する`担当の文書$が`全部的に作動中$であって、~portに登録されたすべての~event~listenerの~scriptは，［ その`設定群~obj$が `全部的に作動中$でない`担当の文書$を指定する ］場合、~queueされた~messageたちは，失われることになる。 ◎ If the port's owner specifies a responsible document that is fully active, but the event listeners all have scripts whose settings objects specify responsible documents that are not fully active, then the messages will be lost.

［ `MessagePort$I の`搬送-済み~flag$ ~EQ ~OFF ］の下では、その`~port~message~queue$は，`~event-loop$の目的においては無視され~MUST（代わりに，`未搬送の~port~message~queue$が利用される）。 ◎ When a MessagePort's has been shipped flag is false, its port message queue must be ignored for the purposes of the event loop. (The unshipped port message queue is used instead.)

注記： `MessagePort$I ~obj %P の`搬送-済み~flag$は、［ %P, %P の相手~側~port, %P の~clone元~obj ］のいずれかが，転送されるか, すでにされている ］ときに ~ON にされる。 %P の`搬送-済み~flag$が ~ON にされて以降は、 %P の`~port~message~queue$は first-class `~task源$ 【すなわち， “通常の，独立な” ~task源】 として動作し，`未搬送の~port~message~queue$には影響しなくなる 【その一部を成さなくなる】。 ◎ The has been shipped flag is set to true when a port, its twin, or the object it was cloned from, is or has been transferred. When a MessagePort's has been shipped flag is true, its port message queue acts as a first-class task source, unaffected to any unshipped port message queue.

~UAは， `~MessagePort~objを作成する@ ときは、所与の ( `環境~設定群~obj$ %所有者 ) に対し，新たな `MessagePort$I ~objを［ その`所有者$ ~SET %所有者 ］とした上で返さ~MUST。 ◎ When the user agent is to create a new MessagePort object with a particular environment settings object as its owner, it must instantiate a new MessagePort object, and let its owner be owner.

~UAは， `~portを連絡する@ ときは、所与の 2 個の `MessagePort$I ~obj ( %A, %B ) に対し，次の手続きを走らせ~MUST： ◎ When the user agent is to entangle two MessagePort objects, it must run the following steps:

1. ~EACH ( %P ~IN { %A, %B } ) に対し ⇒ ~IF［ %P に連絡されている別の `MessagePort$I ~obj %Q がある ］ ⇒ %P と %Q との連絡を解く ◎ If one of the ports is already entangled, then disentangle it and the port that it was entangled with.

   注記： %P, %Q が，ある `MessageChannel$I ~obj %C の 2 個の~portであった場合、 %C は最早~実際の~channelを表現しなくなる — それ以降、 %P と %Q が連絡されることはない。 ◎ If those two previously entangled ports were the two ports of a MessageChannel object, then that MessageChannel object no longer represents an actual channel: the two ports in that object are no longer entangled.

2. %A, %B を，ある新たな~channelの 2 個の部位を形成するように結付けて連絡する（その~channelを表現する `MessageChannel$I ~objは，まだない） ◎ Associate the two ports to be entangled, so that they form the two parts of a new channel. (There is no MessageChannel object that represents this channel.)

   この時点で %A, %B は 互いに連絡されたことになる。 ◎ Two ports A and B that have gone through this step are now said to be entangled; one is entangled to the other, and vice versa.

   注記： この仕様は，この処理-を instantaneous として述べるが、実装は，~message passing 【？】を介して実装する見込みが高い。 要は、他の~algoと同様，その最終的な結果が、~black-box的意味で “単に” 仕様が定めるものと判別できなければよい。 ◎ While this specification describes this process as instantaneous, implementations are more likely to implement it via message passing. As with all algorithms, the key is "merely" that the end result be indistinguishable, in a black-box sense, from the specification.

`MessagePort$I ~objは`転送-可能$である。 ◎ MessagePort objects are transferable objects.＼

その`転送-手続き$は、所与の ( %値, %~data保持体 ) に対し，次を走らす： ◎ Their transfer steps, given value and dataHolder, are:＼

1. %値 の`搬送-済み~flag$ ~SET ~ON ◎ Set value's has been shipped flag to true.
2. %~data保持体 . `PortMessageQueue^sl ~SET %値 の`~port~message~queue$ ◎ Set dataHolder.[[PortMessageQueue]] to value's port message queue.

3. ~IF［ ある別~port %~remote~port が %値 に連絡されている ］： ◎ If value is entangled with another port remotePort, then:

   1. %~remote~port の`搬送-済み~flag$ ~SET ~ON ◎ Set remotePort's has been shipped flag to true.

   2. %~data保持体 . `RemotePort^sl ~SET %~remote~port ◎ Set dataHolder.[[RemotePort]] to remotePort.

4. ~ELSE ⇒ %~data保持体 . `RemotePort^sl ~SET ~NULL ◎ Otherwise, set dataHolder.[[RemotePort]] to null.

その`転送-受信-時の手続き$は、所与の ( %~data保持体, %値 ) に対し，次を走らす： ◎ Their transfer-receiving steps, given dataHolder and value, are:

1. %値 の`搬送-済み~flag$ ~SET ~ON ◎ Set value's has been shipped flag to true.
2. %所有者 ~LET %値 に`関連する設定群~obj$ ◎ ↓
3. %値 の`所有者$ ~SET %所有者 ◎ Set value's owner to value's relevant settings object.

4. %~data保持体 . `PortMessageQueue^sl 内の［ `message$et ~eventを発火する`~task$ ］すべてを %値 の`~port~message~queue$に移動する — その際には： ◎ Move all the tasks that are to fire message events in dataHolder.[[PortMessageQueue]] to the port message queue of value, if any,＼

   • %値 の`~port~message~queue$は，（初期~時の）不能化~状態のまま変えない ◎ leaving value's port message queue in its initial disabled state, and,＼
   • ［ %所有者 が指定する`担当の~event-loop$は `閲覧文脈~event-loop$である ］場合、移動された`~task$に， %所有者 が指定する`担当の文書$を結付ける ◎ if value's owner specifies a responsible event loop that is a browsing context event loop, associating the moved tasks with the responsible document specified by value's owner.
5. ~IF［ %~data保持体 . `RemotePort^sl ~NEQ ~NULL ］ ⇒ `~portを連絡する$( %~data保持体 . `RemotePort^sl, %値 ) ⇒ （これは、元の転送された~portと %~data保持体 . `RemotePort^sl との連絡を解くことになる。） ◎ If dataHolder.[[RemotePort]] is not null, then entangle dataHolder.[[RemotePort]] and value. (This will disentangle dataHolder.[[RemotePort]] from the original port that was transferred.)

``postMessage( message, transfer )@m

被呼出時には、次の手続きを走らせ~MUST： ◎ The postMessage(message, transfer) method, when invoked on a MessagePort object, must run the following steps:

1. %宛先~port ~LET 此れに連絡されている~portが［ 在るならば それ ／ 無いならば ~NULL ］ ◎ Let targetPort be the port with which this MessagePort is entangled, if any; otherwise let it be null.
2. ~IF［ 此れ ~IN %transfer ］ ⇒ ~THROW `DataCloneError$E ◎ If transfer contains this MessagePort, then throw a "DataCloneError" DOMException.
3. %破棄予定 ~LET ~F ◎ Let doomed be false.

4. ~IF［ %宛先~port ~NEQ ~NULL ］~AND［ %宛先~port ~IN %transfer ］：

   1. %破棄予定 ~SET ~T
   2. 任意選択で ⇒ %宛先~port が自身に向けて投函された結果，通信~channelは失われることを、~UAの開発者~consoleに報告する
   ◎ If targetPort is not null and transfer contains targetPort, then set doomed to true and optionally report to a developer console that the target port was posted to itself, causing the communication channel to be lost.
5. %転送-を伴う直列化-結果 ~LET `StructuredSerializeWithTransfer$jA( %message, %transfer ) （例外投出あり） ◎ Let serializeWithTransferResult be StructuredSerializeWithTransfer(message, transfer). Rethrow any exceptions.
6. ~IF［ %宛先~port ~EQ ~NULL ］~OR［ %破棄予定 ~EQ ~T ］ ⇒ ~RET ◎ If targetPort is null, or if doomed is true, then return.

7. 次の手続きを走らす`~task$を %宛先~port の`~port~message~queue$に追加する： ◎ Add a task that runs the following steps to the port message queue of targetPort:

   1. %最終~宛先~port ~LET この~taskが見出される`~port~message~queue$を持つ `MessagePort$I ~obj ◎ Let finalTargetPort be the MessagePort in whose port message queue the task now finds itself.

      これは %宛先~port と異なり得る — %宛先~port 自身が転送されるに伴い，その~taskすべても移動された場合には。 ◎ This can be different from targetPort, if targetPort itself was transferred and thus all its tasks moved along with it.

   2. %宛先~Realm ~LET %最終~宛先~port に`関連する~Realm$ ◎ Let targetRealm be finalTargetPort's relevant Realm.

   3. %逆直列化-~record ~LET `StructuredDeserializeWithTransfer$jA( %転送-を伴う直列化-結果, %宛先~Realm ) ◎ Let deserializeRecord be StructuredDeserializeWithTransfer(serializeWithTransferResult, targetRealm).

      ここで例外が投出されたときは、~catchして： ◎ If this throws an exception, catch it,＼

      1. %最終~宛先~port に向けて，名前 `messageerror$et の`~eventを発火する$ — `MessageEvent$I を利用して ◎ fire an event named messageerror at finalTargetPort, using MessageEvent, and then＼
      2. ~RET ◎ abort these steps.
   4. %~message~clone ~LET %逆直列化-~record . `Deserialized^sl ◎ Let messageClone be deserializeRecord.[[Deserialized]].
   5. %新~port~list ~LET %逆直列化-~record . `TransferredValues^sl 内の すべての `MessagePort$I ~objからなる，同順の新たな`凍結~配列$ ◎ Let newPorts be a new frozen array consisting of all MessagePort objects in deserializeRecord.[[TransferredValues]], if any, maintaining their relative order.
   6. %最終~宛先~port に向けて，名前 `message$et の`~eventを発火する$ — `MessageEvent$I を利用し，次のように初期化して ⇒＃ `data$m 属性 ~SET %~message~clone, `ports$m 属性 ~SET %新~port~list ◎ Fire an event named message at finalTargetPort, using MessageEvent, with the data attribute initialized to messageClone and the ports attribute initialized to newPorts.

``start()@m

被呼出時には、此れの`~port~message~queue$を — まだ可能化されていなければ — 可能化し~MUST。 ◎ The start() method, when invoked, must enable this MessagePort object's port message queue, if it is not already enabled.

``close()@m

被呼出時には、次を走らせ~MUST： ◎ The close() method, when invoked, must run these steps:

1. 此れの `Detached$sl 内部~slot ~SET ~T ◎ Set this MessagePort object's [[Detached]] internal slot value to true.
2. ~IF［ 此れに別~portが連絡されている ］ ⇒ その連絡を解く ◎ If this MessagePort object is entangled, disentangle it.

`MessagePort$I ~interfaceを実装している~すべての~objは、以下に挙げる`~event~handler$, および対応する`~event~handler~event型$を，`~event~handler~IDL属性$として~supportし~MUST： ◎ 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 MessagePort interface:

%P の`~port~message~queue$は、 `MessagePort$I ~obj %P の ``onmessage$m ~IDL属性が初回に設定された時点で， %P の ``start()$m ~methodが~callされたかのように可能化され~MUST。 ◎ The first time a MessagePort object's onmessage IDL attribute is set, the port's port message queue must be enabled, as if the start() method had been called.

9.5.4. 多数の~portへの~broadcast法

多数の~portへ~broadcastすることは、原則的には，比較的~単純であり、~messageを送信-用の `MessagePort$I ~objからなる配列を保っておいて，配列~内を反復して, ~messageを送信すればよい。 しかしながら、相手~側が消去っても それらの~portを~garbage収集できなくなるという，困った効果もある。 この問題を避けるには、相手~側から自身の存在を認知させるような，単純な~protocolを実装するとよい — 一定時間そうしなかったなら，消去ったと見做して、 `MessagePort$I ~objを~closeすることにより，~garbage収集に任せるような。 ◎ 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, implement a simple protocol whereby the other side acknowledges it still exists. If it doesn't do so after a certain amount of time, assume it's gone, close the MessagePort object, and let it be garbage collected.

9.5.5. ~portと~garbage収集

更には， `MessagePort$I ~obj %O は、次のいずれかが満たされている間は，~garbage収集されては~MUST_NOT： ◎ Furthermore, a MessagePort object must not be garbage collected＼

• ある`~task~queue$内の ある`~task$が、 %O に向けて配送される~eventを参照している ◎ while there exists an event referenced by a task in a task queue that is to be dispatched on that MessagePort object, or＼
• %O の`~port~message~queue$は、空でない, かつ 可能化されている ◎ while the MessagePort object's port message queue is enabled and not empty.

注記： 作者には、 `MessagePort$I ~objを明示的に~closeして，それらの連絡を解くことが強く奨励される — そうすれば、それらの資源は再収集できるようになる。 多数の `MessagePort$I ~objを作成して，それらを~closeすることなく破棄することは、一時的に多量の~memoryを~~消費させ得る — ~garbage収集は、とりわけ， `MessagePort$I に対する~garbage収集に~cross-processの協調も孕まれ得る所では、即座に遂行されるとは限らないので。 ◎ 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.