Re: DOML3: ACTION-266: TRAVIS - Test addEventListener vs onFoo attribute
Travis Leithead wrote: 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. This is not true. You are assuming that the EventListener object used for onfoo attributes is the onfoo object itself. This is not the case in firefox, nor would I expect it to be the case anywhere else. Instead we create a separate EventListener object which wraps the onfoo object and deals with things like calling .preventDefault() if the onfoo object returns false. It also does lazy compilation when onfoo is set via setAttribute(onfoo, your code here); In firefox i think onfoo listeners do go in the same list as other event listeners, however you can't get to the EventListener object itself, so you won't be able to remove it using removeEventListener. A better way to test for this would be something like: myElem.addEventListener(click, listener1, false); myElem.onclick = listener2; myElem.addEventListener(click, listener3, false); And then check in which order the three listeners are called. If attribute listeners end up in the same list as normal listeners then the calling order should be: listener1, listener2, listener3. 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. Hmm.. this sounds like a bug to me. I would have expected .removeAttribute(onclick) to remove the .onclick attribute. / Jonas
DOML3: ACTION-266: TRAVIS - Test addEventListener vs onFoo attribute
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 :( Title: onFoo versus programmatic event handlers onFoo versus add/removeEventListener(foo) This test checks the relationship between HTML inline event handlers and programmatically-added event handlers for both the Microsoft and W3C event handling models. The box below is the testing area for mouse events. It has no events attached by default when the page loads. The buttons below the box control the adding/removing of the following event handler to the box: onclick - cycle the color of the box from (0)red -> (1)orange -> (2)yellow -> (3)green -> (4)blue The buttons below it control the dynamic addition/removal of the event via the various dynamic mechanisms supported by browsers. 0 Event handler manipulation via the Element Event handler manipulation via the EventTarget Handler Attached: no Event handler manipulation via the EventTarget with references to the Element's DOM property Handler Attached: no
