[webkit-dev] Setting event handlers on the global context

Mon Jul 20 18:49:38 PDT 2009

You might want to ask someone at Mozilla if they'd be willing to
change their behavior to match everyone else.  The whatwg might be a
good forum for that if you're not sure who to contact individually.

Adam

On Mon, Jul 20, 2009 at 6:30 PM, Drew Wilson<atwilson at google.com> wrote:
> Ran a quick test on Opera and IE along these lines:
> <html><body><script> function onload() { alert("onload"); }
> </script></body></html>
> Only firefox displayed the alert dialog when loading this page -
> IE/Opera/WebKit do not. So if this behavior is incorrect, at least we have
> lots of company.
> -atw
>
> On Sun, Jul 19, 2009 at 4:28 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On Jul 19, 2009, at 11:10 AM, Adam Barth wrote:
>>
>>> I think we should do what Firefox does in the window.onload case.  :)
>>>
>>> I'm not familiar with the history through.  Is there some particular
>>> reason we have our current behavior?
>>
>> The current behavior is an accident of implementation, but I think the
>> relevant applicable spec is somewhat ambiguous. A function declaration
>> creates a new var-like binding which shadows the underlying onmessage
>> setter.
>>
>> The relevant spec here is ECMAScript, not HTML5. In ECMA-262, section
>> 10.1.3 is what would apply, I haven't checked the proper reference for the
>> fifth edition draft. Regarding the declaration of a function with the same
>> name as an existing property, it says: "If the variable object already has a
>> property with this name, replace its value and attributes." So a vanilla
>> property should get replaced with a DontDelete property, but in the case of
>> a setter it's not clear whether it should be replaced or shadowed.
>>
>> It would probably be good to match other browsers. I am curious what IE
>> and Opera do here. I would also be curious if ECMAScript 5 is more clear
>> about what to do when a function declaration has the same name as a setter
>> property, since it supports getters and setters in the spec.
>>
>>  his would be slightly, but not insanely tricky to fix. The relevant code
>> is all in BytecodeGenerator::BytecodeGenerator(ProgramNode*
>> programNode....), since this only affects global scope. The change could
>> have far-reaching consequences so we'd have to be on the lookout for Web
>> compatibility regressions if we change this.
>>
>> Regards,
>> Maciej
>>
>>>
>>> Adam
>>>
>>>
>>> On Sun, Jul 19, 2009 at 10:56 AM, Drew Wilson<atwilson at google.com> wrote:
>>>>
>>>> Yes, it happens with window.onload() too (I didn't mean to imply that it
>>>> was
>>>> a worker-only issue).
>>>> This seems like precisely the type of inoperability that the HTML5 spec
>>>> should address, but I figured I should get some input here before
>>>> bringing
>>>> it up there.
>>>> -atw
>>>>
>>>> On Sun, Jul 19, 2009 at 10:31 AM, Adam Barth <abarth at webkit.org> wrote:
>>>>>
>>>>> You should test the same thing with window.onload.  If I recall
>>>>> correctly, you'll see similar inoperability.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On Sun, Jul 19, 2009 at 9:29 AM, Drew Wilson<atwilson at google.com>
>>>>> wrote:
>>>>>>
>>>>>> I was writing a new worker unit test and I noticed that all of our
>>>>>> unit
>>>>>> tests set event handlers in worker global context like so:
>>>>>> onmessage = function(event) { ... do something ... };
>>>>>> I note that Firefox also allows setting event handlers like this:
>>>>>> function onmessage(event) { ... do something ... };
>>>>>> In WebKit, the latter form creates a function at global scope named
>>>>>> "onmessage" but does not set it as an event handler.
>>>>>> I'm trying to figure out what the correct behavior should be - I've
>>>>>> asked
>>>>>> IanH, and his response was that he dimly recalls that both forms
>>>>>> should
>>>>>> be
>>>>>> valid "(through a convoluted argument that I forget right now, but
>>>>>> which
>>>>>> should be examined carefully by whoever implements this, and which
>>>>>> requires
>>>>>> careful examination of at least the ECMAScript spec and maybe also the
>>>>>> WebIDL and HTML5 specs)" - basically, he wasn't entirely certain and
>>>>>> thought
>>>>>> I should check here and with the Mozilla devs to get your opinions.
>>>>>> Anyone familiar enough with the various specs to make a definitive
>>>>>> argument
>>>>>> one way or the other?
>>>>>> -atw
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> webkit-dev mailing list
>>>>>> webkit-dev at lists.webkit.org
>>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>