Interesting spec ambiguity: cross-frame "this"
Well, I don't think ES5 has anything to say about this issue because as you know it doesn't include the concept of multiple global contexts. I actually don't think it is valid to try to interpret the ES5 spec. to try to find guidance on this issue as anything thing you find that may seem relevant to this situation is probably coincidental.
That said, I'll violate my own advice and point out some possibly relevant things in the ES5 spec.
First, the global object that is in scope to a function is captured when a function instantiated as part of the state captured via the [[Scope]] internal property. So, that means in canary.html the global object used to resolve 'window' and 'parent' within the canary function should be the frame's global object. The value passed as the this value to the call to canary is determined by 10.4.3 (Entering Function Code) but is only identified as the "global object". There is no hint in 10.4.3 about which global object to use. However, 10.4.3 is referenced from the specification of the [[Call]] internal method (13.2.1). Both [[Call]] and [[Scope]] are part of the internals of a function object so you would expect them to have a consistent view of the "global object". Hence, when [[Call]] refers to 10.4.3 I would assume that it should be done using the same "global object" that [[Scope]] captured.
Thus, the expected answer should be "true,false,[object ???]"
But, like I said above, this is not necessarily intentional.
Does the HTML spec. explicitly covers this case?
On Mon, Apr 18, 2011 at 5:17 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
Well, I don't think ES5 has anything to say about this issue because as you know it doesn't include the concept of multiple global contexts. I actually don't think it is valid to try to interpret the ES5 spec. to try to find guidance on this issue as anything thing you find that may seem relevant to this situation is probably coincidental.
That said, I'll violate my own advice and point out some possibly relevant things in the ES5 spec.
First, the global object that is in scope to a function is captured when a function instantiated as part of the state captured via the [[Scope]] internal property. So, that means in canary.html the global object used to resolve 'window' and 'parent' within the canary function should be the frame's global object. The value passed as the this value to the call to canary is determined by 10.4.3 (Entering Function Code) but is only identified as the "global object". There is no hint in 10.4.3 about which global object to use. However, 10.4.3 is referenced from the specification of the [[Call]] internal method (13.2.1). Both [[Call]] and [[Scope]] are part of the internals of a function object so you would expect them to have a consistent view of the "global object". Hence, when [[Call]] refers to 10.4.3 I would assume that it should be done using the same "global object" that [[Scope]] captured.
Thus, the expected answer should be "true,false,[object ???]"
Good. I went through a similarly indirect analysis, reading between the lines, and arrived at the same conclusion for canary.html and canary-orig.html. As for canary-direct.html, I think both FF4.0's apparent behavior (it is a direct eval) and apparent Nightly6.0beta's behavior (it is an indirect eval) are justifiable, but I prefer the latter.
But, like I said above, this is not necessarily intentional.
Does the HTML spec. explicitly covers this case?
From discussion with Ian, it seems the answer is no. Ian asked if it would
be useful for HTML to specify this in the interim, until ES-next get around to specifying the semantics of multiple globals. I said yes, since we need to converge present browser behavior sooner.
On Apr 18, 2011, at 2:28 PM, Mark S. Miller wrote:
Good. I went through a similarly indirect analysis, reading between the lines, and arrived at the same conclusion for canary.html and canary-orig.html. As for canary-direct.html, I think both FF4.0's apparent behavior (it is a direct eval) and apparent Nightly6.0beta's behavior (it is an indirect eval) are justifiable, but I prefer the latter.
I can tell you the intent of the language in15.1.2.1.1. IThe intent was that the resolved value of "eval" is the SameValue as the original value of the global named 'eval' defined in 15.1.2.1. By the same logic that I used in my previous response that should be the original eval value of the global environment that is in scope for the code containing the possibly direct eval. In other words, the eval call in canary-direct is not a direct eval.
As an indirect eval, the global object is uses should be the global object captured the eval function which should be the frame's eval. That appears to be the Nightly6.0 result.
On Mon, Apr 18, 2011 at 6:08 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
On Apr 18, 2011, at 2:28 PM, Mark S. Miller wrote:
Good. I went through a similarly indirect analysis, reading between the lines, and arrived at the same conclusion for canary.html and canary-orig.html. As for canary-direct.html, I think both FF4.0's apparent behavior (it is a direct eval) and apparent Nightly6.0beta's behavior (it is an indirect eval) are justifiable, but I prefer the latter.
I can tell you the intent of the language in15.1.2.1.1. IThe intent was that the resolved value of "eval" is the SameValue as the original value of the global named 'eval' defined in 15.1.2.1. By the same logic that I used in my previous response that should be the original eval value of the global environment that is in scope for the code containing the possibly direct eval. In other words, the eval call in canary-direct is not a direct eval.
As an indirect eval, the global object is uses should be the global object captured the eval function which should be the frame's eval. That appears to be the Nightly6.0 result.
Excellent. +1.
See code.google.com/p/chromium/issues/detail?id=79612.
See <http://code.google.com/p/chromium/issues/detail?id=79612>. -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110418/7afb3e23/attachment.html>