Re: ISSUE-77: DOM3EV: Effect of evt.currentTarget.add/removeEL

Web APIs Issue Tracker wrote:
> ISSUE-77: DOM3EV: Effect of evt.currentTarget.add/removeEL
> 
> http://www.w3.org/2005/06/tracker/webapi/issues/77
> 
> Raised by: Bjoern Hoehrmann
> On product: DOM 3 Events
> 
> The effects of evt.currentTarget.add/removeEventListener are well-
> defined in the current draft but implementations vary. I would like
> to confirm that the current requirements are really desired so I
> can improve the wording for it. The effect of
> 
>   evt.currentTarget.addEventListener(...)
> 
> is deferred, the listener will not be triggered by in the current
> phase. The effect of
> 
>   evt.currentTarget.removeEventListener(...)
> 
> is immediate, the removed listener will not be triggered until it
> is added again. This implies that doing (for the same listener)
> 
>   evt.currentTarget.removeEventListener(...)
>   evt.currentTarget.addEventListener(...)
> 
> would prevent the listener from being triggerd in the current
> phase (and the position probably changes when triggered by another
> event). Test cases for this include
> 
> http://bjoernsworld.de/temp/remove-listener-from-current-target.html
> http://bjoernsworld.de/temp/remove-listener-from-current-target.svg
> http://bjoernsworld.de/temp/remove-listener-from-current-target-and-re-add.html
> http://bjoernsworld.de/temp/remove-listener-from-current-target-and-re-add.svg
> 
> Opera9 fails both, Batik 1.6.0 passes both, Mozilla passes the first
> and fails the second, and I'm told for Safari it depends on the version.
> 
> I think it would be more logical if mutations are handled exactly like
> mutations to the document tree affect the DOM event flow, that is, they
> don't affect it at all (the effect would be deferred for both methods);
> failing that it would be more logical if the effect of both methods is
> immediate. I don't feel strongly about changing it though.

I agree, i think having add and remove behave the same would be a good 
idea. I'm not sure if we can actually change this though if the DOM L2 
spec is indeed clear on the behaviour.

I don't really have a very strong oppinion which way to go though.

One argument against deferred modification is that it forces the 
implementation to create a copy of the list of listeners to notify 
before notifying them. This might be expensive since it has to be done 
on every single event target. Though it is possible that this could be 
done lazily.

Another argument against deferred notification is that it might be 
confusing that a removed listener can still be notified.

Also, does the spec say anything about what happens if listeners are 
added or removed on any other EventTarget that is about to get notified 
by the current Event? I couldn't find where in the spec it describes any 
of this.

/ Jonas

Received on Sunday, 23 April 2006 10:51:55 UTC