The global object in browsers

Maciej Stachowiak mjs at apple.com
Wed Feb 18 02:15:38 PST 2009


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

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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090218/49f71ba0/attachment.html>


More information about the Es-discuss mailing list