[html5] r6263 - [giow] (1) Make worker errors propagate all the way up to the Document, hitting [...]

whatwg at whatwg.org whatwg at whatwg.org
Tue Jun 21 14:20:53 PDT 2011


Author: ianh
Date: 2011-06-21 14:20:51 -0700 (Tue, 21 Jun 2011)
New Revision: 6263

Modified:
   complete.html
   source
Log:
[giow] (1) Make worker errors propagate all the way up to the Document, hitting the global scope .onerror each step of the way. This isn't a great way to specify it but I couldn't work out a cleaner way that didn't involve major (potentially risky) surgery and inventing new terms. If it turns out that there are other things that'd need the parent/child infrastructure to be better defined I'll do it then.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=12067

Modified: complete.html
===================================================================
--- complete.html	2011-06-21 07:28:03 UTC (rev 6262)
+++ complete.html	2011-06-21 21:20:51 UTC (rev 6263)
@@ -78026,23 +78026,28 @@
 
   <p>For dedicated workers, if the error is still <i title=concept-error-nothandled><a href=#concept-error-nothandled>not handled</a></i> afterwards, or if
   the error occurred while handling a previous script error, the user
-  agent must <a href=#queue-a-task>queue a task</a> to <a href=#fire-a-worker-error-event>fire a worker error
-  event</a> at the <code><a href=#worker>Worker</a></code> object associated with the
-  worker.</p>
-
-  <p>When the user agent is to <dfn id=fire-a-worker-error-event>fire a worker error event</dfn> at
-  a <code><a href=#worker>Worker</a></code> object, it must create and dispatch an event
-  that uses the <code><a href=#errorevent>ErrorEvent</a></code> interface, with the name <code title=event-error>error</code>, that doesn't bubble and is
+  agent must <a href=#queue-a-task>queue a task</a> to fire an event that uses the
+  <code><a href=#errorevent>ErrorEvent</a></code> interface, with the name <code title=event-error>error</code>, that doesn't bubble and is
   cancelable, with its <code title=dom-ErrorEvent-message><a href=#dom-errorevent-message>message</a></code>, <code title=dom-ErrorEvent-filename><a href=#dom-errorevent-filename>filename</a></code>, and <code title=dom-ErrorEvent-lineno><a href=#dom-errorevent-lineno>lineno</a></code> attributes set
-  appropriately. The default action of this event depends on whether
-  the <code><a href=#worker>Worker</a></code> object is itself in a worker. If it is, and
-  that worker is also a dedicated worker, then the user agent must
-  again <a href=#queue-a-task>queue a task</a> to <a href=#fire-a-worker-error-event>fire a worker error
-  event</a> at the <code><a href=#worker>Worker</a></code> object associated with
-  <em>that</em> worker. Otherwise, then the error may be reported to
-  the user.</p>
+  appropriately, at the <code><a href=#worker>Worker</a></code> object associated with the
+  worker. If the event is not canceled, the user agent must act as if the
+  uncaught runtime script error had occurred in the global scope that
+  the <code><a href=#worker>Worker</a></code> object is in, thus repeating the entire
+  runtime script error reporting process one level up.</p>
 
-  <p>The <a href=#task-source>task source</a> for the tasks mentioned above is the
+  <p>If the implicit port connecting the worker to its
+  <code><a href=#worker>Worker</a></code> object has been disentangled (i.e. if the parent
+  worker has been terminated), then the user agent must act as if the
+  <code><a href=#worker>Worker</a></code> object had no <code title=event-error>error</code> event handler and as if that
+  worker's <code title=handler-WorkerGlobalScope-onerror><a href=#handler-workerglobalscope-onerror>onerror</a></code> attribute
+  was null, but must otherwise act as described above.</p>
+
+  <p class=note>Thus, error reports proagate up to the chain of
+  dedicated workers up to the original <code><a href=#document>Document</a></code>, even if
+  some of the workers along this chain have been terminated and
+  garbage collected.</p>
+
+  <p>The <a href=#task-source>task source</a> for the task mentioned above is the
   <a href=#dom-manipulation-task-source>DOM manipulation task source</a>.</p>
 
   <hr><pre class=idl>interface <dfn id=errorevent>ErrorEvent</dfn> : <a href=#event>Event</a> {
@@ -78656,6 +78661,8 @@
 
 
 
+
+
   </div><!--data-component-->
 
 

Modified: source
===================================================================
--- source	2011-06-21 07:28:03 UTC (rev 6262)
+++ source	2011-06-21 21:20:51 UTC (rev 6263)
@@ -88395,27 +88395,34 @@
   <p>For dedicated workers, if the error is still <i
   title="concept-error-nothandled">not handled</i> afterwards, or if
   the error occurred while handling a previous script error, the user
-  agent must <span>queue a task</span> to <span>fire a worker error
-  event</span> at the <code>Worker</code> object associated with the
-  worker.</p>
-
-  <p>When the user agent is to <dfn>fire a worker error event</dfn> at
-  a <code>Worker</code> object, it must create and dispatch an event
-  that uses the <code>ErrorEvent</code> interface, with the name <code
+  agent must <span>queue a task</span> to fire an event that uses the
+  <code>ErrorEvent</code> interface, with the name <code
   title="event-error">error</code>, that doesn't bubble and is
   cancelable, with its <code
   title="dom-ErrorEvent-message">message</code>, <code
   title="dom-ErrorEvent-filename">filename</code>, and <code
   title="dom-ErrorEvent-lineno">lineno</code> attributes set
-  appropriately. The default action of this event depends on whether
-  the <code>Worker</code> object is itself in a worker. If it is, and
-  that worker is also a dedicated worker, then the user agent must
-  again <span>queue a task</span> to <span>fire a worker error
-  event</span> at the <code>Worker</code> object associated with
-  <em>that</em> worker. Otherwise, then the error may be reported to
-  the user.</p>
+  appropriately, at the <code>Worker</code> object associated with the
+  worker. If the event is not canceled, the user agent must act as if the
+  uncaught runtime script error had occurred in the global scope that
+  the <code>Worker</code> object is in, thus repeating the entire
+  runtime script error reporting process one level up.</p>
 
-  <p>The <span>task source</span> for the tasks mentioned above is the
+  <p>If the implicit port connecting the worker to its
+  <code>Worker</code> object has been disentangled (i.e. if the parent
+  worker has been terminated), then the user agent must act as if the
+  <code>Worker</code> object had no <code
+  title="event-error">error</code> event handler and as if that
+  worker's <code
+  title="handler-WorkerGlobalScope-onerror">onerror</code> attribute
+  was null, but must otherwise act as described above.</p>
+
+  <p class="note">Thus, error reports proagate up to the chain of
+  dedicated workers up to the original <code>Document</code>, even if
+  some of the workers along this chain have been terminated and
+  garbage collected.</p>
+
+  <p>The <span>task source</span> for the task mentioned above is the
   <span>DOM manipulation task source</span>.</p>
 
   <hr>
@@ -89139,6 +89146,8 @@
   interface's <span>relevant namespace object</span> is a
   <code>Window</code> object. <a href="#refsWEBIDL">[WEBIDL]</a></p>
 
+
+
 <!--END workers-->
 <!--END whatwg-workers-->
 




More information about the Commit-Watchers mailing list