window object

[yb]

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

[Michael Winter]

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){win dow.alert('bar' );}
(this.alert('fo o'));

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('b ar');
};
(this.alert('fo o'));

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('b ar');
})(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]

On 04/03/2006 16:27, Michael Winter wrote:

On 04/03/2006 15:44, VK wrote:
[snip]

var alert = function(m){win dow.alert('bar' );}
(this.alert('fo o'));

[snip]
var alert = function() {
window.alert('b ar');
};
(this.alert('fo o'));

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]

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){win dow.alert('bar' );}
(this.alert('fo o'));

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

[VK]

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.

[Thomas 'PointedEars' Lahn]

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

[VK]

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 (?)

[Thomas 'PointedEars' Lahn]

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

[Richard Cornford]

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.setTime out"
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.setTimeo ut - 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
"programmin g 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*Identifie rs corresponding with ECMA global object'+
' properties\n'+
'\nMath = '+Math+
'\nArray = '+Array+
'\nObject = '+Object+
'\neval = '+eval+

'\n\n*Identifie rs corresponding with browser object model'+
' global properties.\n'+
'\nclipboardDat a = '+clipboardData +
'\nsetTimout = '+setTimeout+
'\nalert = '+alert+
'\nwindow = '+window+

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

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

'\n\n*Identifie r 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">XX X</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.setTimeo ut 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.

[Randy Webb]

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.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

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('f oo'); // '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.