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/complete/webappapis.html Multipage: http://www.whatwg.org/C#event-handler-content-attributes Complete: http://www.whatwg.org/c#event-handler-content-attributes Comment: should allow deferring these steps until the event handler would be invoked (observable with window.onerror) Posted from: 85.227.155.223 by simonp@opera.com User agent: Opera/9.80 (Macintosh; Intel Mac OS X 10.5.8; U; en) Presto/2.9.168 Version/11.51
Why?
Because browsers do that for perf reasons. (Well, Opera does at least.)
Seems like that would allow for variance in behaviour leading to reduce interoperability. The perf win seems minimal; do you have any numbers to support whether it's worth it?
The only variance in behavior would be when window.onerror is invoked in case the attribute contains a compile error. No? I don't have numbers. But I know Opera (we don't have a public build with onerror support yet), Firefox and Chrome all do this. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1216 So possibly you could require that compiling the attribute is delayed until an event is fired.
That would make more sense, yeah. Or at least, deferring firing the onerror. Is this onerror sync with the handler that would have been called?
Yes. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1230
Looks like no: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1236 Seems like Firefox sets it lazily and finds the error the first time it's fetched, whether for execution or because it's being serialised; it then fires onerror (but doesn't throw an exception) and sets it to null. IE fires onerror as soon as the attribute is parsed by the HTML parser, and treats the attribute as being null afterwards. Chrome tries to compile it every time it's accessed, and throws an exception each time (leading to onerror if it's not caught). (Safari and Opera don't seem to support onerror.)
Safari (or really, WebCore JavaScriptCore bindings) parses such inline scripts when they are first needed. They can be re-parsed if the attribute moves to another node. Also, they are re-parsed each time if parsing failed - failure isn't currently cached. So, sounds pretty much like Chrome.
Olli knows better the details of how/when we parse event handlers. I wouldn't be entirely opposed to giving some leeway here as to allow implementations to optimize parsing speed. Clearly multiple browser vendors has run into performance issues with parsing event handlers too eagerly.
In Opera with onerror support the output is: log: before1 log: >undefined log: before2 log: onerror called log: after1 log: >undefined log: after2 log: onerror called log: onerror called
I think the Firefox behaviour is probably the one to spec. It means defining the getter for event handler IDL attributes in more detail. To make the model simpler to explain I'll have the spec compile it straight away, but delay the reporting of the error until the first time it's needed (reading the attribute or handling an event), and then at that point reset it to null.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see bug 14176 Rationale: Concurred with reporter's comments.