«

Jorge <> writes:

> On Feb 22, 5:37*pm, Lasse Reichstein Nielsen <lrn.unr...@gmail.com>
> wrote:
>> Jorge <jo...@jorgechamorro.com> writes:
>> > (globalObject).window === (globalObject).self === (globalObject)
>>
>> In IE8:
>> *var global = function(){return this;}();
>> *global.window === global; *// => false
>>
>> Didn't help, sorry.
>> (Might be a bug in ===, but it's still false
>
> Yes yes. And there are many many more odd things that are true -only-
> in IEs. Are you saying that's the way it should be ? Are you -maybe-
> advocating to standardize that behaviour ? Because if not, you'd
> better think of it as just "another bug in IE".

I'm not saying it should be like this, but neither am I saying in
general terms how a non-standardized feature behaves, while ignoring
how it actually works in one of the most common browsers.

Eventually (perhaps) browsers will be HTML 5 compliant, with both
a Window and a WindowProxy object (which is merely a codification of
the way most browsers already work). Then it will be true that
this.object = this
in the global scope (but neither side is the global object .

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Richard Cornford <> writes:

> On Feb 22, 5:03 pm, Lasse Reichstein Nielsen wrote:
> <snip>
>> I can't find a way that's guaranteed to get you out of a
>> strict mode jail that tries to hide the global object.
>
> I assume you mean a way out that is not just not opting into strict
> mode, and so never being in the jail to start with.

Yes, I mean a situation where I get to specify some code to be
executed in a completely unknown context, and want to get hold
of a reference to the global object.

If the context turns out to be strict mode, and someone wants to
block me, I can't see a way that can't be blocked.
Which is probably a good thing for those who want a safe subset
of ES
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

kangax wrote:

> Thomas 'PointedEars' Lahn wrote:
>> kangax wrote:
>>> If I'm reading spec correctly, one of the ways to get global object
>>> from within _any_ code in ES5 is by using indirect call to eval.
>>>
>>> To quote Annex E from ES5:
>>>
>>> "indirect calls to the eval function use the global environment as both
>>> the variable environment and lexical environment for the eval code"
>>
>> You have omitted the important part that immediately follows:
>>
>> | . In Edition 3, the variable and lexical environments of the caller
>> | of an indirect e was used as the environments for the eval code.
>>
>> For this paragraph is part of the *informal* Annex E because that
>> section
>
> The formal part is 10.4.2:
>
> 1. If there is no calling context or if the eval code is not being
> evaluated by a direct call (15.1.2.1.1) to the eval function then,
>
> a. Initialize the execution context as if it was a global execution
> context using the eval code as C as described in 10.4.1.1.
>
> [...]
>
> Let's see 10.4.1.1:
>
> The following steps are performed to initialize a global execution
> context for ECMAScript code C:
>
> 1. Set the VariableEnvironment to the Global Environment.
> 2. Set the LexicalEnvironment to the Global Environment.
>
> 3. Set the ThisBinding to the global object.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Fair enough. But that was _not_ what you were referring to, therefore not
what I was referring to when I said

>> I do not think you are understanding the Specification correctly.

and therefore your

> And I think you're not reading Specification carefully.

is not justified.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

On Feb 22, 6:42*pm, Lasse Reichstein Nielsen <lrn.unr...@gmail.com>
wrote:
> Jorge <jo...@jorgechamorro.com> writes:
> > On Feb 22, 5:37*pm, Lasse Reichstein Nielsen <lrn.unr...@gmail.com>
> > wrote:
> >> Jorge <jo...@jorgechamorro.com> writes:
> >> > (globalObject).window === (globalObject).self === (globalObject)
>
> >> In IE8:
> >> *var global = function(){return this;}();
> >> *global.window === global; *// => false
>
> >> Didn't help, sorry.
> >> (Might be a bug in ===, but it's still false
>
> > Yes yes. And there are many many more odd things that are true -only-
> > in IEs. Are you saying that's the way it should be ? Are you -maybe-
> > advocating to standardize that behaviour ? Because if not, you'd
> > better think of it as just "another bug in IE".
>
> I'm not saying it should be like this, but neither am I saying in
> general terms how a non-standardized feature behaves, while ignoring
> how it actually works in one of the most common browsers.

It's that I love to ignore *that* browser. Blatantly

> Eventually (perhaps) browsers will be HTML 5 compliant, with both
> a Window and a WindowProxy object (which is merely a codification of
> the way most browsers already work). Then it will be true that
>
> * this.object = this

this.object or this.window ?

> in the global scope (but neither side is the global object .

It depends. What exactly would you expect a global object to be, when
there are several different (JS) contexts ?

You probably don't expect the next tab's global object to be the
same... unless there's a parent-child relation: then the expectations
suddenly change (subtly).

And, what exactly would you expect a global object to hold ?

Does it hold just the context's user-defined globals ?
Does it hold the built-ins too ? But the same built-ins shared among
contexts, or distinct separate instances ?
If you mutate a global built-in, does it mutate the other contexts'
built ins too ?

These kind of things -for sure- ought to be established, specified and
standardized.

And I'm not sure that the fact that each window/frame/iframe/tab/
worker has its own JS context/global object contradicts the ES specs,
when the specs are written for a single context, with just a single
context in mind. Yes, each of these contexts has these "doors" to go
to the others, but, how's that against the specs ?
--
Jorge.

kangax <> writes:

> On 2/22/10 12:03 PM, Lasse Reichstein Nielsen wrote:
>> kangax<> writes:
>>
>>> If I'm reading spec correctly, one of the ways to get global object
>>> from within _any_ code in ES5 is by using indirect call to eval.
>>
>> Not if there is another variable called "eval" in scope.
>
> But, AIUI, you can't have another variable named eval in strict mode

No, but you can create a shadowing binding before entering strict mode, e.g.,

// Non-strict context.
function myEval(s) { "use strict"; return eval(s); }
function shadower() {
var eval = myEval;
return function context(){
"use strict";
<< your code inserted here >>
}();
}
shadower();

>> If you are certain to have access to "eval" on the global object, you
>> are pretty close to haveing the global object itself.
>>
>> Another approach is Function("return this")(), but Function may be
>
> That was my first thought as well, but from what I can see, this won't
> "work". It looks like `Function('return this')()` won't give you a
> global object.

True, my mistake. The function's scope will be the global environment,
but it will create a new scope when it's called, just as any other
function.

> Or did I miss something?

No, not as far as I can see.


However, the Function constructor can create non-strict functions in
a strict environment, so this should work:

var global = Function("return function(){return this;}();")();

A determined jailer will be able to prevent that too, by changing
the binding of Function and Function.prototype.constructor:

var myFunction = function(oldFunction) {
var myFunction = function Function(args) {
var arr = Array.prototype.slice.call(args, 0, args.length);
arr[arr.length-1] = '"use strict";\n' + arr[arr.length-1];
return oldFunction.apply(null, arr);
};
Function.prototype.constructor = myFunction;
return myFunction;
}(Function);
function myEval(s) { "use strict"; return eval(s); }
function shadower() {
var eval = myEval;
var Function = myFunction;
return function() {
"use strict";
<< Your code, in jail >>
}();
}


I'm sure there are still holes in this (e.g., setTimeout with string
argument), but the idea is to prevent you from getting access to
running non-strict code in any way. That will also prevent you from
getting direct access to the global object.

You will actually need to shadow access to ANY non-frozen object on
the global object - because if "foo" refers to an property of the
global object, then
foo.bar = function() { return this; }
var global = foo.bar();
would work.

Strict mode is build so that you can't access strict mode variables
from non-strict code. You are still allowed to create non-strict code,
but only as if the code was running in the global environment.
/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

In comp.lang.javascript message <f249e211-5103-4933-8fc2-92740e661ba7@t3
1g2000prh.googlegroups.com>, Sat, 20 Feb 2010 18:37:37, Stoyan
<> posted:

>Since JS is everywhere (client, server, desktop...), it makes sense to
>think how to write code that could run in environments other than the
>one originally in mind. Perhaps it's not a good idea to use `window`
>when the code could possibly run in environment that has no idea what
>`window` is.


Evidently you cannot use any of the special properties of "window".

Do you really [always] need to access *THE* Global Object, or might it
be [sometimes] sufficient to create one with a known name, perhaps by
var glObj , and use it instead?

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.