Sebastian Mayr

> could you explain why do you use the expression dynamic objects? That's mainly because I'm not sure I wired this up correctly for regular schema configuration overlays, I only...

In that case feature detection wouldn't work anymore - you can also easily stub it in the `created` callback.

Sadly, prototype chains are screwed up due to sandboxing, which we can't really fix (without making jsdom a whole lot slower). The Object in the HTMLInputElement chain is the "real"...

``` > obj = input.__proto__.__proto__.__proto__.__proto__.__proto__.__proto__ {} > obj instanceof Object false > obj.constructor == Object true ``` It's uuuh... very weird.

Yeah, we've had this problem with a few other things, namely `/abc/ instanceof Regexp` and similiar things. Sadly the only thing we (or you, in the `created` callback) can do...

If you do that then `!({} instanceof Object)` which is really bad usually in JS. There's no real general solution here at the moment, it's all a tradeoff.

> It would not be hard to set it up that way, what's the problem? It would require setting up a whole new prototype chain for every jsdom window. `require('jsdom')`...

> Instead of sharing the global Object you could share a singleton window.Object. Yeah, that would also work. We thought about this a bit. By extending it to also overwrite...

hasInstance is a kinda shitty patch though, it just hides the problem a bit better. Walking the prototype chain would still not work for example. > or do you want...

Can't confirm, this seems to work pretty well, memory usage periodically drops back down to ~650MB: ```js const jsdom = require('.') function createWindow() { return new Promise((resolve, reject) => {...