Re: The global object in browsers
On Mon, 6 Jul 2009, Brendan Eich wrote: If we must have split windows in all top browser implementations (so the argument goes), then we must have them in a spec. If not ECMA-262, then HTML5. If split windows, then what |this| binds to (outer or inner) needs to be spec'ed. So here we are. Comments? Your e-mail is in line with my understanding. In HTML5, the inner window is the Window object and the outer window is the WindowProxy object. With one minor exception to do with about:blank, there's a 1:1 mapping from Document to Window, and a 1:1 mapping from WindowProxy to browsing context. Each browsing context can have many Window/Document pairs. For what it's worth, right now HTML5 says: If the script's global object is a Window object, then in JavaScript, the |this| keyword in the global scope must return the Window object's WindowProxy object. This is a willful violation of the JavaScript specification current at the time of writing (ECMAScript edition 3). The JavaScript specification requires that the this keyword in the global scope return the global object, but this is not compatible with the security design prevalent in implementations as specified herein. [ECMA262] I'd love to be able to include this requirement without it being a violation of another spec. 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
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 [...]
Suppose that a browser allocates all JavaScript objects associated with
some unit of content [*], in an arena. When the browser navigates away from
that unit of content, the arena is deallocated; to preserve memory safety,
all references into it from objects that are still live will throw an
exception.
This behaviour has clear advantages for robustness against denial of service
from JavaScript code, both deliberate and inadvertent -- which is a definite
weak spot of current browsers, and a very common cause of complaint from
knowledgeable users. Is there any reason why it should be considered
nonconformant?
[*] Possibly a frame, or consecutive sequence of navigated frames with
the same origin. What is the minimum granularity for a unit of content
for this would be compatible with the current web?
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
Maciej Stachowiak wrote: On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote: Ian Hickson wrote: 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). MarkM's point is that *given that the object called Window is inaccessible*, there's no way to observe that the object called Window is at the top of the scope chain. An implementation could reflect all property changes in that object to the object called WindowProxy, by some unspecified mechanism (which is allowed since they are both host objects). It is possible to observe that the object at the top of the scope chain behaves differently than the global this value (it may have an entirely different set of properties), so this arguably violates the ECMAScript requirement that these be the same object, even though object identity cannot be observed directly. Ian Hickson's description of the two objects was: # 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. I don't understand how the WindowProxy forwarding everything to the Window object is is consistent with the two objects having entirely different set[s] of properties. In any case, note that host objects can have arbitrary [[Put]] and [[Get]] internal methods, so it is possible for them to implement almost any conceivable behaviour that HTML5 could specify (given that ES code cannot obtain a reference to the object at the top of the scope chain, and so === cannot be used on it). That was my point above. In other words, ES3 has such a weak specification for host objects that literally any behaviour for property accesses on them is conformant. [...] I'm confused by the motivation of the change in HTML5. It seems like it is imposing most of the complexity that would be needed to fix some of the security problems associated with the global object, *without* actually fixing those problems. The HTML5 spec behavior does fix important security problems, relative to what older browsers used to do. Older behavior was to reuse the same global object across navigations, but simply clear the variables. This creates easily exploitable XSS vulnerabilities. That's obviously broken, yes. When you say older behaviour, what versions of the main browsers are you talking about, approximately? Note though that HTML5 is following the implementations here rather than leading. Also, it is a breach of standards development etiquette for the HTML WG to make a a change (even in a draft) that it believes to be incompatible with the ECMAScript spec, without consulting TC39. It should not have been left to you in the role of an implementor to point out the incompatibility. I think Ian discharged his obligation by notifying TC39 of the issue and starting this discussion. At this point, the important thing is to come up with a solution we can agree on. I was confused partly by the fact that Ian said: # For HTML5, this behaviour has been defined in more detail. [...] # The HTML5 spec says: [...] as opposed to something like: It has been proposed for the next draft of HTML5 to define this in more detail. [...] The proposal is: [...] -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 21, 2009, at 1:49 AM, David-Sarah Hopwood wrote:
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 [...]
Suppose that a browser allocates all JavaScript objects associated
with
some unit of content [*], in an arena. When the browser navigates
away from
that unit of content, the arena is deallocated; to preserve memory
safety,
all references into it from objects that are still live will throw an
exception.
This behaviour has clear advantages for robustness against denial of
service
from JavaScript code, both deliberate and inadvertent -- which is a
definite
weak spot of current browsers, and a very common cause of complaint
from
knowledgeable users. Is there any reason why it should be considered
nonconformant?
This behavior has two problems:
1) Likely incompatible with the Web. Though Web sites apparently don't
depend on ability to call older functions, they certainly do use
objects originally allocated in other global objects and quite likely
after the originating context has navigated. It's hard to quantify
this since no browser has ever tried.
2) Makes implementation of back/forward caching (as present in Safari
and Firefox) impractical; b/f cache fully restores a context that you
navigated away from, including the live JavaScript object graph.
3) Has the same performance problems as the model of checking at
function call boundaries, since at calls you'd have to check if your
function has turned into a magical exception object. You are on record
as not believing these, I will leave it to others to judge for
themselves whether your I'm quite sure argument outweighs the
experience of those who actually tried it and measured the results.
4) If the arena is truly deallocated rather than filled with magic
exception objects, many additional checks must be inserted each time a
value reference is used in almost any way, to check whether it is a
reference into a deallocated arena. This would likely be a significant
perf hit as well.
5) As far as I can tell, this violates the ECMA spec even more than
the current HTML5 solution; the ECMA spec does not include the concept
of reachable values turning into exception-throwing zombies.
6) It has poor properties for reliability and integrity of ECMAScript
programs. Your code may have a perfectly good string or object stored
away. But depending on where it originally came from, that reference
can suddenly go bad.
[*] Possibly a frame, or consecutive sequence of navigated frames with
the same origin. What is the minimum granularity for a unit of
content
for this would be compatible with the current web?
A unit of content of one page is almost certainly incompatible with
the Web. A series of frames with the same origin would likely also be
incompatible, since it is quite likely an initially empty frame may be
used as a helper before navigating elsewhere. Not only that, but it
would be bizarrely arbitrary if your object references from another
frame go dead or not depending on whether the frame navigates to same-
origin or non-same-origin content. Either way, problems 2-5 remain.
I don't think we need to try to redesign how browsers do navigation
here. I don't see any justification provided for preferring your
approach to what HTML5 specifies.
Regards,
Maciej
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 20, 2009, at 4:13 PM, David-Sarah Hopwood wrote: Ian Hickson's description of the two objects was: # 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. I don't understand how the WindowProxy forwarding everything to the Window object is is consistent with the two objects having entirely different set[s] of properties. Let's say you have a top-level browsing context currently displaying a document loaded from http://example.com/. This document has a subframe displaying http://example.com/frame1.html. Inside the frame1 browsing context, a variable X containing the value frame1 is defined. A function F is also defined which accesses variable X via scope, and via a retained reference to the global object. The top- level context gets a reference to function F. Now the nested browsing context is navigated to http://example.com/frame2.html. This establishes a new Window, which the WindowProxy now points to. Let's say that inside this new global object, another variable X is defined which has the value frame2. Now when F is called from the outer context, it will consistently see the value frame1 when looking up variable X via scope, since the scope chain contains its Window. But when accessing X via a saved reference to the global object (for example via window.X) it will consistently see frame2, since this is a WindowProxy reference that forwards to the now-current Window. Taking this further, the old Window and new Window (visible via the WindowProxy) could have totally different sets of properties. Note that to observe the difference requires at least two frames, at least one of which is navigated, for a total of 3 different global objects. Does that help? In any case, note that host objects can have arbitrary [[Put]] and [[Get]] internal methods, so it is possible for them to implement almost any conceivable behaviour that HTML5 could specify (given that ES code cannot obtain a reference to the object at the top of the scope chain, and so === cannot be used on it). That was my point above. In other words, ES3 has such a weak specification for host objects that literally any behaviour for property accesses on them is conformant. If we take this approach, then the requirement that the top level scope entry and the global object are the same object would be meaningless. I'm willing to buy the argument that it is in fact meaningless and imposes no real requirement, but perhaps others will disagree. Since there is no way to observe identity directly, one could always make the claim that two different objects are in fact one object with strange property access behavior. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
Maciej Stachowiak wrote: On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote: Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. In modern JITing implementations, adding (at least) two memory reads and a conditional branch to every function call would be a significant performance hit. It is not every function call; only function calls that are not known to be same-context (in a particular copy of the generated code). The majority (by call frequency) of function calls can be inferred to be same-context by analyses that a high-performance implementation should be doing already. Furthermore, the context check can be hoisted to the first point in a function body where the target function is known (so calls to the same function in a loop will require only one check). There are most sophisticated optimizations that could be done, but they're probably not needed. In JavaScriptCore for instance, the hot path at the machine code level is optimized down to essentially just one memory read, one conditional branch, and a jump to the callee's code (also some memory writes but those don't stall the pipeline so they don't matter as much). The next hottest path has three branches and a few extra memory reads. Adding an extra branch (and associated memory reads) to that would be a big hit. We know because we have measured the benefit of reducing the number of branches. It makes a huge difference in call-heavy code. In general, I would advise against making performance claims in absolute terms (like clearly false) without testing or studying the relevant implementation internals. I see no point in equivocating on points that I am quite sure about, having studied similar issues in implementations of other languages. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. -- David-Sarah Hopwood ⚥ ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Thu, 19 Feb 2009, David-Sarah Hopwood wrote: MarkM's point is that *given that the object called Window is inaccessible*, there's no way to observe that the object called Window is at the top of the scope chain. Granted, but there _is_ a way to observe that the object at the top of the scope chain isn't the same as the object returned by |this|, which is what I am concerned about. 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, It's not possible to observe that, since by hypothesis neither object is accessible to ECMAScript code. The object itself isn't, but properties on the object are. If two scripts check to see what value a variable x on their global object is, and they get different results, in the absence of any code changing anything, one can tell that they are different global objects. I'm confused by the motivation of the change in HTML5. It seems like it is imposing most of the complexity that would be needed to fix some of the security problems associated with the global object, *without* actually fixing those problems. What security problems does in not fix? The motivation is to make HTML5 describe what browsers do. Also, it is a breach of standards development etiquette for the HTML WG to make a a change (even in a draft) that it believes to be incompatible with the ECMAScript spec, without consulting TC39. It should not have been left to you in the role of an implementor to point out the incompatibility. I am the editor of the HTML5 spec. My e-mail was an attempt at the consultation to which you refer. 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Thu, 19 Feb 2009, David-Sarah Hopwood wrote: Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. To be honest it doesn't really matter to me what the reason is -- if three browser vendors tell me they're not implementing the spec, I change the spec. My goal is to have a specification that browser vendors implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
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 i...@hixie.ch 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).
Whatever is specified should not prevent an implementation from throwing
an exception (ReferenceError would be most appropriate) in this case.
I disagree, strongly, with the position attributed by Ian Hickson to
Mozilla, Apple, and Opera that this option should be excluded on
performance grounds; I think that position has no sound technical
justification.
--
David-Sarah Hopwood ⚥
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
Ian Hickson wrote: On Thu, 19 Feb 2009, David-Sarah Hopwood wrote: Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. To be honest it doesn't really matter to me what the reason is -- if three browser vendors tell me they're not implementing the spec, I change the spec. My goal is to have a specification that browser vendors implement. I think it should matter. The vendors should be asked to give a reason that makes technical sense. That this option could not be implemented in a high-performance manner does not make sense -- which means that it is quite possible that the vendors were asked the wrong question, or had some misunderstanding about how such a specification could be implemented. -- David-Sarah Hopwood ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Thu, 19 Feb 2009, David-Sarah Hopwood wrote: I think it should matter. The vendors should be asked to give a reason that makes technical sense. That this option could not be implemented in a high-performance manner does not make sense -- which means that it is quite possible that the vendors were asked the wrong question, or had some misunderstanding about how such a specification could be implemented. I don't believe there was any misunderstanding, but regardless: if you are able to convince the implementors to implement something other than what is currently specced in HTML5, I'm very happy to change the spec to require that instead. I don't really mind how this works, I just want to make sure the spec is clear on what is required and that the spec matches what actually gets implemented, and ideally I would like it to not contradict the ES specs as it unfortunately does now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 19, 2009, at 1:39 AM, David-Sarah Hopwood wrote: Ian Hickson wrote: On Tue, 17 Feb 2009, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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. That is clearly false. It would be a single pointer comparison when entering a new context. I make no comment here on whether this behaviour would be a good idea on other criteria, just that rejecting it on performance grounds is absurd. In modern JITing implementations, adding (at least) two memory reads and a conditional branch to every function call would be a significant performance hit. In JavaScriptCore for instance, the hot path at the machine code level is optimized down to essentially just one memory read, one conditional branch, and a jump to the callee's code (also some memory writes but those don't stall the pipeline so they don't matter as much). The next hottest path has three branches and a few extra memory reads. Adding an extra branch (and associated memory reads) to that would be a big hit. We know because we have measured the benefit of reducing the number of branches. It makes a huge difference in call-heavy code. In general, I would advise against making performance claims in absolute terms (like clearly false) without testing or studying the relevant implementation internals. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 19, 2009, at 1:20 AM, David-Sarah Hopwood wrote: Ian Hickson wrote: 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). MarkM's point is that *given that the object called Window is inaccessible*, there's no way to observe that the object called Window is at the top of the scope chain. An implementation could reflect all property changes in that object to the object called WindowProxy, by some unspecified mechanism (which is allowed since they are both host objects). It is possible to observe that the object at the top of the scope chain behaves differently than the global this value (it may have an entirely different set of properties), so this arguably violates the ECMAScript requirement that these be the same object, even though object identity cannot be observed directly. However, this can only be observed in the presence of multiple global objects and global object replacement via navigation, which is a situation not adequately covered by the ECMAScript spec at present. One could make the case that because the difference is not observable under a single global object, then the behavior is conforming. I'm confused by the motivation of the change in HTML5. It seems like it is imposing most of the complexity that would be needed to fix some of the security problems associated with the global object, *without* actually fixing those problems. The HTML5 spec behavior does fix important security problems, relative to what older browsers used to do. Older behavior was to reuse the same global object across navigations, but simply clear the variables. This creates easily exploitable XSS vulnerabiliites. Note though that HTML5 is following the implementations here rather than leading. Also, it is a breach of standards development etiquette for the HTML WG to make a a change (even in a draft) that it believes to be incompatible with the ECMAScript spec, without consulting TC39. It should not have been left to you in the role of an implementor to point out the incompatibility. I think Ian discharged his obligation by notifying TC39 of the issue and starting this discussion. At this point, the important thing is to come up with a solution we can agree on. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: The global object in browsers
On Thu, 19 Feb 2009, Allen Wirfs-Brock wrote: Perhaps it would be useful to have a half day (or even full day) session on this general topic at the March F2F. Since Ian is affiliated with an ECMA member he could attend if he chooses and I might get an appropriate IE platform representative to attend. I really don't have an opinion on this topic. I'm happy to spec whatever the browser vendors are willing to implement. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 6:31 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 5:24 PM, Ian Hickson i...@hixie.ch 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. That would either allow access to new variable bindings to functions in old documents from different origins (violating security requirements, my constraint 2, from another email) or would require a security check for every global variable lookup (violating my performance constraint 3). Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 11:18 PM, Mark Miller wrote: You misunderstood me a bit, but no matter. Now that I better understand the constraints -- thanks! -- what I was trying to say is irrelevant. What I mess. I am at a loss to find anything sensible to recommend. I think that's how most of us who have studied the issue feel. The split window solution is in some ways inelegant, but there is no obvious other option that satisfies the performance, compatibility and security requirements. Regards, Maciej ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 11:18 PM, Mark Miller wrote: You misunderstood me a bit, but no matter. Sorry, I couldn't see how to interpret your proposal otherwise. Let me know what I missed if you like. Maciej's right, the object identities practically dictate split windows. I suppose the original DOM level 0 could have made the split explicit, but it was not implemented this way at all back in the day. Different browser implementors solved the security and performance problems in similar ways, to preserve the view of the persistent window container as the one true window object, really a proxy with multiple global objects hidden within it. The ability to use lexical scope (however the syntax turns out) and make the global variables truly lexical bindings in a top-level environment, not properties of some grotty object, is something I look forward to in Harmony: http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: The global object in browsers
On Tue, 17 Feb 2009, 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. This would be fine by me, though it should be noted that the people who will ultimately decide what the answer is here are those who will be implementing it, and there is nobody who falls into that camp who is on the public-h...@w3.org list and is not on the es-discuss list as far as I am aware. So it's not clear that there would be any benefit to the getting past the bureaucratic hurdles. I'm happy to spec into HTML5 whatever the majority of implementations eventually do (i.e. HTML5 will just track reality, whatever that is), I would hope the same applies to 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 18, 2009, at 3:24 PM, Ian Hickson wrote: I'm happy to spec into HTML5 whatever the majority of implementations eventually do (i.e. HTML5 will just track reality, whatever that is), I would hope the same applies to the ES specs. :-) We do try to pave the cowpaths (without giving the biggest herds undue influence, or falling into other such traps -- I get lost driving around Boston, I hear it's cuz they paved the cowpaths back a century or two). You may remember us from such reality-inspired movies as Attack of the /[/]/ Killer RegExps and Don't throw for(i in null) from the Train. :-/ /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson i...@hixie.ch 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson i...@hixie.ch 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@mozilla.org 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@mozilla.org 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 i...@hixie.ch 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@mozilla.org 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 i...@hixie.ch 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@mozilla.org
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 erig...@google.com wrote:
On Tue, Feb 17, 2009 at 2:02 PM, Ian Hickson i...@hixie.ch 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@mozilla.org
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 3:02 PM, Ian Hickson i...@hixie.ch wrote: 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 FF = Firefox 3.0.6 WK = WebKit nightly for Safari Version 3.2.1 (5525.27.1) CR = Chrome 1.0.154.48 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 1test 2 before after test 5 before after FF TT B T B WK TT F T T CR TT T T B OP TT T T F IE TT 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 5:03 PM, Ian Hickson i...@hixie.ch 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@mozilla.org 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 i...@hixie.ch 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 4:03 PM, ihab.a...@gmail.com wrote: On Tue, Feb 17, 2009 at 3:35 PM, Garrett Smith dhtmlkitc...@gmail.com 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 5:24 PM, Ian Hickson i...@hixie.ch 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@mozilla.org 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@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: The global object in browsers
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-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] 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
i...@hixie.chmailto:i...@hixie.ch 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@mozilla.org
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-br...@microsoft.com 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-boun...@mozilla.org [mailto:
es-discuss-boun...@mozilla.org] *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 i...@hixie.ch 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
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
___
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote: 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. If Ian's Window object were provided as the ES global, then we'd have the security problem you're concerned about. But, IIUC, with the WindowProxy we don't. As for performance, wouldn't a shallow binding implementation[1] make switching which page is current be more expensive, but variable access within a page, even after a switch, would have no added expense? [1] The two primary methods of implementing dynamic scoping were known as shallow binding and deep binding. Although current is not dynamic scope, some of the same issues and tradeoffs apply. In a shallow bound implementation. the WindowProxy's properties are direct properties -- not forwarded. On page navigation, these properties are copied into the Window object corresponding to the old page, and the properties on the Window object corresponding to the new page are copied onto the WindowProxy. Another analogy is with the register store in thread control blocks in an OS implementation. One can describe the semantics of computation in a given OS as directly updating the current per-thread register set. But instead of paying the indirection on register access, we'd rather pay the copying overhead on context switch. -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
On Feb 17, 2009, at 8:17 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote: 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. If Ian's Window object were provided as the ES global, then we'd have the security problem you're concerned about. But, IIUC, with the WindowProxy we don't. That seems half-right. The ES global at the end of scope chains is the inner Window object. The perisistent-identity global that you get your hands on via the DOM, |this|, |self|, and |window| is the outer or WindowProxy object. Which one did you mean by the ES global in the first sentence cited above? As for performance, wouldn't a shallow binding implementation[1] make switching which page is current be more expensive, but variable access within a page, even after a switch, would have no added expense? [1] The two primary methods of implementing dynamic scoping were known as shallow binding and deep binding. Although current is not dynamic scope, some of the same issues and tradeoffs apply. You are missing the requirement that the identity of the outer WindowProxy, which contains a series of documents loaded into it over time, remain the same, while the identities, plural, of the inner Window objects, each the global for its own document, also remain the same. In a shallow bound implementation. the WindowProxy's properties are direct properties -- not forwarded. On page navigation, these properties are copied into the Window object corresponding to the old page, and the properties on the Window object corresponding to the new page are copied onto the WindowProxy. And the scope chains for all the functions and activations in the old page are rewritten to refer to the Window object corresponding to the old page, not the WindowProxy? This does not scale at all. And the reference monitor that checks access rights in the WindowProxy must run when the accesses come from only certain code. How does that work without disjoint global (end of scope chain) objects but persistent |this|? You can't know to skip the check and avoid a bad performance hit. The lexical references must suffer no penalty. Another analogy is with the register store in thread control blocks in an OS implementation. One can describe the semantics of computation in a given OS as directly updating the current per- thread register set. But instead of paying the indirection on register access, we'd rather pay the copying overhead on context switch. This doesn't work for security or performance. /be ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: The global object in browsers
You misunderstood me a bit, but no matter. Now that I better understand the constraints -- thanks! -- what I was trying to say is irrelevant. What I mess. I am at a loss to find anything sensible to recommend. On Tue, Feb 17, 2009 at 9:20 PM, Brendan Eich bren...@mozilla.com wrote: On Feb 17, 2009, at 8:17 PM, Mark Miller wrote: On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich bren...@mozilla.com wrote: 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. If Ian's Window object were provided as the ES global, then we'd have the security problem you're concerned about. But, IIUC, with the WindowProxy we don't. That seems half-right. The ES global at the end of scope chains is the inner Window object. The perisistent-identity global that you get your hands on via the DOM, |this|, |self|, and |window| is the outer or WindowProxy object. Which one did you mean by the ES global in the first sentence cited above? As for performance, wouldn't a shallow binding implementation[1] make switching which page is current be more expensive, but variable access within a page, even after a switch, would have no added expense? [1] The two primary methods of implementing dynamic scoping were known as shallow binding and deep binding. Although current is not dynamic scope, some of the same issues and tradeoffs apply. You are missing the requirement that the identity of the outer WindowProxy, which contains a series of documents loaded into it over time, remain the same, while the identities, plural, of the inner Window objects, each the global for its own document, also remain the same. In a shallow bound implementation. the WindowProxy's properties are direct properties -- not forwarded. On page navigation, these properties are copied into the Window object corresponding to the old page, and the properties on the Window object corresponding to the new page are copied onto the WindowProxy. And the scope chains for all the functions and activations in the old page are rewritten to refer to the Window object corresponding to the old page, not the WindowProxy? This does not scale at all. And the reference monitor that checks access rights in the WindowProxy must run when the accesses come from only certain code. How does that work without disjoint global (end of scope chain) objects but persistent |this|? You can't know to skip the check and avoid a bad performance hit. The lexical references must suffer no penalty. Another analogy is with the register store in thread control blocks in an OS implementation. One can describe the semantics of computation in a given OS as directly updating the current per-thread register set. But instead of paying the indirection on register access, we'd rather pay the copying overhead on context switch. This doesn't work for security or performance. /be -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
