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

* Ian Hickson wrote:
>The usual pattern when dispatching an event is:
>
>   <something happens>
>   dispatch an event to notify user code!
>   was the event canceled? if not, do the default action
>
>It would be weird if this wasn't synchronous. I'm not really sure how you 
>would do the default action. Certainly it would mean that the default 
>action was no longer in the same task as the <something happens>, which is 
>weird. Think about browser events (either by analogy or as a concrete 
>example, depending on whether you'd want this to apply to all events or 
>only those dispatched from script): you click on a checkbox, its .value 
>changes, an event is fired, and if it's canceled, the .value is changed 
>back. It'd be pretty weird if this happened asynchronously.

That case does not match the usual pattern you describe above, rather it
is doing the default action, dispatching the event, and than undoing the
default action. And even the usual pattern is fairly defective when you
have more than one listener and only want to react to an event if it is
not canceled by any of the listeners, or want to undo any side-effects
if it was canceled as the case may be; only the dispatching code can do
that properly.

A simple example would be a listener on a <form> element that cancels
all checkbox clicks if some condition is not met, and some listeners on
the checkboxes that trigger side-effects assuming that the clicks will
not be canceled. That will result in an inconsistent application state,
and the only way to avoid that is to trigger the side-effects after the
dispatchEvent call has returned, only then would it be known whether any
of the listeners prevented the default action. And when you do that, I
do not really see how asynchronous dispatch would add much weirdness.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Monday, 17 June 2013 22:51:36 UTC