|
The global object in browsers
Right now ES3 assumes that there is a single global object, which is used
at the top of the scope chain and that is returned for "this" in the
global scope.
It is possible to show that this is now what some browsers do:
var x = 1;
function f() { return x; }
var global = this;
function g() { return global.x; }
// some other page's script takes references to f and g
// browser navigates to a new page
var x = 2;
Now, if the other page's script calls f() and g(), it will get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually a
WindowProxy object, which forwards everything to the "current" Window
object. However, doing this has required that I require browsers to
violate the requirement that the ES3 spec has, namely that "this" and the
object at the top of the scope chain are both the global object, because
in this model an invariant is that script cannot access the actual global
object directly, only the proxy. The HTML5 spec says:
If the script's global object is a Window object, then in JavaScript,
the this keyword in the global scope must, contrary to the ECMAScript
specification, return the Window object's WindowProxy object.
If it would be possible for the ECMAScript specification to have a hook
that allowed me to require this without violating the spec, that would be
great.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson < ian@...> wrote:
> For HTML5, this behaviour has been defined in more detail. The global
> object is a Window object. This object is per-Document. The object
> returned by the "window" attribute on that global object is actually a
> WindowProxy object, which forwards everything to the "current" Window
> object. However, doing this has required that I require browsers to
> violate the requirement that the ES3 spec has, namely that "this" and the
> object at the top of the scope chain are both the global object, because
> in this model an invariant is that script cannot access the actual global
> object directly, only the proxy. The HTML5 spec says:
>
> If the script's global object is a Window object, then in JavaScript,
> the this keyword in the global scope must, contrary to the ECMAScript
> specification, return the Window object's WindowProxy object.
>
> If it would be possible for the ECMAScript specification to have a hook
> that allowed me to require this without violating the spec, that would be
> great.
I don't understand. If the object you're calling Window is
inaccessible from ES code, and if the object you're calling
WindowProxy forwards everything to your Window, why not just relabel
Window -> InternalWindow, WindowProxy -> Window? And in any case, why
not just provide your WindowProxy as the global object to ES code? Why
does ES need to be aware of your Window at all?
The deeper problem here is that ES specs to date -- including the
draft ES3.1 spec -- have not yet admitted the existence of multiple
global objects. We all know we need to, but it is *way* too late to
consider such a change for ES3.1. For ES-Harmony, I think we all agree
we will take this step. Also, the draft module proposal at
< http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v>, proposed by Ihab
Awad and Kris Kowal for ES-Harmony, relies on the introduction of a
"hermetic eval" which omits the global object from the bottom of the
scope chain.
--
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <ian@...> wrote:
Now, if the other page's script calls f() and g(), it will get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually a
WindowProxy object, which forwards everything to the "current" Window
object. What do you mean by "current"? Are you proposing to legitimize the dynamic scoping behavior demonstrated by your example? If all major browsers agree on this bizarre behavior, we will indeed be stuck. But if some existing browsers use lexical capture (i.e., return 1 in both cases), then ES-Harmony should feel free to specify that. What do each of the major browsers do?
-- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, 17 Feb 2009, Mark S. Miller wrote:
>
> I don't understand. If the object you're calling Window is inaccessible
> from ES code, and if the object you're calling WindowProxy forwards
> everything to your Window, why not just relabel Window ->
> InternalWindow, WindowProxy -> Window?
I don't really mind what the objects are called, the point is just that
the object at the top of the scope chain is not the same as the object
returned by "this" (or "window" on the global object).
> And in any case, why not just provide your WindowProxy as the global
> object to ES code? Why does ES need to be aware of your Window at all?
When a browsing context navigates from page A to page B, the object at the
top of the scope chain in code from page A and the oject at the top of the
scope chain in code from page B are not the same object, but the object
returned by the global-scope "this" in scripts from A and B are the same
object (===).
> The deeper problem here is that ES specs to date -- including the draft
> ES3.1 spec -- have not yet admitted the existence of multiple global
> objects. We all know we need to, but it is *way* too late to consider
> such a change for ES3.1.
Ok. This unfortunately leaves us in the status quo position where HTML5
has to require something that violates the ES specs.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, 17 Feb 2009, Mark Miller wrote:
> On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson < ian@...> wrote:
> >
> > Now, if the other page's script calls f() and g(), it will get
> > different results (2 and 1 respectively, if I didn't screw up the
> > example code).
> >
> > For HTML5, this behaviour has been defined in more detail. The global
> > object is a Window object. This object is per-Document. The object
> > returned by the "window" attribute on that global object is actually a
> > WindowProxy object, which forwards everything to the "current" Window
> > object.
>
> What do you mean by "current"? Are you proposing to legitimize the
> dynamic scoping behavior demonstrated by your example?
I'm not really trying to "legitimize" anything so much as accurately
describe the status quo so that new browsers can be written without having
to reverse engineer other browsers.
> If all major browsers agree on this bizarre behavior, we will indeed be
> stuck. But if some existing browsers use lexical capture (i.e., return 1
> in both cases), then ES-Harmony should feel free to specify that. What
> do each of the major browsers do?
My understanding (assuming I got the code right) is that Webkit and Gecko
return different values, and Trident returns 2 for the g() and throws an
exception for f().
Here are some demos. 001 is a control test. If it says "false", you have a
violation of ES, and are likely incompatible with legacy content. If it
says "true", then test 002. If 002 says "false", then ES is being violated
in some way. If 002 doesn't say anything, then code is being blocked when
the global object doesn't match the current document; Mozilla, Apple, and
Opera have all told me not to do that for performance reasons. If it says
false, then test 005 -- if that says true before and false after, then the
browser is probably incompatible with legacy content.
http://damowmow.com/playground/demos/global-object/001.html http://damowmow.com/playground/demos/global-object/002.html http://damowmow.com/playground/demos/global-object/005.html--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Feb 17, 2009, at 2:48 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <ian@...> wrote:
Now, if the other page's script calls f() and g(), it will get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually a
WindowProxy object, which forwards everything to the "current" Window
object.
What do you mean by "current"? Are you proposing to legitimize the dynamic scoping behavior demonstrated by your example?
What Ian showed is not dynamic scoping.
var global = this;
function g() { return global.x; }
The issue is what global.x means after the current page (the one containing the script including these two lines) has been unloaded and a new page loaded (while some other window keeps a reference to g).
If all major browsers agree on this bizarre behavior, we will indeed be stuck. But if some existing browsers use lexical capture (i.e., return 1 in both cases), then ES-Harmony should feel free to specify that. What do each of the major browsers do?
What the proxy forwards to, the current inner window or the one associated with function g (associated how?) when the expression global.x is evaluated, is the *current* inner window for the outer (persistent, === identity) proxy denoted by global in the example.
The identity of the inner window, the one at the tail (top is confusing, which way is up?) of the scope chain in ECMA-262 terms, must not leak or it could be used to subvert access checks done by the proxy.
/be
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Feb 17, 2009, at 3:09 PM, Brendan Eich wrote: On Feb 17, 2009, at 2:48 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <ian@...> wrote:
Now, if the other page's script calls f() and g(), it will get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually a
WindowProxy object, which forwards everything to the "current" Window
object.
What do you mean by "current"? Are you proposing to legitimize the dynamic scoping behavior demonstrated by your example?
What Ian showed is not dynamic scoping.
var global = this;
function g() { return global.x; }
The issue is what global.x means after the current page (the one containing the script including these two lines) has been unloaded and a new page loaded (while some other window keeps a reference to g).
The call to g comes from another window, and it would be dynamic scoping if that window were the global object for the activation of g. It's not. The other window is nowhere on the scope chain. The only issue is whether the proxy forwards to the inner in which g was bound, or the current inner.
Finding the inner in which g was bound from the proxy is not feasible in general. But we could find g's statically linked scope parent ([[Scope]] in ES3), which would be the inner in which g was defined. I raised this idea on IRC recently, and Hixie replied that the proxy (denoted by global) might have no relation to g's [[Scope]].
But that could in theory be handled, I think, by comparing the proxy to which global was bound to the proxy for g's [[Scope]] (inners keep track fo their outer, that is easy; the reverse is 1:N and not easy). If the same proxy is associated with g's [[Scope]] as is the base of the reference being evaluated in g, then use g's [[Scope]]. Else use the current inner global for the proxy.
This could be done, but it would add a kind of alias checking to all property accesses. And it's not what any browser does. So it's probably right out, but I wanted to raise it in detail.
/be _______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 2:36 PM, Mark S. Miller < erights@...> wrote:
> On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson < ian@...> wrote:
> The deeper problem here is that ES specs to date -- including the
> draft ES3.1 spec -- have not yet admitted the existence of multiple
> global objects. We all know we need to, but it is *way* too late to
> consider such a change for ES3.1. For ES-Harmony, I think we all agree
> we will take this step. Also, the draft module proposal at
> < http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v>, proposed by Ihab
> Awad and Kris Kowal for ES-Harmony, relies on the introduction of a
> "hermetic eval" which omits the global object from the bottom of the
> scope chain.
That document is not completely readable (at least in Firefox).
I see the first heading: "roduction". All subsequent headings appear truncted.
h1 {
margin-left:-0.5in;
}
Garrett
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Feb 17, 2009, at 2:02 PM, Ian Hickson wrote:
>
> Right now ES3 assumes that there is a single global object, which is
> used
> at the top of the scope chain and that is returned for "this" in the
> global scope.
>
> It is possible to show that this is now what some browsers do:
>
> var x = 1;
> function f() { return x; }
> var global = this;
> function g() { return global.x; }
>
> // some other page's script takes references to f and g
> // browser navigates to a new page
>
> var x = 2;
>
> Now, if the other page's script calls f() and g(), it will get
> different
> results (2 and 1 respectively, if I didn't screw up the example code).
Actually it's the other way around - f() will return 1 and g() will
return 2. (I think this might have been the reason Mark thought this
example showed dynamic scoping; scope is purely lexical and reflects
original global bindings, but a persistent handle to the global object
reflects the new global object bought in by navigation.)
Regards,
Maciej
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 3:35 PM, Garrett Smith < dhtmlkitchen@...> wrote:
> That document is not completely readable (at least in Firefox).
> I see the first heading: "roduction". All subsequent headings appear truncted.
Rats.
Ok, so it works fine in Safari, and some previous version of it *used*
to work in FF.
Sorry about that folks.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 3:02 PM, Ian Hickson <ian@...> wrote: OP = Opera 9.62 IE = IE 6.0.2900
T = true F = false B = apparently blocked, since nothing happened (view in a fixed width font) test 1 test 2 before after test 5 before after
FF T T B T B
WK T T F T T
CR T T T T B
OP T T T T F
IE T T B F B
Since cross-browser legacy content must work across this range of behaviors, it seems there is not any one legacy behavior to codify. Nice tests!
-- Cheers, --MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, 17 Feb 2009, Mark Miller wrote:
>
> Since cross-browser legacy content must work across this range of
> behaviors, it seems there is not any one legacy behavior to codify.
Indeed, I noted this earlier. The behavior HTML5 codifies is the behavior
that the majority of browser vendors have asked me to codify.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
RE: The global object in browsers
Some parts of this message have been removed.
Learn more about Nabble's security policy.
Perhaps this would be a good initial W3C HTML WG/ECMA TC-39 joint
work item if we can expeditiously get past the bureaucratic hurdles. The
fact that there isn’t an existing consensus behavior among the major browsers
would seem to present an opportunity to step back a bit and take a new look
at the problem.
My sense, is that there are issues that go deeper here simply the
binding of the ECMAScript global object to a browser Window object. It’s
really about providing a clear definition of the execution environments for
scripts (and potentially other code) within browsers and how such execution
environments are associated with browser abstractions such as windows, pages,
frames, etc. In particular, what are the life times of such execution
environments and when are direct object references required/permitted/forbidden
to be shared between them. Also when are proxy references required/permitted/forbidden
and what are the characteristics of such proxies.
I don’t think we should wait to address these issues
as part of the larger ES-Harmony effort As I’ve previously mentioned I
think from an ES perspective it could be initially addressed in an ECMA Tech
Report that describes how the single ES global environment should map into the
browser execution context. I think the most important point is that these
issues should be addressed from a holistic browser perspective rather than just
from a ES or HTML perspective.
Allen
From:
es-discuss-bounces@... [mailto:es-discuss-bounces@...] On
Behalf Of Brendan Eich
Sent: Tuesday, February 17, 2009 3:17 PM
To: Mark Miller; Ian Hickson
Cc: es-discuss Steen
Subject: Re: The global object in browsers
On Feb 17, 2009, at 3:09 PM, Brendan Eich wrote:
On Feb 17, 2009, at 2:48 PM, Mark Miller wrote:
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <ian@...> wrote:
Now, if the other page's script calls f() and g(), it will
get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually
a
WindowProxy object, which forwards everything to the "current" Window
object.
What do you mean by "current"? Are you proposing to legitimize the
dynamic scoping behavior demonstrated by your example?
What Ian showed is not dynamic scoping.
var
global = this;
function
g() { return global.x; }
The issue is what global.x means after the current page (the
one containing the script including these two lines) has been unloaded and a
new page loaded (while some other window keeps a reference to g).
The call to g comes from another window, and it would be
dynamic scoping if that window were the global object for the activation of g.
It's not. The other window is nowhere on the scope chain. The only issue is
whether the proxy forwards to the inner in which g was bound, or the current
inner.
Finding the inner in which g was bound from the proxy is not
feasible in general. But we could find g's statically linked scope parent
([[Scope]] in ES3), which would be the inner in which g was defined. I raised
this idea on IRC recently, and Hixie replied that the proxy (denoted by global)
might have no relation to g's [[Scope]].
But that could in theory be handled, I think, by comparing
the proxy to which global was bound to the proxy for g's [[Scope]] (inners keep
track fo their outer, that is easy; the reverse is 1:N and not easy). If the
same proxy is associated with g's [[Scope]] as is the base of the reference
being evaluated in g, then use g's [[Scope]]. Else use the current inner global
for the proxy.
This could be done, but it would add a kind of alias
checking to all property accesses. And it's not what any browser does. So it's
probably right out, but I wanted to raise it in detail.
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson <ian@...> wrote:
Indeed, I noted this earlier. The behavior HTML5 codifies is the behavior
that the majority of browser vendors have asked me to codify.
Majority, huh? Which vendors? How does the behavior they ask for correlate with what their browsers do? At ECMAScript, the committee has representatives from the main browsers. ECMA works on consensus, not majority, so we get to codify only what all the players agree on. This discipline has repeatedly saved us from standardizing something unnecessarily complex. Cross-browser legacy is generally assumed to be constrained only by what the main browsers agree on (though there are exceptions), giving us some room to clean up areas where existing browser behaviors differ.
-- Cheers, --MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, 17 Feb 2009, Mark Miller wrote:
> On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson < ian@...> wrote:
> >
> > Indeed, I noted this earlier. The behavior HTML5 codifies is the
> > behavior that the majority of browser vendors have asked me to codify.
>
> Majority, huh? Which vendors? How does the behavior they ask for
> correlate with what their browsers do?
Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE does,
namely throw an exception when running code whose global object doesn't
match the current Window object, but Opera, Apple, and Mozilla rejected
this on the grounds that it could not be implemented in a high-performance
manner. They requested that the spec be changed to match what Mozilla and
Safari do. What Opera does is known to be incompatible with deployed
content (they expose Window objects that aren't === to each other).
The browsers all do slightly different things. The HTML5 spec right now is
a mix of what Gecko and Webkit do.
HTH,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 3:35 PM, Garrett Smith < dhtmlkitchen@...> wrote: That document is not completely readable (at least in Firefox).
I see the first heading: "roduction". All subsequent headings appear truncted.
Rats. Ok, so it works fine in Safari, and some previous version of it *used* to work in FF.
My CSS guru says:
"It's equally broken (text off the left edge) for me in Firefox 3.0
and 1.5 as it is on trunk. The page asks for a negative half an
inch of margin, and that's what it gets.
There is a rule that gives body a half-inch margin-left to
compensate (line 283), but that's overriden by a later rule (line
328) at the very beginning of the next style element."
/be
Sorry about that folks. Ihab -- Ihab A.B. Awad, Palo Alto, CA _______________________________________________ Es-discuss mailing list Es-discuss@...https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
Brendan & folks,
On Tue, Feb 17, 2009 at 5:35 PM, Brendan Eich < brendan@...> wrote:
> My CSS guru says:
Thanks for looking at it. :) It turns out I was looking at the Google
docs editor view, not the published web page view. The latter is
indeed broken as you describe (for all browsers), and happens to be
the view that all y'all are looking at.
I'll fix asap then ping the group. And I agree with Mark that we
should move this to the ES Wiki.
Ihab
--
Ihab A.B. Awad, Palo Alto, CA
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Tue, Feb 17, 2009 at 5:24 PM, Ian Hickson <ian@...> wrote:
Opera, Apple, and Mozilla. The HTML5 spec originally specced what IE does,
namely throw an exception when running code whose global object doesn't
match the current Window object, but Opera, Apple, and Mozilla rejected
this on the grounds that it could not be implemented in a high-performance
manner. They requested that the spec be changed to match what Mozilla and
Safari do. What Opera does is known to be incompatible with deployed
content (they expose Window objects that aren't === to each other).
The browsers all do slightly different things. The HTML5 spec right now is
a mix of what Gecko and Webkit do.
Now that I think I understand "current" and how weak the legacy constraints are, why not simply spec that your WindowProxy is the object to treated as the ECMAScript global object? The consequence would be that both f() and g() in your original example would return 2.
-- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
On Feb 17, 2009, at 6:31 PM, Mark Miller wrote:
> Now that I think I understand "current" and how weak the legacy
> constraints are, why not simply spec that your WindowProxy is the
> object to treated as the ECMAScript global object? The consequence
> would be that both f() and g() in your original example would return
> 2.
That either opens a huge security hole, or imposes costly runtime
checks on all lexical references to global variables.
/be
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
|
Re: The global object in browsers
+1 On Tue, Feb 17, 2009 at 5:10 PM, Allen Wirfs-Brock <Allen.Wirfs-Brock@...> wrote:
Perhaps this would be a good initial W3C HTML WG/ECMA TC-39 joint
work item if we can expeditiously get past the bureaucratic hurdles. The
fact that there isn't an existing consensus behavior among the major browsers
would seem to present an opportunity to step back a bit and take a new look
at the problem.
My sense, is that there are issues that go deeper here simply the
binding of the ECMAScript global object to a browser Window object. It's
really about providing a clear definition of the execution environments for
scripts (and potentially other code) within browsers and how such execution
environments are associated with browser abstractions such as windows, pages,
frames, etc. In particular, what are the life times of such execution
environments and when are direct object references required/permitted/forbidden
to be shared between them. Also when are proxy references required/permitted/forbidden
and what are the characteristics of such proxies.
I don't think we should wait to address these issues
as part of the larger ES-Harmony effort As I've previously mentioned I
think from an ES perspective it could be initially addressed in an ECMA Tech
Report that describes how the single ES global environment should map into the
browser execution context. I think the most important point is that these
issues should be addressed from a holistic browser perspective rather than just
from a ES or HTML perspective.
Allen
From:
es-discuss-bounces@... [mailto:es-discuss-bounces@...] On
Behalf Of Brendan Eich
Sent: Tuesday, February 17, 2009 3:17 PM
To: Mark Miller; Ian Hickson
Cc: es-discuss Steen
Subject: Re: The global object in browsers
On Feb 17, 2009, at 3:09 PM, Brendan Eich wrote:
On Feb 17, 2009, at 2:48 PM, Mark Miller wrote:
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson <ian@...> wrote:
Now, if the other page's script calls f() and g(), it will
get different
results (2 and 1 respectively, if I didn't screw up the example code).
For HTML5, this behaviour has been defined in more detail. The global
object is a Window object. This object is per-Document. The object
returned by the "window" attribute on that global object is actually
a
WindowProxy object, which forwards everything to the "current" Window
object.
What do you mean by "current"? Are you proposing to legitimize the
dynamic scoping behavior demonstrated by your example?
What Ian showed is not dynamic scoping.
var
global = this;
function
g() { return global.x; }
The issue is what global.x means after the current page (the
one containing the script including these two lines) has been unloaded and a
new page loaded (while some other window keeps a reference to g).
The call to g comes from another window, and it would be
dynamic scoping if that window were the global object for the activation of g.
It's not. The other window is nowhere on the scope chain. The only issue is
whether the proxy forwards to the inner in which g was bound, or the current
inner.
Finding the inner in which g was bound from the proxy is not
feasible in general. But we could find g's statically linked scope parent
([[Scope]] in ES3), which would be the inner in which g was defined. I raised
this idea on IRC recently, and Hixie replied that the proxy (denoted by global)
might have no relation to g's [[Scope]].
But that could in theory be handled, I think, by comparing
the proxy to which global was bound to the proxy for g's [[Scope]] (inners keep
track fo their outer, that is easy; the reverse is 1:N and not easy). If the
same proxy is associated with g's [[Scope]] as is the base of the reference
being evaluated in g, then use g's [[Scope]]. Else use the current inner global
for the proxy.
This could be done, but it would add a kind of alias
checking to all property accesses. And it's not what any browser does. So it's
probably right out, but I wanted to raise it in detail.
-- Text by me above is hereby placed in the public domain Cheers, --MarkM
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss
|
