[whatwg] onerror

[Jonas Sicking]

On 1/17/09, Anne van Kesteren <annevk at opera.com> wrote:
> On Sat, 17 Jan 2009 04:04:19 +0100, Jonas Sicking <jonas at sicking.cc> wrote:
>> Not sure if I should be posting this to the whatwg list or the webapps
>> list, given that the spec is in process of transitioning between the
>> two groups. So I'm posting to both in the hope that this thread won't
>> generate too much related traffic. So please stay on topic :)
>>
>> Currently the webapps spec define that the onerror property should
>> start out as undefined, rather than other onX properties which start
>> out as null. The reason for this is parity with the window object
>> where the onerror property behaves the same.
>>
>> However there is very little parity anyway between the window onerror
>> and the worker onerror. The former isn't a normal event handler but
>> rather a special function that receives 3 arguments and returns a
>> special value to suppress the error. The latter is a normal event
>> handler which receives an error event and suppresses the error by
>> calling .preventDefault() on the event.
>>
>> Further, the fact that onerror is undefined at the start is to prevent
>> breaking existing scripts, of which there are none for workers.
>>
>> So I think it'd be nicer to have parity with other onX properties,
>> than to have parity on this one aspect with window.onerror.
>
> Will you be changing Firefox for the other onX attributes then?
>
> I.e.,
>
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cscript%3E%20w(document.body.onclick)%20%3C%2Fscript%3E
>
> gives "null" in Opera 9.6+ and Internet Explorer 6, but "undefined" in
> Firefox 3.2a1pre.

I'm talking about parity with other onX attributes inside workers.

But I'd be fine with changing onX for other objects if all other
browsers do something else, but thats orthogonal to the issue I
originally brought up in this thread.

/ Jonas