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

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 3 Jun 2013 15:53:47 +0100
Message-ID: <CADnb78i-1RBVqKZDDUVug8caPg800UNVsdxdx+LnNjbjA3vRpw@mail.gmail.com>
To: John Barton <johnjbarton@google.com>, "www-dom@w3.org" <www-dom@w3.org>
On Mon, Jun 3, 2013 at 3:49 PM, John Barton <johnjbarton@google.com> wrote:
> Sorry I intended to reply all, but failed. Can we move this back to the
> group?

Okay, done.

> On Mon, Jun 3, 2013 at 7:40 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> The callback is invoked in its own JS stack iirc. Agreed that the
>> language needs to be made clearer in due course.
> Yes, the listener is called on a JS stack where it appears to have no JS
> caller. However this is not the same as an asynchronous event turn. The JS
> caller of dispatchEvent() is blocked, the listener is called on its own new
> stack, the exception occurs, the new stack unwinds, the exception is queue
> for printing, and then finally the JS caller of dispatchEvent() is
> unblocked; somewhere in there the exception is printed.

Yes, it'll reach window.error.

> The JS event-loop is a critical feature of the system and this kind of
> behavior is confusing.

It does not seem too confusing to me for event callback exceptions to
never propagate up to dispatchEvent(), especially given they execute
in their own context. We can't modify this either I think, though
you're welcome to try in Chrome and report back.

Received on Monday, 3 June 2013 14:54:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:02 UTC