`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.
Well the thing is it only applies to specific objects, and must return S_FALSE otherwise so we know it doesn't. Not sure how to fit that in existing functions without over-engineering them? I could make a function that returns a BOOL like `OverridesProps` but that's just replacing it with another…
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.
Not sure if we have a test (or how to test it?), but native **does not** use the fixed DISPIDs in IE9+ like in IE8 and below, which suggests that it does something similar to my approach. See `test_elem_GetIDsOfNames` in `tests/dom.c` comment; feel free to remove that check and watch it fail. Obviously I can't test for fixed DISPID that's why I skipped it…
There is also `test_doc_obj` in `tests/events.c` with the comment and following test at `Navigate to a different document mode page`, where we test `importNode`'s DISPID, and it's not fixed.
In my case we guarantee the DISPIDs are the same for the given name, just not across different objects, but on the same object. Isn't that enough? It is the same as jscript. Two jscript objects, even if they're the same object "type", will likely have different DISPIDs for the same name. The only thing we don't guarantee is their "fixed" DISPIDs but that's already the case on native in IE9+.
I don't really understand what you mean by enums. Right now it's basically just doing what jscript does, filling the props, except instead of jscript builtins it's mshtml builtins (which end up as proxies, either functions, accessors or PROP_PROXY). It works the same way, there's zero changes needed for prototypes. We have a new method to deal with it because we have to bypass the normal `GetNextDispID` since that would call back into us, just like e.g. PropInvoke vs InvokeEx.
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?
Sorry, I don't understand what you mean here. Wouldn't special casing one object be worse, because it would include extra checks/code (generic is easier, it applies to all DispatchEx on mshtml side), **and** there's no guarantee that it would cover all cases, which is the main point isn't it? If we didn't have objects like `localStorage` then all this override/fixup wouldn't have been needed. Tbh I'm not even sure how to begin special casing just one object.
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).
Unfortunately I can't see a better way, since there's no way even for mshtml code to know when some underlying storage changed for those objects (no callbacks or anything). We already fixup the PROP_PROTREFs so I thought reusing that would make it more acceptable.
The other concerns, like forwarding calls to jscript, DISPIDs, and so on, I don't see how they're relevant to this MR? I prefer doing it a bit at a time instead of all at once.
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?
I can, but this is a lot more work than Typed Arrays, so I wanted to get those in first so it doesn't keep piling up. Note that I haven't split it up yet, and I want to get it in acceptable shape somewhat first because re-writing it constantly if it's split up becomes a nightmare.
Though Typed Arrays don't really affect this much, they do show that they are enough for the current jscript prop methods in the vtbl, isn't that enough for this MR?
Are you sure you don't want to review this MR as-is so I can get those in first? "fixup" may not be good, but it's not part of this MR as noted, and so if we find a better way later it wouldn't affect this MR.
The other methods are totally justified for non-mshtml cases so we need them regardless of what happens with mshtml bindings.