14175 2011-09-16 06:52:15 +0000 onerror: Defer firing the onerror from compiling an event handler until it's used 2011-11-10 23:32:06 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#event-handler-content-attributes P3 normal --- 14174 1 contributor ian ap bugs ian jonas mike public-html-admin public-html-wg-issue-tracking w3c zcorpan public-html-bugzilla oldest_to_newest 56882 0 contributor 2011-09-16 06:52:15 +0000 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 58473 1 ian 2011-10-19 23:19:26 +0000 Why? 58518 2 zcorpan 2011-10-20 08:20:21 +0000 Because browsers do that for perf reasons. (Well, Opera does at least.) 58555 3 ian 2011-10-20 20:05:06 +0000 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? 58566 4 zcorpan 2011-10-20 20:18:32 +0000 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. 58858 5 ian 2011-10-25 04:46:39 +0000 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? 58892 6 zcorpan 2011-10-25 07:32:10 +0000 Yes. http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1230 59028 7 ian 2011-10-26 23:54:59 +0000 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.) 59041 8 ap 2011-10-27 04:19:30 +0000 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. 59043 9 jonas 2011-10-27 05:47:18 +0000 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. 59050 10 zcorpan 2011-10-27 08:12:59 +0000 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 59560 11 ian 2011-11-03 16:22:27 +0000 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. 59853 12 ian 2011-11-10 23:32:06 +0000 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.