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

On Mon, Jun 17, 2013 at 2:27 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Mon, 3 Jun 2013, Jonas Sicking wrote:
> >
> > I think it would be great if dispatchEvent dispatched the event at
> > end-of-microtask or some such.
>
> 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.
>
Check-boxes are changed asynchronously (by XHR processing) all of the time.
On the other hand, the control flow options in dispatchEvent() are --
compared to the rest of JS -- weird. With preventDefault any handler can
block one special kind of action. With stopPropagation any handler can
block a subset of other handlers.
These feature are valuable, but if we're talking weird JS control flow,
they are weird.
(If we have a 'cancelable' flag allowing the dispatching caller to grant a
handler the ability to preventDefault, I don't understand why we can't have
a 'unexceptional' to grant handlers the ability to stop all handlers and
throw in the caller.)
jjb