W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: Exceptions in event listeners triggered by dispatchEvent().

From: Simon Pieters <simonp@opera.com>
Date: Sat, 08 Jun 2013 10:38:28 +0200
To: "Glenn Maynard" <glenn@zewt.org>
Cc: "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>
Message-ID: <op.wycqaevpidj3kv@simons-macbook-pro.local>
On Fri, 07 Jun 2013 15:40:09 +0200, Glenn Maynard <glenn@zewt.org> wrote:

> On Fri, Jun 7, 2013 at 8:09 AM, Simon Pieters <simonp@opera.com> wrote:
>> Well then those browsers violate the spec and the original
>> implementation... At least Presto implements the spec.
> When IE, Chrome and Firefox all violate the spec in the same way, it's  
> the
> spec that's wrong.  You know that.


>>  (The spec looks incorrect here.  It bypasses event dispatch entirely  
>> and
>>> calls "onerror" directly, which forgets to fire event listeners.  It  
>>> also
>>> doesn't make much sense to support error handling with event listeners  
>>> in
>>> workers but not in the UI thread.  This should probably just fire an
>>> ErrorEvent, and the window.onerror special case should probably be in  
>>> the
>>> event dispatch algorithm.)
>> You misunderstood the worker case. Errors in workers are handled the  
>> same
>> as in window, i.e. onerror is invoked directly. However, if a worker  
>> error
>> is not "handled", an ErrorEvent gets fired on the Worker object.
> Sorry, I don't follow and I don't believe I'm misunderstanding anything.

You said:

>>> It also
>>> doesn't make much sense to support error handling with event listeners  
>>> in
>>> workers but not in the UI thread

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 above describes the *non*-worker behavior.
> http://www.whatwg.org/specs/web-apps/current-work/#report-the-error

Simon Pieters
Opera Software
Received on Saturday, 8 June 2013 08:38:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:21 UTC