Recent changes to Global_object

Global_object modified by mmartz

mmartz — Mon, 05 Aug 2019 09:51:19 -0000

--- v3
+++ v4
@@ -18,7 +18,7 @@

 A Greasemonkey [User script](User_script), however, by default wraps up all code inside an anonymous function wrapper that swallows identifiers, causing them not to end up on the global object. The useful effect of this wrapper is to protect user scripts from global identifiers in the Greasemonkey sandbox that might otherwise collide with yours and make it not work *(yielding unhelpful errors such as "invalid value")*.

-Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#0.8.20080609.0) removed it and [0.8.1](Version_history#0.8.20090123.1) re-added it by default, unless the script wright disables it manually using [@unwrap](Metadata_Block#unwrap). In the context of such a *user script*, the *special operator* [this](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/this) acts as *"the global object is passed as the context object"*, which behind the scenes is also linked to the `window` object, which is in turn a [XPCNativeWrapper](XPCNativeWrapper) wrapped version of [unsafeWindow](unsafeWindow) - the window of the *user script's* target page. 
+Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#08200806090) removed it and [0.8.1](Version_history#08200901231) re-added it by default, unless the script wright disables it manually using [@unwrap](Metadata_Block#unwrap). In the context of such a *user script*, the *special operator* [this](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/this) acts as *"the global object is passed as the context object"*, which behind the scenes is also linked to the `window` object, which is in turn a [XPCNativeWrapper](XPCNativeWrapper) wrapped version of [unsafeWindow](unsafeWindow) - the window of the *user script's* target page. 

 ### Debugging

Global_object modified by Martz

Martz — Sun, 10 Aug 2014 06:43:50 -0000

--- v2
+++ v3
@@ -18,14 +18,14 @@

 A Greasemonkey [User script](User_script), however, by default wraps up all code inside an anonymous function wrapper that swallows identifiers, causing them not to end up on the global object. The useful effect of this wrapper is to protect user scripts from global identifiers in the Greasemonkey sandbox that might otherwise collide with yours and make it not work *(yielding unhelpful errors such as "invalid value")*.

-Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#0.8.20080609.0) removed it and [0.8.1](Version_history#0.8.20090123.1) re-added it by default, unless the script wright disables it manually using [@unwrap](Greasemonkey_Manual:Metadata_Block#unwrap). In the context of such a *user script*, the *special operator* [this](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/this) acts as *"the global object is passed as the context object"*, which behind the scenes is also linked to the `window` object, which is in turn a [XPCNativeWrapper](XPCNativeWrapper) wrapped version of [unsafeWindow](unsafeWindow) - the window of the *user script's* target page. 
+Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#0.8.20080609.0) removed it and [0.8.1](Version_history#0.8.20090123.1) re-added it by default, unless the script wright disables it manually using [@unwrap](Metadata_Block#unwrap). In the context of such a *user script*, the *special operator* [this](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/this) acts as *"the global object is passed as the context object"*, which behind the scenes is also linked to the `window` object, which is in turn a [XPCNativeWrapper](XPCNativeWrapper) wrapped version of [unsafeWindow](unsafeWindow) - the window of the *user script's* target page. 

 ### Debugging

 One consequence of being unable to access a *user script's global object* is that [debuggers and inspectors](Greasemonkey_Manual%3AOther_Useful_Tools) are unable to see anything in a *user script*. In order to inspect a data structure in the script's scope it can be temporarily added to `unsafeWindow`. e.g. `unsafeWindow.myScriptMyStruct = myStruct;`.

