Re: [webkit-dev] Setting event handlers on the global context
Ran a quick test on Opera and IE along these lines:
htmlbodyscript 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 Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Setting event handlers on the global context
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 Wilsonatwil...@google.com wrote:
Ran a quick test on Opera and IE along these lines:
htmlbodyscript 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 Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Setting event handlers on the global context
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 Wilsonatwil...@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
Re: [webkit-dev] Setting event handlers on the global context
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 Wilsonatwil...@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
Re: [webkit-dev] Setting event handlers on the global context
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?
Adam
On Sun, Jul 19, 2009 at 10:56 AM, Drew Wilsonatwil...@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 Wilsonatwil...@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
Re: [webkit-dev] Setting event handlers on the global context
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 Wilsonatwil...@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 Wilsonatwil...@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
