- From: Travis Leithead <travil@windows.microsoft.com>
- Date: Tue, 3 Jun 2008 15:01:09 -0700
- To: "public-webapi@w3.org" <public-webapi@w3.org>, Doug Schepers <schepers@w3.org>
- Message-ID: <0003CB8B8FE2154EB50431DB2B8F69C00A306FF4C5@NA-EXMSG-W601.wingroup.windeploy.ntd>
Interesting findings (mostly related to IE): This test tries to define if the HTML event handlers (onFoo) are linked to the add/removeEventListener APIs in any way (or to define what the relationship is). Browsers tested: Opera 9.25, Firefox 3 RC1, IE8 Beta1, Safari 3.1.1. (on IE, I substituted attach/detachEvent for add/removeEventListener) The findings appear to indicate that: 1. All tested browsers follow a basic model in that an HTML event handler is maintained separately (perhaps in a separate queue) from event handlers attached via programmatic means (e.g., addEventListener/attachEvent). This can be verified by adding an HTML event handler and then trying to delete the reference to its DOM attribute via removeEventListener. In addition to this basic conclusion, there were a few discrepencies in event handling that should be noted: * IE/Firefox/Opera all keep a reference alive to the HTML event handler via the element's 'onclick' DOM attribute even after the content attribute has been removed. * Safari also keeps a reference to the element's 'onclick' handler, yet the "body" of the handler may be missing if the element's content attribute is removed (this prevents adding an event listener via the DOM attribute if the content attribute is missing). * IE's attachEvent is cumulative, despite re-applying the same handler over and over. detachEvent works in reverse, removing references until none are left. * IE has a bug that HTML event handlers are not actually removed via removeAttribute (though the attribute itself is removed). This is being fixed in IE8, but does impact this test page :(
Attachments
- text/html attachment: event handler relationships.htm
Received on Tuesday, 3 June 2008 22:01:52 UTC