This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14175 - onerror: Defer firing the onerror from compiling an event handler until it's used
Summary: onerror: Defer firing the onerror from compiling an event handler until it's ...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on: 14174
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-16 06:52 UTC by contributor
Modified: 2011-11-10 23:32 UTC (History)
9 users (show)

See Also:


Attachments

Description contributor 2011-09-16 06:52:15 UTC
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
Comment 1 Ian 'Hixie' Hickson 2011-10-19 23:19:26 UTC
Why?
Comment 2 Simon Pieters 2011-10-20 08:20:21 UTC
Because browsers do that for perf reasons. (Well, Opera does at least.)
Comment 3 Ian 'Hixie' Hickson 2011-10-20 20:05:06 UTC
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?
Comment 4 Simon Pieters 2011-10-20 20:18:32 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2011-10-25 04:46:39 UTC
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?
Comment 7 Ian 'Hixie' Hickson 2011-10-26 23:54:59 UTC
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.)
Comment 8 Alexey Proskuryakov 2011-10-27 04:19:30 UTC
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.
Comment 9 Jonas Sicking (Not reading bugmail) 2011-10-27 05:47:18 UTC
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.
Comment 10 Simon Pieters 2011-10-27 08:12:59 UTC
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
Comment 11 Ian 'Hixie' Hickson 2011-11-03 16:22:27 UTC
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.
Comment 12 Ian 'Hixie' Hickson 2011-11-10 23:32:06 UTC
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.