instanceof with multiple windows/iframes

[murzart]

Hey,
I experienced an issue with the raycaster, when using multiple windows/iframes.
In my case objects instanceof Array === false in intersectObjects failed.
Object.prototype.toString.call( objects ) !== '[object Array]' works as expected.

This effect is described here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof

[mrdoob]

Uh! Do you mind explaining a bit more what's happening?

[andre161292]

The problem with instanceof is, that every environment (every iframe, frame, window) has it's own internal classes (Array, Object, etc.). So if you have an environment, where var a is an Array, in the top environment, and you test for a instanceof iframe.contentWindow.Array, it returns false - and vice versa.

It's different for loaded scripts:
If you load the same library in both environments and test, for example, if a instanceof THREE.Texture and a instanceof iframe.contentWindow.THREE.Texture, it will return true for both expressions.

A good explanation can be found here: http://perfectionkills.com/instanceof-considered-harmful-or-how-to-write-a-robust-isarray/

[mrdoob]

If you load the same library in both environments and test, for example, if a instanceof THREE.Texture and a instanceof iframe.contentWindow.THREE.Texture, it will return true for both expressions.

And, isn't this the expected behaviour?

[mrdoob]

Oh wait. So you're trying to use the library that you're loading inside an iframe from outside?

[murzart]

Exactly. That's why instanceof Array isn't working as intended.

[mrdoob]

That's a very strange use case. I'm not sure the whole library should get more unreadable because strange use cases...

[thure]

The use of instanceof also precludes creating custom classes that have instances of any THREE classes as properties and using those instances with other classes that check type that way, the same principle discussed on SO.

e.g. If you have an arbitrary class Rain with a property Rain.mesh that's an instance of THREE.Object3D created during construction, you can't add it to a THREE.Scene that belongs to an instance of a different class because it fails the instanceof THREE.Object3D check, even though it was created with that constructor.

It'd make writing abstractions over THREE easier if type checking were less strict, i.e. compared an instance's type property instead of instanceof THREE.<class>, but I haven't looked into the negative consequences of making such a change.

[kumavis]

@mrdoob I agree that the particular usecase is uncommon, but the instanceof problem rears its head in a few different places. As @thure said, this problem makes it difficult for others to build modules/libraries on top of three.js and get them to play nice together (your object is not an instanceof my Object3D). Substack suggested using a feature-detection pattern instead to overcome this.

[mrdoob]

The consequences of not being so strict is (not forcing instanceof THREE.Object3D) is that avoiding breakage from version to version would be (even) more difficult. Changing to the API would be more tricky because users would be using it in ways I couldn't foresee and more people will get mad.

[kumavis]

Not making more people mad is a good motivation.

That said, I'm going to move away from this particular issue which is originally focused on

var iframe = document.getElementsByTagName('iframe')[0]
window.Array !== iframe.contentWindow.Array

However, shims for Array.isArray are readily available

[mrdoob]

As the original issue mainly referred Array I guess we can just use Array.isArray() instead?

[kumavis]

@mrdoob that sounds good to me
enable 'obsolete browsers' to get a better idea of compat on older browsers
http://kangax.github.io/compat-table/es5/#Array.isArray

[andre161292]

I think we're at cross-purposes. If the issue would only reffer to Arrays, this solution would be fine, but it isn't.
The main problem is, that we cannot identify, if a specific instance is the instance of a specific class of ThreeJS.

[mrdoob]

@andre161292 Doesn't your use case gets solved by just doing var THREE = window.contentWindow.THREE? from within the iframe?

[mrdoob]

Fixed!