- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 3 Jun 2013 15:53:47 +0100
- 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. -- http://annevankesteren.nl/
Received on Monday, 3 June 2013 14:54:14 UTC