window object

Discussion in 'Javascript' started by yb, Mar 2, 2006.

  1. yb

    yb Guest

    Hi,

    Is there a standard for the global 'window' object in browsers? For
    example, it supports methods such as setInterval and clearInterval, and
    several others.

    I know that w3c standardized several parts of the DOM, but this does
    not include the window object.

    Thank you
     
    yb, Mar 2, 2006
    #1
    1. Advertising

  2. yb

    RobG Guest

    yb wrote:
    > Hi,
    >
    > Is there a standard for the global 'window' object in browsers? For
    > example, it supports methods such as setInterval and clearInterval, and
    > several others.


    The window object is not part of either the ECMAScript Language or W3C
    Document Object Model (DOM) specification - it belongs to DOM Level 0,
    which is described in the introduction to the W3C DOM 1 specification as:

    'The term "DOM Level 0" refers to a mix (not formally specified)
    of HTML document functionalities offered by Netscape Navigator
    version 3.0 and Microsoft Internet Explorer version 3.0. In some
    cases, attributes or methods have been included for reasons of
    backward compatibility with "DOM Level 0".'

    <URL:http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-1176245063>


    You will find references to the window object in the Gecko DOM reference:
    <URL:http://developer.mozilla.org/en/docs/DOM:window>

    and MSDN's 'HTML and DHTML' documentation:
    <URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/obj_window.asp>


    The global object is a concept of the ECMAScript Language (colloquially
    known as 'JavaScript', which is a registered trademark of Sun
    Microsystems, Inc.), see section 10.1.5 of the specification.

    In user agents that have a concept of a window object, it is synonymous
    with the global object. When explaining the global object, the above
    reference says:

    "...in the HTML document object model the window property of
    the global object is the global object itself."


    You can test whether that is true - 'this' outside any other context
    refers to the global object:

    var Global = this;

    Now 'Global' refers to the global object. To check that it refers to
    the same object as window:

    alert( Global === window ); // shows 'true'


    I guess it's possible that somewhere there is an ECMAScript environment
    that implements a window object that isn't the global object. It's more
    likely you'll find one that doesn't have a window object at all (but it
    must have a global object if compliance matters).


    > I know that w3c standardized several parts of the DOM, but this does
    > not include the window object.


    Generally there is no need to reference the window object. If there is
    a circumstance that you feel 'window' should be included in a reference,
    but are uncertain whether the environment supports a window object, then
    use the abovementioned 'Global' variable, e.g.

    var Global = this;

    function someFn(){
    ...
    Global.setTimeout(...);
    ...
    }


    Some believe that a fully qualified reference (e.g. window.setTimeout())
    makes scripts run faster as it reduces the time spent on scope chain
    resolution - I have never tried to confirm whether that is true or not.


    --
    Rob
     
    RobG, Mar 3, 2006
    #2
    1. Advertising

  3. RobG <> writes:

    > I guess it's possible that somewhere there is an ECMAScript
    > environment that implements a window object that isn't the global
    > object.


    The Adobe SVG plugin, IIRC.
    It has a window object, but it is not the global object.

    Also note that the SVG specification is trying to formalize
    some parts of DOM 0.

    > Some believe that a fully qualified reference
    > (e.g. window.setTimeout()) makes scripts run faster as it reduces the
    > time spent on scope chain resolution - I have never tried to confirm
    > whether that is true or not.


    It should be false. In fact is should run slower, if anything.
    The global "window" variable name is no different form "setTimeout".
    Both must be looked up in the same scope chain, ending at the global
    object. After that, "window.setTimeout" will do one further property
    lookup on the global object, so it should take longer than just using
    "setTimeout" directly.

    /L
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Mar 3, 2006
    #3
  4. yb

    VK Guest

    Lasse Reichstein Nielsen wrote:
    > It should be false. In fact is should run slower, if anything.
    > The global "window" variable name is no different form "setTimeout".
    > Both must be looked up in the same scope chain, ending at the global
    > object. After that, "window.setTimeout" will do one further property
    > lookup on the global object, so it should take longer than just using
    > "setTimeout" directly.


    It is not true at least for IE 5.0 or higher and Opera 8.0 or higher -
    thus for 80%-90% of the browsers on the market (grace to IE). Therefore
    ECMA-compliant scope schema will be rather a rare exeption than a rule
    with your visitors. One can hate it, scream and cry about it :) - but
    at least she should be aware of it.

    For IE and Opera "Global" object and "window" object constitute two
    distinct programming scopes. Again I'm not talking about some
    occasional models like Adobe SVG plugin or such.
    I'm talking about the standard environment of a HTML page (XHTML is not
    supported by IE and interpreted as regular HTML) with a script running
    on it.

    In such case we have Global scope (level of global variables ang Global
    methods like escape, encodeURI etc.) and Window scope *above* it (level
    of ID'entified HTML elements and window methods like setTimeout, open
    etc.)

    On lookup the engine search first in the Global scope, if not found
    then in the window scope.

    Therefore if we say declare
    var setTimeout = 'foobar';
    we shadow window.setTimeout reference (engine will find "setTimeout" in
    the Global scope first thus will never look in the window scope above).

    Respectively if we declare:
    window['foo'] = 'bar';
    and later call alert(foo) then
    engine will look first in the Global scope, fail on it, then look in
    the window scope and find it.

    For a non-aware user the fact that:
    window['foo'] = 'bar';
    alert(foo); // 'bar'
    may lead to the conclusion that Global scope and window scope are the
    same - but nothing more far from the true than that, again - at least
    for IE and Opera.

    It also explain the real mechanics of possible circular reference leaks
    in IE as well as explains the overall higher memory consumption by
    JScript - which is *not* a memory leak but makes nervious many
    developers, specially ones coming from a C++ or so background.

    As I'm kind of tired of regular hysterics about "VK unbellyfeels ECMA":
    here a sample and I don't care if it trigs the thinking process or the
    doublethink will help as usual.
    ....
    <script type="text/javascript">
    var v1 = true;

    function demo() {
    var v2 = true;
    alert(v1);
    alert(v2);
    alert(this[v2]);
    alert(v3);
    }

    window.onload = demo;
    </script>
    ....
    <div id="v1">v1</div>
    <div id="v2">v2</div>
    <div id="v3">v3</div>
    ....

    P.S. If it helped to start the thinking process (which I still hope
    despite don't care too much anymore):- the next question would be: "Is
    it possible and how in IE's scope model that a DOM object is still
    referenced in the execution context - thus not GC-available - despite
    no one JScript variable holds a reference to it?"
     
    VK, Mar 3, 2006
    #4
  5. RobG wrote:

    > [...]
    > The global object is a concept of the ECMAScript Language (colloquially
    > known as 'JavaScript', which is a registered trademark of Sun
    > Microsystems, Inc.), see section 10.1.5 of the specification.
    >
    > In user agents that have a concept of a window object, it is synonymous
    > with the global object. When explaining the global object, the above
    > reference says:
    >
    > "...in the HTML document object model the window property of
    > the global object is the global object itself."


    However, this is not a normative statement.

    You have already pointed out that "the window object" is not specified in
    ECMAScript or the W3C DOM. But to be absolutely clear about this: The
    above non-normative statement originates from ECMAScript Edition 1 (June
    1997) where it referred to "(the) HTML (document object model)" of the
    only user agents that implemented ECMAScript: Netscape Navigator (with
    JavaScript), and Internet Explorer (with JScript). (Most notably, in
    JavaScript there had been no separation between core language and
    [Netscape] DOM/AOM before JavaScript 1.4 [1999].) It certainly was not
    intended to refer to the W3C Document Object Model HTML specifications
    (the earliest draft of W3C DOM Level 1 HTML dated 1997-10-09). The term
    "HTML" has been changed to "the HTML document object model" in ECMAScript
    Edition 3 (December 1999), probably to distinguish between the markup
    language and the object model used to access the element tree created
    when it is parsed.

    > You can test whether that is true - 'this' outside any other context
    > refers to the global object:
    >
    > var Global = this;
    >
    > Now 'Global' refers to the global object. To check that it refers to
    > the same object as window:
    >
    > alert( Global === window ); // shows 'true'


    Your logic is flawed, because the `window' property of the Global object
    refers to a host object which does not need to strictly implement
    ECMAScript algorithms, including the algorithm for the `===' operator.

    Given the above strict comparison, it could as well be, and would strictly
    conform to the ECMAScript specification, that the Global Object and the
    object referred to by its host-defined `window' property are different
    objects; that the properties of the object referred to by the `window'
    property of the Global Object are also host-defined properties of the
    Global object that are added to it before execution context is entered;
    that every augmentation of the host object referred to with the `window'
    property of the Global Object includes augmentation of the Global Object
    (and vice-versa) through language-specific conforming extensions to the
    ECMAScript specification. It has been showed already here that there is a
    host object that implements the `==' operation different than specified.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Mar 3, 2006
    #5
  6. yb

    VK Guest

    RobG wrote:
    > In user agents that have a concept of a window object, it is synonymous
    > with the global object.


    I'm aware of only one browser where this is true: Firefox. "Bravo
    Firefox!" etc. but with the current share of actions this standard
    behavior is rather non-standard on the web-wide run.

    > When explaining the global object, the above
    > reference says:
    >
    > "...in the HTML document object model the window property of
    > the global object is the global object itself."


    While MSDN says: "For client versions of JScript, this refers to the
    window object if used outside of the context of any other object."
    However non-standard it may be, it is implemented exactly as
    documented.


    > You can test whether that is true - 'this' outside any other context
    > refers to the global object:
    >
    > var Global = this;
    >
    > Now 'Global' refers to the global object. To check that it refers to
    > the same object as window:
    >
    > alert( Global === window ); // shows 'true'


    Again: this test does what expected only for Firefox. In IE you simply
    getting a reference to the window and then compare window===window with
    is naturally true. Global object is escaping this test. See my post in
    this thread for the correct test demonstrating that Global and Window
    are different objects with separate scopes.
    Moreover IE distincts "The Window" (the global context atop of Global
    object) and "the window" (surrent window where the script is
    executing). Therefore "window" object is "The Window" while window.self
    is "the window". IE needs it as it implements additional current window
    scope for constructors. Say you cannot create a new instance using
    constructor located in another frame (it will be "Cannot use freed
    script" error).

    Overall there is much more of mechanics here than one sencence from
    Books of ECMA. And actually Books of ECMA is the least informative
    source to look at *for this particular question*. ;-)

    Just another chunk to think about (feel free to experiment further)

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Strict//EN"
    "http://www.w3.org/TR/html401/strict.dtd">
    <html>
    <head>
    <title>Global vs. Window</title>
    <meta http-equiv="Content-Type"
    content="text/html; charset=iso-8859-1">

    <style type="text/css">
    body { background-color: #FFFFFF}
    </style>

    <script type="text/javascript">
    /* Test 1 */
    alert(this === window);
    alert(this === window.window);
    alert(this === self);
    alert(window === self);

    // IE 6.0
    // true
    // false
    // false
    // false

    // Opera 8.51
    // false
    // false
    // false
    // true

    // Firefox 1.5.0.1
    // true
    // true
    // true
    // true

    function demo() {
    /* Test 2 */
    var alert = function(m) {window.alert(m+'bar');}
    alert('foo'); // 'foobar'
    window.alert('foo'); // 'foo'
    }

    window.onload = demo;
    </script>

    </head>

    <body>

    <div id="v1">v1</div>
    <div id="v2">v2</div>
    <div id="v3">v3</div>

    </body>
    </html>
     
    VK, Mar 4, 2006
    #6
  7. yb

    VK Guest

    > >RobG wrote:
    > > In user agents that have a concept of a window object, it is synonymous
    > > with the global object.


    > VK wrote:
    > I'm aware of only one browser where this is true: Firefox.


    Actually it is not true for Firefox neither: they just tryed to *mimic*
    that ECMA statement as hard as they could, so it's really difficult to
    catch them on the act :)

    Nevertheless the test #2 from my previous post gets them - I just
    didn't check it first on Firefox:

    function demo() {
    /* Test 2 */
    var alert = function(m) {window.alert(m+'bar');}
    alert('foo'); // 'foobar'
    window.alert('foo'); // 'foo'
    // Gocha! :)
    }
     
    VK, Mar 4, 2006
    #7
  8. On 04/03/2006 14:12, VK wrote:

    > function demo() {
    > /* Test 2 */
    > var alert = function(m) {window.alert(m+'bar');}
    > alert('foo'); // 'foobar'
    > window.alert('foo'); // 'foo'
    > // Gocha! :)
    > }


    That doesn't prove anything, except that /you/ are unbelievably incompetent.

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Mar 4, 2006
    #8
  9. yb

    VK Guest

    Michael Winter wrote:
    > On 04/03/2006 14:12, VK wrote:
    >
    > > function demo() {
    > > /* Test 2 */
    > > var alert = function(m) {window.alert(m+'bar');}
    > > alert('foo'); // 'foobar'
    > > window.alert('foo'); // 'foo'
    > > // Gocha! :)
    > > }

    >
    > That doesn't prove anything, except that /you/ are unbelievably incompetent.


    As I said: whatever.

    P.S.
    <script type="text/javascript">
    var alert = function(m){window.alert('bar');}
    (this.alert('foo'));

    // 'foo'
    // 'bar'
    </script>
     
    VK, Mar 4, 2006
    #9
  10. VK wrote:

    > Michael Winter wrote:
    >> On 04/03/2006 14:12, VK wrote:
    >> > function demo() {
    >> > /* Test 2 */
    >> > var alert = function(m) {window.alert(m+'bar');}
    >> > alert('foo'); // 'foobar'
    >> > window.alert('foo'); // 'foo'
    >> > // Gocha! :)
    >> > }

    >>
    >> That doesn't prove anything, except that /you/ are unbelievably <-.
    >> incompetent. |

    > |
    > As I said: whatever. |
    > |
    > P.S. |
    > <script type="text/javascript"> |
    > var alert = function(m){window.alert('bar');} |
    > (this.alert('foo')); |
    > |
    > // 'foo' |
    > // 'bar' |
    > </script> |

    |
    ---------------------------------------------------------------------'


    PointedEars
     
    Thomas 'PointedEars' Lahn, Mar 4, 2006
    #10
  11. On 04/03/2006 15:44, VK wrote:

    > Michael Winter wrote:


    [snip]

    >> That doesn't prove anything, except that /you/ are unbelievably
    >> incompetent.

    >
    > As I said: whatever.


    The fact that you don't understand your own code is proof.

    > P.S.
    > <script type="text/javascript">
    > var alert = function(m){window.alert('bar');}
    > (this.alert('foo'));


    This is more interesting, but not for the reason you'd like to think.

    It seems that Fx isn't parsing this properly. The following:

    var alert = function() {
    window.alert('bar');
    };
    (this.alert('foo'));

    should be exactly identical; the only significant difference is the
    addition of a semicolon at the end of the variable declaration. However,
    the change in behaviour is profound: instead of the previous two
    dialogue boxes, the code now throws a recursion error.

    It seems that the previous code (posted by VK) is equivalent to:

    var alert = (function() {
    window.alert('bar');
    })(this.alert('foo'));

    That is, the native alert method is called with an argument, 'foo'. The
    return value (undefined) is then passed as an argument to a function
    expression, which calls the native alert method a second time, with an
    argument, 'bar'. The return value from the function expression call
    (undefined) is then assigned to declared variable, alert. This final
    step can be observed in both cases with a call to the write method:

    document.write(typeof alert); /* undefined */


    To Randy (if you're reading): I think you asked for an example where
    explicit semicolons make a difference. This is a bug, granted, but an
    example nevertheless. :)

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Mar 4, 2006
    #11
  12. On 04/03/2006 16:27, Michael Winter wrote:

    > On 04/03/2006 15:44, VK wrote:


    [snip]

    >> var alert = function(m){window.alert('bar');}
    >> (this.alert('foo'));


    [snip]

    > var alert = function() {
    > window.alert('bar');
    > };
    > (this.alert('foo'));
    >
    > should be exactly identical [...]


    I forgot to mention that removing the parentheses from around the call
    (preceding semicolon, or not) also produces the expected recursion error.

    [snip]

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Mar 4, 2006
    #12
  13. [Correction] Re: window object

    On 04/03/2006 16:27, Michael Winter wrote:
    > On 04/03/2006 15:44, VK wrote:
    >
    >> Michael Winter wrote:

    >
    >
    > [snip]
    >
    >>> That doesn't prove anything, except that /you/ are unbelievably
    >>> incompetent.

    >>
    >>
    >> As I said: whatever.

    >
    >
    > The fact that you don't understand your own code is proof.
    >
    >> P.S.
    >> <script type="text/javascript">
    >> var alert = function(m){window.alert('bar');}
    >> (this.alert('foo'));


    [snip]

    > It seems that Fx isn't parsing this properly. [...]


    Scratch that. I'm so used to writing:

    (function() {
    })(...);

    that I forgot that:

    function() {
    }(...);

    is perfectly fine as long as 'function' isn't the first token (as in the
    Initialiser production, above).

    Mike

    --
    Michael Winter
    Prefix subject with [News] before replying by e-mail.
     
    Michael Winter, Mar 4, 2006
    #13
  14. yb

    VK Guest

    Michael Winter wrote:
    > > The fact that you don't understand your own code is proof.


    I don't understand ECMA/Firefox sometimes - it is true. Their way of
    thinking and acting is sometimes too alien to what I used from Netscape
    and Internet Explorer.

    So I just have to repeat once again: "Bravo Firefox!". Whatever is
    strictly spelled, vaguely mentioned or softly murmured in ECMA or W3C
    is being implemented at the best of human abilities.

    So then we have two scope schemas: one from IE other from FF. Opera is
    kind of sitting between two chairs (which is the normal position for
    this browser :)

    I'm wandering what my tests would show for Safari/Konqueror.
     
    VK, Mar 4, 2006
    #14
  15. VK wrote:

    > Michael Winter wrote:
    >> > The fact that you don't understand your own code is proof.

    >
    > I don't understand ECMA/Firefox sometimes - it is true.


    You have never displayed a blink of understanding of the specification.

    > Their way of thinking and acting is sometimes too alien to what I used
    > from Netscape and Internet Explorer.


    It is not. You have just still not understood that Netscape 3+ and Internet
    Explorer use ECMAScript implementations as primary scripting language, and
    that conforming ECMAScript implementations may be extended compared to the
    specification, according to its Conformance section.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Mar 4, 2006
    #15
  16. yb

    VK Guest

    Thomas 'PointedEars' Lahn wrote:
    > It is not. You have just still not understood that Netscape 3+ and Internet
    > Explorer use ECMAScript implementations as primary scripting language


    One cannot implement something that has to be written yet (ECMAScript
    specs).
    Netscape Gold and Internet Explorer 3.02 simply have JavaScript 1.1 and
    JScript 1.0 as primary scripting language respectively (Internet
    Explorer 3.0 has VBScript as default language).

    > and
    > that conforming ECMAScript implementations may be extended compared to the
    > specification, according to its Conformance section.


    What does it have to do with tea and China? IE and Opera have two
    separate scopes: Global and enclosing Window. Firefox has (or
    pretending to have) only one: Global wich is Window (or Window which is
    Global - I'm really lost here). If both allowed by specs so the better.
    If one of them is not allowed by specs - it doesn't make it disappear.

    One cannot just keep saying "This is so because it is written so". You
    need some correlation with the reality, especially if it involves
    80%-90% of UA's (?)
     
    VK, Mar 4, 2006
    #16
  17. VK wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> It is not. You have just still not understood that Netscape 3+ and
    >> Internet Explorer use ECMAScript implementations as primary scripting
    >> language

    >
    > One cannot implement something that has to be written yet (ECMAScript
    > specs).


    One can. It is the idea of the language that counts here, not the written
    representation of it.

    > Netscape Gold and Internet Explorer 3.02 simply have JavaScript 1.1 and
    > JScript 1.0 as primary scripting language respectively


    ,-[ECMAScript Edition 3]
    |
    | Brief History
    |
    | This ECMA Standard is based on several originating technologies, the
    | most well known being JavaScript (Netscape) and JScript (Microsoft). The
    | language was invented by Brendan Eich at Netscape and first appeared in
    | that company's Navigator 2.0 browser. It has appeared in all subsequent
    | browsers from Netscape and in all browsers from Microsoft starting with
    | Internet Explorer 3.0.
    |
    | The development of this Standard started in November 1996. The first
    | edition of this ECMA Standard was adopted by the ECMA General Assembly
    | of June 1997.
    |
    | That ECMA Standard was submitted to ISO/IEC JTC 1 for adoption under the
    | fast-track procedure, and approved as international standard ISO/IEC
    | 16262, in April 1998. The ECMA General Assembly of June 1998 approved the
    | second edition of ECMA-262 to keep it fully aligned with ISO/IEC 16262.
    | Changes between the first and the second edition are editorial in nature.

    Therefore, and because of the behavior they display, one can say
    rightfully that both JavaScript 1.1 (implemented in Netscape 3.0,
    August 1996), and JScript 1.0 (implemented in IE 3.0, dito) are
    (extended) ECMAScript implementations.

    > (Internet Explorer 3.0 has VBScript as default language).


    I cannot test that, yet both the W3C DOM HTML Specification (in
    its reference to DOM Level 0) and the MSDN Library say otherwise.


    PointedEars
     
    Thomas 'PointedEars' Lahn, Mar 4, 2006
    #17
  18. VK wrote:
    > Lasse Reichstein Nielsen wrote:
    >> It should be false. In fact is should run slower, if anything.
    >> The global "window" variable name is no different form
    >> "setTimeout". Both must be looked up in the same scope chain,
    >> ending at the global object. After that, "window.setTimeout"
    >> will do one further property lookup on the global object, so
    >> it should take longer than just using "setTimeout" directly.

    >
    > It is not true at least for IE 5.0 or higher and Opera 8.0
    > or higher - thus for 80%-90% of the browsers on the market
    > (grace to IE).


    What is not true? That - window.setTimeout - should take longer to
    resolve than unqualified - setTimeout -? It does take longer, you just
    have to time it to see that.

    > Therefore ECMA-compliant scope schema will be rather a rare
    > exeption than a rule with your visitors. One can hate it,
    > scream and cry about it :) - but at least she should be
    > aware of it.


    So is it the resolution of Identifiers against the scope chain, or the
    scope chain itself that you think does not follow the specification?
    That should be fairly simple to demonstrate as all you would have to do
    is show some code that ECMA 262 says should result in one behaviour that
    actually exhibits another. Of course you need to both know what ECMA 262
    says the code should do and understand the code written. That is a bit
    of a problem for you as you don't understand ECMA 262 or the javascript
    you write.

    > For IE and Opera "Global" object and "window" object
    > constitute two distinct programming scopes.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    And that should be a fairly simple assertion to back-up. Although
    "programming scopes" is essentially meaningless; another piece of
    fictitious jargon from someone more interested in giving the impression
    that they know more than they do. On the other hand "two distinct" is
    concrete enough for consideration. It implies that the global object and
    the window object are two distinct entities.

    > Again I'm not talking about some
    > occasional models like Adobe SVG plugin or such.
    > I'm talking about the standard environment of a HTML page
    > (XHTML is not supported by IE and interpreted as regular HTML)
    > with a script running on it.
    >
    > In such case we have Global scope (level of global variables
    > ang Global methods like escape, encodeURI etc.) and Window scope
    > *above* it (level of ID'entified HTML elements and window methods
    > like setTimeout, open etc.)


    The implication if which is that there are two distinct objects on the
    scope chain; one the ECMAScript global object with the specification
    defined properties and the other a true host object with browser defined
    properties.

    > On lookup the engine search first in the Global scope, if not
    > found then in the window scope.


    So in scope chain resolution the ECMAScript global object is encountered
    first on the scope chain and the 'window' object comes after that?

    Well, we can test that proposition with a bit of scope chain
    augmentation. Suppose we explicitly put the object referred to by -
    window - on the scope chain of an inner function (with a - with -
    statement) and give the outer function local variables with identifiers
    that would mask global properties of interest. Acting upon those
    unqualified Identifiers inside the inner function would not involve the
    consequences of getting to the end of the scope chain because if not
    resolved as propitious of the object added to the scope chain they would
    be caught by being resolved as priorities of the Activation/variable
    object of the outer function.

    If the window and global objects are two distinct entities that have
    different sets of properties, Identifiers referring to properties of
    the one that had _not_ been added to the scope chain would be
    resolved as the outer function's local variables. Finding any single
    Identifier that could not be resolved as a property of the object
    added to the scope chain would _prove_ that there were two distinct
    objects, failing to demonstrate this would suggest a single global
    object. E.G:-

    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    "http://www.w3.org/TR/html4/loose.dtd">
    <html>
    <head>
    <title></title>
    <meta http-equiv="Content-Type"
    content="text/html; charset=iso-8859-1">
    <script type="text/javascript">

    var globalVar = 'Global Variable';

    function getWindow(){
    return window;
    }
    function getGlobal(){
    return this;
    }

    window.onload = (function(){
    var localFnc;
    /* Identifier corresponding with IDed DIV element */
    var testDiv = 'Outer Function variable';

    /* Identifiers corresponding with ECMA global object properties */
    var Math = 'Outer Function variable';
    var Array = 'Outer Function variable';
    var Object = 'Outer Function variable';
    var eval = 'Outer Function variable';
    /* Identifiers corresponding with browser object model global
    properties. */
    var clipboardData = 'Outer Function variable';
    var setTimeout = 'Outer Function variable';
    var alert = 'Outer Function variable';
    var window = 'Outer Function variable';

    /* Identifier corresponding with a declared global variable */
    var globalVar = 'Outer Function variable';

    /* Explicitly add a property to the - window - object:- */
    getWindow()['foo'] = 'Assigned to window object'
    /* Identifier corresponding with an property explicitly added
    to the window object */
    var foo = 'Outer Function variable';

    /* Explicitly add a property to the - this - object:- */
    this['bar'] = 'Assigned to window object'
    /* Identifier corresponding with an property explicitly added
    to the window object */
    var bar = 'Outer Function variable';

    /* Cannot use the - window - reference directly as it is defined
    as a local string variable in this scope so call a function
    that will return - window - instead:- */
    with( getWindow() ){ // Add the - window - object to the inner
    // function's scope chain.
    localFnc = (function(){
    alert(
    '*Identifier corresponding with IDed DIV element\n'+
    'testDiv = '+testDiv+

    '\n\n*Identifiers corresponding with ECMA global object'+
    ' properties\n'+
    '\nMath = '+Math+
    '\nArray = '+Array+
    '\nObject = '+Object+
    '\neval = '+eval+

    '\n\n*Identifiers corresponding with browser object model'+
    ' global properties.\n'+
    '\nclipboardData = '+clipboardData+
    '\nsetTimout = '+setTimeout+
    '\nalert = '+alert+
    '\nwindow = '+window+

    '\n\n*Identifier corresponding with a declared global'+
    ' variable\n'+
    '\nglobalVar = '+globalVar+

    '\n\n*Identifier corresponding with an property explicitly'+
    ' added to the window object'+
    '\nfoo = '+foo+

    '\n\n*Identifier corresponding with an property explicitly'+
    ' added to the global - this - object'+
    '\nbar = '+bar+
    ''
    );
    });
    }
    /* Return the inner function so it can be assigned to
    - window.onload -:- */
    return localFnc;
    })();


    </script>
    </head>
    <body>
    <div id="testDiv">XXX</div>
    </body>
    </html>

    It is also possible to repeat that experiment using the - this -
    reference as the object added to the scope chain (or any other
    candidate for similar consideration).

    And the results of running that on IE 6 are that whichever object (-
    window - or - this -) is added to the inner function's scope chain that
    object has; properties that correspond with IDed DOM elements,
    properties that correspond with ECMA 262 defined global properties,
    properties that correspond with expected browser object model global
    properties, properties that correspond with declared global variables
    and properties corresponding with properties added to both the -
    window - and - this - object at runtime.

    This result shows no evidence of two distinct objects at the end of the
    scope chain as the single object that is expected to be at the end of
    the scope chain behaves as if it has all the required properties itself.

    > Therefore if we say declare
    > var setTimeout = 'foobar';
    > we shadow window.setTimeout reference (engine will find
    > "setTimeout" in the Global scope first thus will never
    > look in the window scope above).


    No demonstration of 'shadowing' has been made. The behaviour
    demonstrated is instead completely in accordance with a single global
    object being subject to procedure for variable instantiation as
    described in ECMA 262, 3rd ed. sections 10.1.3 and 10.2.1.

    > Respectively if we declare:
    > window['foo'] = 'bar';
    > and later call alert(foo) then engine will look first in
    > the Global scope, fail on it, then look in
    > the window scope and find it.


    With the implication that the global object does not have an - alert -
    property or a - foo - property? Neither have been demonstrated, and the
    above test shows that both the - window - object and the global - this -
    object behave in isolation as if they have properties corresponding with
    ECMA 262 defined global properties, browser global properties, declared
    local variables, runtime added properties, etc.

    > For a non-aware user the fact that:
    > window['foo'] = 'bar';
    > alert(foo); // 'bar'
    > may lead to the conclusion that Global scope and window scope
    > are the same - but nothing more far from the true than that,
    > again - at least for IE and Opera.


    So far no case has been made for that conclusion.

    > It also explain the real mechanics of possible circular
    > reference leaks in IE


    You mean the things that you didn't believe existed last week, and still
    don't understand?

    > as well as explains the overall higher memory consumption
    > by JScript - which is *not* a memory leak but makes nervious
    > many developers, specially ones coming from a C++ or so
    > background.


    Explaining the circular reference memory leaks in terms of inaccessible
    additional objects in the scope chain would be inadequate as then the
    problem could not be addressed, due to the inaccessibility of these
    additional objects.

    > As I'm kind of tired of regular hysterics about
    > "VK unbellyfeels ECMA":


    Stop making out that you know something special to people who have a
    better understanding of the subject than you and have considerably
    greater talent for analysis than you and you may stop people calling you
    a fool.

    > here a sample and I don't care if it trigs the thinking
    > process or the doublethink will help as usual.


    Although writing sentences that make sense would also contribute to your
    not being considered quite the fool you currently are.

    > ...
    > <script type="text/javascript">


    Once again you post code without stating what it is you suppose that it
    is demonstrating. And in not stating what is supposed to be demonstrated
    by this code it becomes difficult to say whether it is demonstrated or
    not, but presumably if you are trying to make any point at all your
    notion of this code is that it demonstrates something that would differ
    from the behaviour predicted by an ECMA 262 conforming implementation.
    Well, lets look at the ECMA 262 derived perdition and see if the results
    do demonstrate IE differing from that behaviour:-

    > var v1 = true;


    A global variable is declare and assigned a value. Variable
    instantiation in the global scope uses the ECMAScript global object as
    the variable object so it would be the global object to which a property
    would be added with the name 'v1', unless the property already exists in
    which case it is left alone. When the global code is executed a value is
    assigned to that property of the global object.

    > function demo() {
    > var v2 = true;


    A local variable is created with the name 'v2' on the function's
    execution context's Activation/variable object and when the function
    body is executed the boolean value - true - is assigned to that
    property.

    > alert(v1);


    Output, now we get to see if behaviour corresponds with expectations.
    The Identifier - alert - is resolved into a reference to the global -
    alert - function and that function is called with an argument list
    consisting of the value read using the Identifier - v1 - . The
    Identifier - v1 - is resolved at the end of the scope chain as a
    property of the global object that corresponds with the declared global
    variable and has the value - true -. The - alert - function
    type-converts its boolean - true - argument into the string 'true' and
    alerts that.

    ECMA 262 predicted outcome: alters the string 'true'.

    Observed outcome: alerts the string 'true'.

    > alert(v2);


    Similarly the Identifier - v2 - is resolved as a property of the
    function's execution context's Activation/Variable object. That property
    has the value - true - and alert type converts that into the string
    'true'.

    ECMA 262 predicted outcome: alters the string 'true'.

    Observed outcome: alerts the string 'true'.

    > alert(this[v2]);


    This time the argument to - alert - is the result of the expression -
    this[v2] -. As this function is executed as a method of the - window -
    object the - this - keyword is resolved as a reference to the - window -
    object. The bracket notation property accessor requires that the - v2 -
    Identifier be resolved, evaluated and type-converted into a string that
    will be used as a property name in association with the - this - object.
    The - v2 - Identifier is resolved as the local variable - v2 - with the
    value - true -. That value is type-converted into the string 'true' and
    used as the property name to be resolved in association with - this -,
    i.e.- this['true'] -.

    The expression - this['true'] - returns the value - undefined - because
    the window object has no property named 'true', and alert type-converts
    undefined into the string 'undefined' and alerts that.

    ECMA 262 predicted outcome: alters the string 'undefined'.

    Observed outcome: alerts the string 'undefined'.

    > alert(v3);


    As we know IE (and other browsers) make DOM elements with ID attributes
    available as global properties under names corresponding with their IDs,
    assuming that they do not clash with declared global variables. The
    Identifier - v3 - corresponds with the ID of a DOM element and does not
    clash with a declared global variable so we can expect - v3 - to resolve
    as a reference to that DOM element. The type-conversion of an IE DOM
    element to a string is the string '[object]' so that is what will be
    alerted.

    ECMA 262 predicted outcome: alters the string '[object]'.

    Observed outcome: alerts the string '[object]'.

    > }
    >
    > window.onload = demo;
    > </script>
    > ...
    > <div id="v1">v1</div>
    > <div id="v2">v2</div>
    > <div id="v3">v3</div>
    > ...


    So once again you post code that is supposed to demonstrate some arcane
    'truth' that actually does no more than behave 100% in accordance with
    the behaviour that would be expected of a 100% ECMA 262 3rd ed.
    conforming implementation. There is certainly nothing happening here
    that requires more than one global object, or suggests any additional
    objects on the scope chain.

    Did you, by any chance, let yourself be fooled by - alert(this[v2]); -
    alerting ' undefined'? I think you did, but as has been pointed out so
    many times you don't understand the basics of javascript so you don't
    understand what the code you write actually does. You probably indented
    to write - alert(this['v2']); - or - alert(this.v2); -, but that would
    have alerted '[object]' and done nothing but demonstrated more expected
    behaviour.

    > P.S. If it helped to start the thinking process (which
    > I still hope despite don't care too much anymore):-


    It appears that no matter how often you make yourself look a fool in
    public it never starts your thinking process. You have made the mistake
    of confusing yourself with someone who knows what they are doing and
    apparently no amount of evidence to the contrary is capable of enabling
    you to rectify that error.

    > the next question would be: "Is it possible and how in IE's
    > scope model that a DOM object is still referenced in the
    > execution context - thus not GC-available - despite
    > no one JScript variable holds a reference to it?"


    Given that you made your original proposition up off the top of your
    head without any evidence to back it up and posted a non-demonstration
    of it 'in action', the 'next question' is entirely moot. However, that
    'next question' hardly qualifies as a question, being the sort of
    incoherent rambling that might be expected from the mentally ill.

    Richard.
     
    Richard Cornford, Mar 4, 2006
    #18
  19. yb

    Randy Webb Guest

    Thomas 'PointedEars' Lahn said the following on 3/4/2006 3:20 PM:
    > VK wrote:


    <snip>

    >> (Internet Explorer 3.0 has VBScript as default language).

    >
    > I cannot test that, yet both the W3C DOM HTML Specification (in
    > its reference to DOM Level 0) and the MSDN Library say otherwise.


    And those two references are always 100% correct? Think about what MSDN
    had to say about IE7 and the XMLHTTPRequest Object before you answer.
    And if that doesn't do it, consider what MSDN has to say about toFixed()
    and where it is known *not* to work.

    MSDN and W3C are not always correct. Doesn't mean I agree with VK (I
    don't care what the default language in IE3.0 was), I do disagree with
    the notion (and VK pointed it out) that "Just because something says so
    doesn't make it right)". And that alone makes me not care what the specs
    say as much as I care what the browsers/UA actually *does* with code.

    --
    Randy
    comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
    Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
     
    Randy Webb, Mar 4, 2006
    #19
  20. VK wrote:
    > VK wrote:
    >> RobG wrote:
    >>> In user agents that have a concept of a window object,
    >>> it is synonymous with the global object.

    >
    >> I'm aware of only one browser where this is true: Firefox.


    You lack of awareness of web browsers is becoming legendary.

    > Actually it is not true for Firefox neither: they just
    > tryed to *mimic* that ECMA statement as hard as they could,
    > so it's really difficult to catch them on the act :)


    And particularly difficult when you don't know what the code you write
    is supposed to do, have no analytical skills and don't really comprehend
    logic.

    > Nevertheless the test #2 from my previous post gets them
    > - I just didn't check it first on Firefox:


    LOL

    > function demo() {
    > /* Test 2 */
    > var alert = function(m) {window.alert(m+'bar');}
    > alert('foo'); // 'foobar'
    > window.alert('foo'); // 'foo'
    > // Gocha! :)
    > }


    So after all this time (what is it, 8-9 years) of supposedly scripting
    web browsers you don't actually understand how local variables work? You
    create a local variable called - alert - and then assign a reference to
    a function object to it and then you don't see why the unqualified
    Identifier - alert - is resolved as a reference to that local variable
    (and its assigned function) while the property accessor - window.alert -
    resolves as a reference to the global - alert - function? How many false
    conclusions have you drown over those years form misconceiving the code
    that your write?

    How can you possibly hope to deduce anything about how web browsers
    behave if you don't even know what the code you are writing is supposed
    to be doing? Don't you think it would be a good idea to stop bothering
    people here with your misconceived nonsense until you have learnt the
    basics of the language you are so keen to assert your expertise in?

    Richard.
     
    Richard Cornford, Mar 4, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Frank
    Replies:
    1
    Views:
    695
    William Ryan
    Dec 31, 2003
  2. Andrew Bewley via DotNetMonster.com

    window to window communication (window.opener)

    Andrew Bewley via DotNetMonster.com, Feb 3, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    1,094
    Andrew Bewley via DotNetMonster.com
    Feb 3, 2005
  3. jon wayne
    Replies:
    9
    Views:
    738
    Jim Langston
    Sep 22, 2005
  4. datactrl
    Replies:
    3
    Views:
    161
    Thomas 'PointedEars' Lahn
    May 29, 2004
  5. sowen
    Replies:
    2
    Views:
    182
    Thomas 'PointedEars' Lahn
    Aug 8, 2007
Loading...

Share This Page