Skip to content

Commit

Permalink
Meta: remove "ILLFATED" MessagePort design
Browse files Browse the repository at this point in the history
  • Loading branch information
annevk authored and domenic committed Apr 25, 2017
1 parent 793ace8 commit 1208d25
Showing 1 changed file with 2 additions and 53 deletions.
55 changes: 2 additions & 53 deletions source
Original file line number Diff line number Diff line change
Expand Up @@ -95844,8 +95844,7 @@ interface <dfn>MessagePort</dfn> : <span>EventTarget</span> {
// event handlers
attribute <span>EventHandler</span> <span data-x="handler-MessagePort-onmessage">onmessage</span>;
attribute <span>EventHandler</span> <span data-x="handler-MessagePort-onmessageerror">onmessageerror</span>;
<!--ILLFATED attribute <span>EventHandler</span> <span data-x="handler-MessagePort-onerror">onerror</span>;
-->};</pre>
};</pre>

<dl class="domintro">

Expand Down Expand Up @@ -96101,55 +96100,6 @@ interface <dfn>MessagePort</dfn> : <span>EventTarget</span> {
disentangle the two ports. If the method is called on a port that is not entangled, then the
method must do nothing.</p>

<!--ILLFATED (search for '- -')
<hr>

<p>In some circumstances, an entangled <code>MessagePort</code> <var>source port</var>
that is not <a href="#ports-and-garbage-collection">eligible for garbage collection</a> will
nonetheless find itself prematurely destroyed, for example if the user manually terminates the
user agent's host process. Under such circumstances, user agents should attempt to following these
steps:</p>

<!- - don't fire this for navigation, it would break bfcache - ->
<!- - for consistency, we don't fire this for worker termination - ->
<!- - we don't fire it on .close() because that would let you probe GC behavior also - ->

<ol>

<li><p>Let <var>target port</var> be the port with which the ill-fated <var>source port</var> is entangled.</p></li>

<li><p>If there is no <var>target port</var> (i.e. if <var>source port</var>
is not entangled), or if <var>target port</var> is suffering the same fate as <var>source port</var> (e.g. if both ports are in the same host process), then abort these
steps.</p></li>

<li><p>Mark <var>target port</var> as being a <dfn>related to an ill-fated
port</dfn>.</p></li>

<li><p>Create a <span data-x="concept-task">task</span> that <span
data-x="concept-event-fire">fires an event</span> named <code data-x="event-error">error</code>
at <var>target port</var>, and add the <span data-x="concept-task">task</span> to the <span>port
message queue</span> of <var>target port</var>. If the <var>new port</var>'s <span
data-x="concept-port-owner">owner</span> specifies a <span>responsible event loop</span> that is
a <span>browsing context</span> <span>event loop</span>, the <span
data-x="concept-task">task</span> must be associated with the <span>responsible document</span>
specified by <var>source port</var>'s <span
data-x="concept-port-owner">owner</span>.</p></li>

<!- - X X X if this port can ever itself be transferred, we should update the previous step to
fire the event not on the current target port, but on the port of the port message queue it finds
itself on when executed - - >

<li><p>Disentangle the two ports.</p></li>

</ol>

<p class="note">This does not happen if the port is garbage collected or closed using the <code
data-x="dom-messageport-close">close()</code> method. It is intended only as a way for Web
applications that operate across multiple browser processes (e.g. using workers or communicating
across multiple tabs) to gracefully handle a catastrophic failure in one process. A strictly
conforming user agent would never fail unexpectedly, and thus would never send this event!</p>
-->

<hr>

<p>The following are the <span>event handlers</span> (and their corresponding <span data-x="event
Expand All @@ -96163,8 +96113,7 @@ interface <dfn>MessagePort</dfn> : <span>EventTarget</span> {
<tbody>
<tr><td><dfn><code data-x="handler-MessagePort-onmessage">onmessage</code></dfn> <td> <code data-x="event-message">message</code>
<tr><td><dfn><code data-x="handler-MessagePort-onmessageerror">onmessageerror</code></dfn> <td> <code data-x="event-messageerror">messageerror</code>
<!--ILLFATED <tr><td><dfn><code data-x="handler-MessagePort-onerror">onerror</code></dfn> <td> <code data-x="event-error">error</code>
--> </table>
</table>

<p>The first time a <code>MessagePort</code> object's <code
data-x="handler-MessagePort-onmessage">onmessage</code> IDL attribute is set, the port's <span>port
Expand Down

0 comments on commit 1208d25

Please sign in to comment.