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: Sergey Ilinsky <sergey@backbase.com>
Date: Wed, 15 Mar 2006 11:55:44 +0100
Message-ID: <014d01c6481f$024a5610$8132a8c0@vientiane>
To: <cjolif@ilog.fr>
Cc: "Web APIs Public" <public-webapi@w3.org>
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> 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
> 
> 
> 
> 
> 
> 
Received on Wednesday, 15 March 2006 10:56:01 GMT

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