This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html Multipage: http://www.whatwg.org/C#event-handler-attributes Complete: http://www.whatwg.org/c#event-handler-attributes Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Per spec, event handler attributes either don't work or have the wrong scope Posted from: 173.48.23.63 by bzbarsky@mit.edu User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0
In particular, http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-content-attributes talks about doing the whole compilation dance "when an event handler content attribute is set". It's not clear to me whether http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token step 1 counts as "setting" the event handler content attribute. If it does not, then per spec as currently written the event handler is never compiled. If that step _does_ count, though, then the fact that it comes before http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#create-an-element-for-the-token step 4 means that the "form owner" will not be set yet when the compilation happens. In either case, when combining event handler content attributes with changing form owners things get interesting. I'll post a semi-exhaustive testcase...
Created attachment 1415 [details] A testcase for some of the stuff here
The Gecko behavior is wacky because we freeze the scope chain when we compile the first handler (which we do lazily) or when we create a JS wrapper for the node, whichever happens first. The Chrome behavior is consistent with compiling the event handler when it's first used. I personally think the chrome behavior here is fine; the caveat is <body> and <frameset>, which need to put the event handler on a different object...
Yeah basically I should move the compilation logic to the event handler processing algorithm, similar to how the error handling is there now.
Checked in as WHATWG revision r8303. Check-in comment: Move the event handler content attribute compiling logic to later in the pipeline, for better consistency with Firefox/Safari (and other browsers, though to a lesser extent). http://html5.org/tools/web-apps-tracker?from=8302&to=8303
As usual, let me know if this new text isn't perfect! Please reopen the bug if you add a comment, so that I see it. Thanks!