Feature request: a window option to run that window in Node's context

[Mithgol]

Different windows of a node-webkit's application have different JavaScript contexts; each window has its own global object and its own set of global constructors (such as Array or Object).

It's generally a good thing because when an object's prototype is replaced or augmented by a library (such as Prototype) or a simpler script, the analogous objects in other windows are unaffected nevertheless. Otherwise bugs could affect larger areas (several windows), malicious applications could access confidential data structures, etc.

And Node modules in node-webkit run in their own shared Node context for the same reason.

Such difference in contexts is generally benefitial, but sometimes it comes with a price. For example, a simple check such as value instanceof Array cannot determine if a variable's value belongs to one of the standard classes if it's passed from another context and had another object as its ancestor (see “Determining with absolute accuracy whether or not a JavaScript object is an array” for details).

Several issues of the past (#702, #716, #832) were caused by this difference of contexts and object inheritance.

That's why, for such special cases, I have to request an option for the window section of node-webkit's manifest (and thus for the options parameter in Window.open()).

That option should be false by default. If set to true, it should cause the corresponding window to run in the Node context (the same context that all Node code share).

The following Node.js globals should also become the globals (i.e. properties of the global object) in such window:

• Standard object types: Array, Boolean, Date, Function, Number, Object, RegExp, String.
• Typed array types: ArrayBuffer, DataView, Float32Array, Float64Array, Int16Array, Int32Array, Int8Array, Uint16Array, Uint32Array, Uint8Array.
• Error types: Error, EvalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError.

It is important to maintain [].constructor === Array and ({}).constructor === Object in that window, otherwise unobvious bugs would arise from using the most simple language constructs.

The name for such option could be nodeglobals or something similar.

The current workaround is using my nwglobal module. However, neither [].constructor === Array nor ({}).constructor === Object could be achieved with this workaround, so the real implementation of the requested feature should probably touch some deeper level of objects' structure of inheritance.

[gpetrov]

Maybe this will be solved easily with the new node 0.12 multi-context feature?

See http://strongloop.com/strongblog/whats-new-node-js-v0-12-multiple-context-execution/

[rogerwang]

merge with #3107 . will deal with this in nw13. Thanks.