The global object in browsers

[Mark Miller-2]

On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan@...> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:

On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan@...> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Mark Miller-2]

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 <brendan@...> wrote:

On Feb 17, 2009, at 8:17 PM, Mark Miller wrote:

On Tue, Feb 17, 2009 at 6:38 PM, Brendan Eich <brendan@...> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

On Feb 17, 2009, at 4:52 PM, Mark Miller wrote:

On Tue, Feb 17, 2009 at 3:02 PM, Ian Hickson <ian@...> 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 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.

There's really two basic requirements that have to be met here:

1) For compatibility, a reference to the Window object (which acts as the global object of a frame or window) must act as a persistent handle for code outside the frame/window and must continue to reflect the current contents of the given frame/window even if it is navigated to a new document.

2) For security, it must not be possible for a function saved from a an older document in a given Window to see variables created when some other document is current, if those documents are not same-origin. (The same applies in reverse - code associated with new documents must not see old variable bindings).

In addition, there are two constraints strongly suggested by performance considerations:

3) Variable lookup via the scope chain shouldn't have to do a same-origin check for every access, as that is too slow compared to the cost of variable lookup alone.

4) JavaScript-to-JavaScript function calls shouldn't have to do a check to see if the function being called is associated with a non-current document - doing this at every JS-to-JS call boundary is quite expensive.

Given these constraints, the most natural solution is a "split window" type approach, which both Gecko and WebKit implement.

Regards,

Maciej

_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

On Feb 17, 2009, at 6:31 PM, Mark Miller wrote:

> 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.

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Ian Hickson]

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-html@... 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Brendan Eich-3]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[David-Sarah Hopwood]

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).

>> 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,

It's not possible to observe that, since by hypothesis neither object is
accessible to ECMAScript code.

> but the object returned by the global-scope "this" in scripts from A and B
> are the same object (===).

That would still be the case in MarkM's relabelling.


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.

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.

--
David-Sarah Hopwood ⚥

_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[David-Sarah Hopwood]

Ian Hickson wrote:

> 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.

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Ian Hickson]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Ian Hickson]

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 <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.
>
> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[David-Sarah Hopwood]

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).

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@...
https://mail.mozilla.org/listinfo/es-discuss

[David-Sarah Hopwood]

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 <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.
>>
>> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Ian Hickson]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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 <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.
>
> 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@...
https://mail.mozilla.org/listinfo/es-discuss

[Maciej Stachowiak]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Allen Wirfs-Brock-2]

>-----Original Message-----
>From: es-discuss-bounces@... [mailto:es-discuss-
>bounces@...] On Behalf Of Maciej Stachowiak
...
>
>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
>

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.

Allen
_______________________________________________
Es-discuss mailing list
Es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Ian Hickson]

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@...
https://mail.mozilla.org/listinfo/es-discuss