Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > get the global object in any environment

Reply
Thread Tools

get the global object in any environment

 
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      02-22-2010
Jorge <(E-Mail Removed)> writes:

> On Feb 22, 5:37*pm, Lasse Reichstein Nielsen <(E-Mail Removed)>
> wrote:
>> Jorge <(E-Mail Removed)> 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'

 
Reply With Quote
 
 
 
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      02-22-2010
Richard Cornford <(E-Mail Removed)> 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'

 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      02-22-2010
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
 
Reply With Quote
 
Jorge
Guest
Posts: n/a
 
      02-22-2010
On Feb 22, 6:42*pm, Lasse Reichstein Nielsen <(E-Mail Removed)>
wrote:
> Jorge <(E-Mail Removed)> writes:
> > On Feb 22, 5:37*pm, Lasse Reichstein Nielsen <(E-Mail Removed)>
> > wrote:
> >> Jorge <(E-Mail Removed)> 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.
 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      02-23-2010
kangax <(E-Mail Removed)> writes:

> On 2/22/10 12:03 PM, Lasse Reichstein Nielsen wrote:
>> kangax<(E-Mail Removed)> 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'

 
Reply With Quote
 
Dr J R Stockton
Guest
Posts: n/a
 
      02-25-2010
In comp.lang.javascript message <f249e211-5103-4933-8fc2-92740e661ba7@t3
1g2000prh.googlegroups.com>, Sat, 20 Feb 2010 18:37:37, Stoyan
<(E-Mail Removed)> 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Initialize global variable before any other global variables jubelbrus C++ 5 07-20-2007 06:38 PM
Are global functions methods of the global object? User1014 Javascript 3 12-01-2006 01:02 PM
501 PIX "deny any any" "allow any any" Any Anybody? Networking Student Cisco 4 11-16-2006 10:40 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 1 10-25-2006 06:50 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 0 10-25-2006 01:04 PM



Advertisments