Fixing instanceof (Array.isArray() etc.)?

Andrea Giammarchi andrea.giammarchi at
Sat Jan 21 07:49:35 PST 2012

with postMessage and other standard/secure ways to pass data around the
cross frame problem is slowly disappearing unless it's meant to sandbox the
Array, as example, of that frame.

A classic example is indeed the freedom to extend the way we like a
sandboxed Array which hopefully will never interferes with others defined
elsewhere, either Array public static methods or those attached to the

If I define Array.prototype.doMyStuff in my frame I *don't* want to affect
external environment anyhow plus if the top frame performs an instanceof
check against my Array, and the result is true, I may expect that frame to
execute my doStuff method which may points to sandboxed, private,
properties I don't want other frames to access or change in untrusted code.

Array.isArray is OK for Array like objects so that we know that common
operation are allowed while instanceof should act exactly as it does now so
no confusion cross frame will be possible.

Same function/constructor in two different worlds aren't same thing because
of the different surrounding world ... same is for Array.isArray unable to
grant that object is inheriting the prototype I have enriched in that frame.

If I want to be sure an Array comes from my world, instanceof is what I
need ... if I want to be sure I can use at least native methods in a
generic Array with unknown origin, Array.isArray is the way to go.

If instanceof acts like Array.isArray we'll end up with less control and
more error prone logic in our applications.


On Fri, Jan 20, 2012 at 7:28 PM, Herby Vojčík <herby at> wrote:

> Axel Rauschmayer wrote:
>> This JavaScript pitfall is still mind-boggling to me. It is clear what
>> happens (each frame has a different copy of Array etc.), but I find it
>> hard to wrap my mind around the consequences in practice. Is there a
>> plan on how to make this less painful in the long run? Initially, a
>> cross-frame version of instanceof might help (as opposed to
>> Function.isFunction, Date.isDate, RegExp.isRegexp etc.).
> Inspired by Smalltalk messages like #isInteger (defined in Object as
> returning false, defined in Integer as returning true) one possible
> solution would be to use variation of it. Its problem (or advantage, as one
> sees at it) is that it is designed for overwriting and possibility have
> forest, not only tree of objects that return isXxx as true; the is, for
> duck-typing. But if recent discussion of read-only inheritance proves true,
> then it can be protected by defining isArray property on (every)
> Object.prototype as non-writable, non-configurable, value:false, and
> similar one with value:true on (every) Array.prototype so one can not
> shadow it by mere assignment, but only by (explicit or implicit)
> defineProperty.
> From the point of security, it is probably too liberal. :-(
>> --
>> Dr. Axel Rauschmayer
>> axel at <mailto:axel at>
> Herby
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list