Well unfortunately it looks like I'll have to look into the prototypes implementation somehow, as they are expected in practice as well by scripts. For IE9 and above, quick testing shows that all objects with the name [object X] (where X is the name) have an equivalent constructor literally called X and is even available from the js code (e.g. prototype.js uses window.Event.prototype to get the __proto__ for all events, since window.Event is the constructor of all events). Such prototypes are called [object XPrototype]. So I guess I'll rethink this a bit. Hopefully I find a way to synthesize the constructors with dynamic code from their names, because I would really like to avoid having to create separate constructors for every single object manually and duplicating so much code in mshtml.
IE8 is a special case. It doesn't support "js-like objects" (with proxies in my impl), but it does have an artificial "prototype" property for all objects, just like builtin functions have artificial "apply" and "call" methods, which try to emulate javascript behavior but are *not* javascript objects or the actual javascript builtin props at all. Which is fine, because they don't use proxies. The IE8 objects are based on the IHTMLDOMConstructorCollection interface and its props—that's all it exposes. Note that all builtin object prototypes are probably the same since they all report [Interface prototype object] for IE8 mode. Anyway I'll leave IE8 aside for the moment.
For IE7 and below modes nothing needs to be changed since the current behavior (not supporting prototypes at all) is correct. It does have 4 constructors (we already have them special cased) like Image and XMLHttpRequest, but those are implemented.
Please feel free to offer suggestions here, if I missed anything. Even just things to check for.
Anyway, since these mshtml proxies are basically acting like jsdisps, and will become even more different now than normal dispatch objects due to the constructors/prototypes (for reference, IE8 and below use normal dispatch objects, which is why they work so differently than jsdisps), I still think it's not a good idea at all to somehow make them use the same code path. In fact, the proxies use the jsdisp code path for the most part, with only a few exceptions, and PROP_PROXY for proxy props (but still within jsdisp codepath; the jsdisp fields usage is the same). This is completely unlike dispatch objects which must use a completely different code path, as it is now, because of how they work, and we have tests for that (especially for normal jscript code, not mshtml related). IMO, keeping the current dispatch-object behavior is needed to be correct for anything other than ES5 and up.
In the meantime, I'll probably try to upstream some other patches I got, that shouldn't be dependent on proxies, that implement some other missing stuff that will be needed for later anyway. Hope that's fine.
BTW I fixed the Proxy Functions and now work with compatible objects as you mentioned, with tests added. I don't store the IID on jscript side, though. I retrieve the mshtml func_disp and store it, and forward to its simulated "call" prop (I moved that patch that implements it earlier, which is needed anyway for IE8 and below), so all the IID checks are done on mshtml side, which is neat and avoids duplication/exposing details, and works across all modes (as tested to).
Thanks, Gabriel