- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 8 Jun 2013 10:10:58 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: Glenn Maynard <glenn@zewt.org>, Domenic Denicola <domenic@domenicdenicola.com>, John Barton <johnjbarton@google.com>, johnjbarton <johnjbarton@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>, Anne van Kesteren <annevk@annevk.nl>
On Sat, Jun 8, 2013 at 1:38 AM, Simon Pieters <simonp@opera.com> wrote: > But the spec currently doesn't support error handling with event listeners > in workers. > > When a runtime error occurs in a worker, the following happens, per spec: > > 1. self.onerror is invoked (without an event). > 2. If the error is "handled", abort these steps. > 3. Otherwise, create an ErrorEvent object and fire it on the associated > 'Worker' object in the parent thread. > > (It can then "bubble" further if it's still not "handled", but ErrorEvent is > only fired for Worker objects, not Window or WorkerGlobalScope.) > > Anyway, I guess this was just a tangent. I don't object to changing the spec > as you suggest. The spec currently says that after your 3 steps above, the following should be done. "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 Worker object is in, thus repeating the entire runtime script error reporting process one level up." I interpret that to mean that if the global scope that the Worker is in is a WorkerGlobalScope, then you repeat the 3 steps above. But if the global scope that the Worker is in is a Window, then you fire Window.onerror. This is what we do in Gecko (and IIRC what the spec was based on). So worker errors in dedicated workers do reach the same window.onerror handler as in-page errors do. / Jonas
Received on Saturday, 8 June 2013 17:11:56 UTC