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

On 6/3/13 11:48 PM, John Barton wrote:
> Ultimately targetElement.dispatchEvent(event) has a primary job: queue
> events for processing in the same way that events are queued when we
> interact with the UI.

It's primary job is to dispatch the event and run all the handlers.

> (We don't need dispatchEvent(), we could call the
> handlers directly if we want, so why don't we?

Because you can't in fact call them all directly: there is no way to get 
the list of all handlers, and you didn't necessarily register them all. 
  For one thing, often some of the handlers are registered by the UA 
itself (sometimes as capturing listeners, sometimes as default actions).

> That primary job got compromised when the
> the fundamentally asynchronous mission was shoe horned in to a
> synchronous call with a return value.

You mean at the moment the API was initially added, right?

You may well be right that at the time it would have been better to 
design it the way you suggest, with the dispatch happening async.  It 
sure would have made a lot of things easier in the implementation of a 
UA.  But that didn't happen, and content very much depends on the 
current behavior....

So if you want a different behavior, you need a different API.  Except 
of course the "easier implementation" argument no longer applies.

-Boris

Received on Tuesday, 4 June 2013 12:46:01 UTC