-With the [@unwrap](Greasemonkey_Manual:Metadata_Block#unwrap) header in place, you can export the whole global object in this fashion, which lets you inspect the whole running context of the script using such tools: 
+With the [@unwrap](Metadata_Block#unwrap) header in place, you can export the whole global object in this fashion, which lets you inspect the whole running context of the script using such tools: 

 ~~~~~~
 // ==UserScript==

Global_object modified by Martz

Martz — Sun, 10 Aug 2014 06:41:33 -0000

--- v1
+++ v2
@@ -1,51 +1,40 @@
 ## Overview

-In JavaScript, top-level functions and global variables are stored as properties of the [global object](http://developer.mozilla.org/en/JavaScript/Guide/Values,_Variables,_and_Literals#Global_Variables). For a script on a webpage, the global object is the page's [window](http://developer.mozilla.org/en/docs/DOM:window), and thus functions or variables like 
+In JavaScript, top-level functions and global variables are stored as properties of the [global object](http://developer.mozilla.org/en/JavaScript/Guide/Values,_Variables,_and_Literals#Global_Variables). For a script on a webpage, the global object is the page's [window](https://developer.mozilla.org/docs/Web/API/Window), and thus functions or variables like 

-    V = "V's value";
-    function F(){return "F's value"};
+~~~~~~
+V = "V's value";
+function F() {
+  return "F's value"
+};
+~~~~~~

+can be looked up through `window`. This gives the equivalences: 

-can be looked up through 
-    
-    window
+~~~~~~    
+(V == window.V) && (V == window['V'])
+(F == window.F) && (F == window['F'])
+~~~~~~    

-. This gives the equivalences: 
-    
-    (V == window.V) && (V == window['V'])
-    (F == window.F) && (F == window['F'])
-    
+A Greasemonkey [User script](User_script), however, by default wraps up all code inside an anonymous function wrapper that swallows identifiers, causing them not to end up on the global object. The useful effect of this wrapper is to protect user scripts from global identifiers in the Greasemonkey sandbox that might otherwise collide with yours and make it not work *(yielding unhelpful errors such as "invalid value")*.

-A Greasemonkey [User_script], however, by default wraps up all code inside an anonymous function wrapper that swallows identifiers, causing them not to end up on the global object. The useful effect of this wrapper is to protect user scripts from global identifiers in the Greasemonkey sandbox that might otherwise collide with yours and make it not work (yielding unhelpful errors such as "invalid value"). 
-
-Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#0.8.20080609.0) removed it and [0.8.1](Version_history#0.8.20090123.1) re-added it by default, unless the script wright disables it manually using [@unwrap](Greasemonkey_Manual:Metadata_Block#.40unwrap). In the context of such a _user script_, the _special operator_ [this](http://developer.mozilla.org/en/JavaScript/Reference/Operators/Special/this) acts as _"the global object is passed as the context object"_, which behind the scenes is also linked to the 
-    
-    window
-
-object, which is in turn a [XPCNativeWrapper] wrapped version of [UnsafeWindow] - the window of the _user script's_ target page. 
+Historically it was also a measure to not unwittingly pollute the window object. [0.8.0](Version_history#0.8.20080609.0) removed it and [0.8.1](Version_history#0.8.20090123.1) re-added it by default, unless the script wright disables it manually using [@unwrap](Greasemonkey_Manual:Metadata_Block#unwrap). In the context of such a *user script*, the *special operator* [this](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Operators/this) acts as *"the global object is passed as the context object"*, which behind the scenes is also linked to the `window` object, which is in turn a [XPCNativeWrapper](XPCNativeWrapper) wrapped version of [unsafeWindow](unsafeWindow) - the window of the *user script's* target page. 

 ### Debugging

-One consequence of being unable to access a _user script's_ _global object_ is that [debuggers and inspectors](Useful_Tools_for_Script_Writers) are unable to see anything in a _user script_. In order to inspect a data structure in the script's scope it can be temporarily added to 
-    
-    unsafeWindow
-
-. E.g.: 
-    
-    unsafeWindow.myScriptMyStruct = myStruct;
+One consequence of being unable to access a *user script's global object* is that [debuggers and inspectors](Greasemonkey_Manual%3AOther_Useful_Tools) are unable to see anything in a *user script*. In order to inspect a data structure in the script's scope it can be temporarily added to `unsafeWindow`. e.g. `unsafeWindow.myScriptMyStruct = myStruct;`.

-With the [@unwrap](Greasemonkey_Manual:Metadata_Block#.40unwrap) header in place, you can export the whole global object in this fashion, which lets you inspect the whole running context of the script using such tools: 
+With the [@unwrap](Greasemonkey_Manual:Metadata_Block#unwrap) header in place, you can export the whole global object in this fashion, which lets you inspect the whole running context of the script using such tools: 

-    // ==UserScript==
-    // ...
-    // @unwrap
-    // ==/UserScript==
+~~~~~~
+// ==UserScript==
+// ...
+// @unwrap
+// ==/UserScript==

-    unsafeWindow.myScript = this;
-    
+unsafeWindow.myScript = this;
+~~~~~~    

 **After debugging this sort of binding should be removed to avoid security and scope related problems.**
-
-[Category:Scripting_context]

Global_object modified by Martz

Martz — Fri, 27 Jun 2014 23:42:41 -0000

Overview

In JavaScript, top-level functions and global variables are stored as properties of the global object. For a script on a webpage, the global object is the page's window, and thus functions or variables like

V = "V's value";
function F(){return "F's value"};

can be looked up through

window

. This gives the equivalences:

(V == window.V) && (V == window['V'])
(F == window.F) && (F == window['F'])

A Greasemonkey [User_script], however, by default wraps up all code inside an anonymous function wrapper that swallows identifiers, causing them not to end up on the global object. The useful effect of this wrapper is to protect user scripts from global identifiers in the Greasemonkey sandbox that might otherwise collide with yours and make it not work (yielding unhelpful errors such as "invalid value").

Historically it was also a measure to not unwittingly pollute the window object. 0.8.0 removed it and 0.8.1 re-added it by default, unless the script wright disables it manually using @unwrap. In the context of such a user script, the special operator this acts as "the global object is passed as the context object", which behind the scenes is also linked to the

window

object, which is in turn a [XPCNativeWrapper] wrapped version of [UnsafeWindow] - the window of the user script's target page.

Debugging

One consequence of being unable to access a user script's global object is that debuggers and inspectors are unable to see anything in a user script. In order to inspect a data structure in the script's scope it can be temporarily added to

unsafeWindow

. E.g.:

unsafeWindow.myScriptMyStruct = myStruct;

With the @unwrap header in place, you can export the whole global object in this fashion, which lets you inspect the whole running context of the script using such tools:

// ==UserScript==
// ...
// @unwrap
// ==/UserScript==

unsafeWindow.myScript = this;

After debugging this sort of binding should be removed to avoid security and scope related problems.

[Category:Scripting_context]