[PATCH v2 1/8] jscript: Implement proxy objects along with a private interface.

[Gabriel Ivăncescu]

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