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 <m...@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<atwil...@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 <aba...@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<atwil...@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@lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>>
>>>>>
>>>>>
>>>
>>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
