On Fri Apr 26 12:13:08 2024 +0000, Jacek Caban wrote:
If "this" object is not MSHTML object, then we know that it doesn't implement the required interface and we throw an appropriate error. The code from your example should fail, unless I'm missing something. It's really the same: it would get the default "this" handling, which means that "this" object doesn't implement the required interface. (That code could work in older compat modes, where functions were tied to object instances, but it's a very different semantics and not interesting for the interface). For `IID`, it seems to me that the first step would be to replace `proxy_func_invoker` with just `IID`, you already have `DISPID` anyway. And yes, for `prop_fixup` I meant something like that. It may be more convenient to have an ID-based variant (instead of name lookup), possibly not, I'm not sure.
OK, I see what you mean with the IID. I didn't think of it, because I thought of delegating everything to mshtml (which already queries the IID and returns appropriate error) and making a generic interface for jscript so that it won't care of also checking it, but if you're ok with that I can try to squash the interfaces.
For the lookup, we need name-based lookup unfortunately because that's the whole point of the fixup (and override): such props may not have existed before, so what would the ID even be?
That said, I'm not sure either of these have to do with this MR, I mean "prop_fixup" itself is not tied to the fixup on the mshtml side (which can have a different interface later), but it's for jscript code itself. Anything in particular wrong with the interfaces in this MR? Or something you'd rather have done differently?
Even if we change PropFixup to PropGetInfo, I don't think it will change the jscript side for this MR.