W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: ACTION-76: Build test case for understanding behaviour of redispatching cancelled and stopped events

From: Christophe Jolif <cjolif@ilog.fr>
Date: Wed, 15 Mar 2006 12:00:51 +0100
Message-ID: <4417F3E3.80108@ilog.fr>
To: Sergey Ilinsky <sergey@backbase.com>
CC: Web APIs Public <public-webapi@w3.org>


The thing to notice is that the event has already been fully dispatched 
(got to the top) before being redispatched.

Sergey Ilinsky wrote:
> I guess the correct behaviour is not to allow redispatching
> event that had allready started its flow through DOM,
> since the event object might carry the state, targets etc
> (Looking here from the implementor point of view).
> So redispatching event leaves no chance for the primarily
> dispatched event to continue its normal flow.
>  
> So IE and FF behave correct.
>  
> Regards,
> Sergey/
>  
> --- Christophe Jolif <cjolif@ilog.fr <mailto:cjolif@ilog.fr>> wrote:
>  
>  >
>  > Here are the results of my tests on different user
>  > agents (test cases
>  > varying because of HTML vs. SVG and IE vs. the rest
>  > of the world)
>  >
>  > Firefox 1.5 behavior:
>  >
>  > Firefox throws an exception
>  > (NS_ERRROR_ILLEGAL_VALUE) when trying to
>  > redispatched (calling EventTarget.dispatchEvent())
>  > an already fully
>  > dispatched event. This happens in all cases not
>  > depending on whether the
>  > event has been stopped (stopPropagation()) or
>  > cancelled (preventDefault()).
>  > (side note: calling initEvent() on the event allows
>  > redispatching)
>  >
>  > Internet Explorer 6.0 behavior:
>  >
>  > IE 6.0 throws an exception (Invalid Argument) when
>  > trying to
>  > redispatched (calling fireEvent()) an already fully
>  > dispatched event.
>  > This happens in all cases not depending on whether
>  > the event has been
>  > stopped (cancelBubble=true) or cancelled (event
>  > listener returning true).
>  >
>  > Opera 8.5 behavior:
>  >
>  > Redispatching an already fully dispatched event is
>  > authorized (i.e.
>  > calling EventTarget.dispatchEvent() does not throw
>  > an exception).
>  > However the behavior depend on what happened to the
>  > event in the first
>  > dispatching phase.
>  >
>  > - if the event was not stopped nor cancelled, the
>  > event is redispatched
>  > as a brand new one. With dispatchEvent() returning
>  > true.
>  > - if the event was previously stopped
>  > (stopPropagation()),
>  > dispatchEvent() returns true but the event is not
>  > catch by any listener.
>  > - if the event was previously cancelled
>  > (preventDefault()), the event is
>  > redispatched as a brand new one. With
>  > dispatchEvent() returning false.
>  >
>  > Safari behavior (unknown version):
>  >
>  > Redispatching an already fully dispatched event is
>  > authorized (i.e.
>  > calling EventTarget.dispatchEvent() does not throw
>  > an exception).
>  > However the behavior depend on what happened to the
>  > event in the first
>  > dispatching phase.
>  >
>  > - if the event was not stopped nor cancelled, the
>  > event is redispatched
>  > as a brand new one. With dispatchEvent() returning
>  > true.
>  > - if the event was previously stopped
>  > (stopPropagation()),
>  > dispatchEvent() returns false but the event is not
>  > catch by any listener.
>  > - if the event was previously cancelled
>  > (preventDefault()), the event is
>  > redispatched as a brand new one. With
>  > dispatchEvent() returning false.
>  >
>  > Adobe SVG Viewer 3.0 behavior:
>  >
>  > ASV throws an exception (disposed event) when trying
>  > to redispatched
>  > (calling EventTarget.dispatchEvent()) an already
>  > fully dispatched event.
>  > This happens in all cases not depending on whether
>  > the event has been
>  > stopped (stopPropagation()) or cancelled
>  > (preventDefault()).
>  >
>  > Batik 1.6 behavior:
>  >
>  > Redispatching an already fully dispatched event is
>  > authorized (i.e.
>  > calling EventTarget.dispatchEvent() does not throw
>  > an exception). The
>  > behavior does not depend on what happened to the
>  > event in the first
>  > dispatching phase, in all cases it is like a brand
>  > new event was
>  > dispatched and dispatchEvent always return true.
>  >
>  > (for reminder ACTION-76 was linking to closed
>  > ISSUE-20).
>  > (resolution was: close ISSUE-20 subject to ACTION-76
>  > not turning up
>  > something to contradict)
>  >
>  > --
>  > Christophe
>  > http://jviews.ilog.com
>  >
>  >
>  >
>  >
>  >
>  >


-- 
Christophe
Received on Wednesday, 15 March 2006 11:00:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:53 GMT