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
