On Tue Apr 30 19:10:03 2024 +0000, Gabriel Ivăncescu wrote:
I pushed new version to `jscript-proxies` that should address the suggestions. But it didn't change anything in the jscript object vtbl (for props I mean, not those interacting with mshtml). So for this MR, nothing changed at all.
That part looks better, thanks. FWIW, if QI itself would fit better in MSHTML, it could also be just passed back together with ID.
`PropOverride` still looks weird to have in the interface. Can't we use other functions for that? It's essentially a `GetPropInfo` combined with a getter call.
For calling the other way around, forwarding MSHTML `IDispatchEx` to jscript looks reasonable, but do you have some tests confirming it? Another approach would be to have them keep doing 'IE8' thing and use something entirely separate for JS. An example of a test distinguishing those approaches would be div element's `IDispatchEx` being able to query properties of `Element` and `Object` methods, respond to defining new ones (on prototypes) and deleting ones, something like that.
For enums, I didn't really mean a glue code, but to consider if we'd want to change it at the core. It would be great if you'd include the code required for proper external prototype support, that should answer a number of my questions.
Generally, jscript guarantees that if a property was exposed from given object once, a property of that name will always have the same dispid, even if it's removed and redefined. This is partially to make sure that callers `IDispatch` dispid caching works, but it's probably more than we really need to guarantee there.
Current jsdisp implementation depends on this strict behavior for correctness. That's what allows prototype reference to work like they do right now, but maintaining an invariant like this is not really convenient for MSHTML. It's not clear to me what's your plan here; you tweaked that for enum, but I'm afraid that for allowing MSHTML objects to be prototypes we may need to change it at the core.
Anyway, it's probably better to talk with a prototype, since you already have it implemented. I'd be mostly interested with minimal testable case, like a single MSHTML object with required interface and implementation changes. Could you please port something like that into the branch?
But it didn't change anything in the jscript object vtbl (for props I mean, not those interacting with mshtml). So for this MR, nothing changed at all.
Well, you put some glue code instead of changing jscript, so nothing changed. I really don't review this MR can be reviewed of the context. Most of comments about the interface apply to this internal interface as well. For example, I hope there is a better way than 'fixup' callbacks (even if it's not technically in this MR, that's what this MR leads to).
I think that the best way forward is to get the prototype into a better shape first. It would be great if you could get unneeded parts out of it. That includes typed arrays and a few other commits, I really hope that we can take care of MSHTML bindings first. Since we already started discussing it here, maybe it makes sense to push such stripped branch to this MR, rename it and mark as a draft? Or have a new draft, if you prefer?