- From: Web APIs Issue Tracker <dean+cgi@w3.org>
- Date: Wed, 19 Apr 2006 11:55:34 +0000 (GMT)
- To: public-webapi@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 UTC