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
