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

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

From: Web APIs Issue Tracker <dean+cgi@w3.org>
Date: Wed, 19 Apr 2006 11:55:34 +0000 (GMT)
To: public-webapi@w3.org
Message-Id: <20060419115534.262C347B98@mojo.w3.org>


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.

So, do we want the current behavior?
Received on Wednesday, 19 April 2006 11:55:42 GMT

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