Array methods should respect the realm of the `this`.

[jdalton]

For example see step 9 of this https://people.mozilla.org/~jorendorff/es6-draft.html#sec-array.prototype.filter

var i = document.createElement('iframe');
i.name = 'iframe';
i.style.display = 'none';
document.body.insertBefore(i, document.body.firstChild);

var f = frames.iframe;
f.document.write('<script><\/script>');
f.document.close();

var otherArray = f.Array(1,2,3);
var sliced = Array.prototype.slice.call(otherArray, 2);

console.log(sliced instanceof Array);  // should be `false`
console.log(sliced instanceof f.Array); // should be `true`

[ljharb]

Is there any way to test this without an iframe (in node)? The spec specifies "exotic Array object" only - is an Array from another iframe exotic?

[domenic]

Realms are a red herring. Subclasses are the more interesting case where consulting this.constructor matters.

[jdalton]

Is there any way to test this without an iframe (in node)?

Yap, you can use require('vm').

[jdalton]

There's the perf side to consider; wrapping all those methods would be hella bad for that. Maybe this is one that es6-shim opts out of and just documents the lack of support.

[ljharb]

Indeed, that's one of my main concerns. At the least, we can ensure that our actual shims do the right thing, even if we choose not to detect and override every existing Array method :-)

[Yaffle]

Array.prototype.map.call(document.querySelectorAll("*"), function (e) {
  return e.tagName;
});

am i right, that this code should throw error (because NodeList is not constructable) according to spec?

[domenic]

@Yaffle yes, I believe so.

[Yaffle]

seems, this was discussed here: https://esdiscuss.org/topic/array-prototype-slice-web-compat-issue#content-17 OK, i am not using Array.prototype.map for NodeLists anyway, so I am fine with it.

[ljharb]

Wow, that's a shame, that's a really common existing pattern.