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
