The global object in browsers
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
> says "true", then test 002. If 002 says "false", then ES is being
> in some way. If 002 doesn't say anything, then code is being blocked
> 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
> false, then test 005 -- if that says true before and false after,
> then the
> browser is probably incompatible with legacy content.
> FF = Firefox 3.0.6
> WK = WebKit nightly for Safari Version 3.2.1 (5525.27.1)
> CR = Chrome 18.104.22.168
> 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
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.
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
Given these constraints, the most natural solution is a "split window"
type approach, which both Gecko and WebKit implement.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es-discuss