On Sat May 11 17:42:25 2024 +0000, Gabriel Ivăncescu wrote:
Wait so let's break it down a bit. Are you talking about the DISPID on mshtml side (the "internal" prop on mshtml, e.g. dynamic prop or whatever), or the DISPID on jscript side? The DISPID on mshtml side is opaque to jscript, it's part of the proxy function/accessor/PROP_PROXY, but jscript doesn't really need to know about it. You can think of it as an opaque `void *context` so it shouldn't interfere with prototype lookup at all. Now if you mean the DISPID on jscript side, I can't reproduce what you describe. Let's say `o` has PROP_PROTREF that points to the async prop, let's say it's 42. The backing file then removes the prop on the prototype, so next time we "fixup" the prop we turn it (on the prototype) into PROP_DELETED. The PROP_PROTREF should then be fixed up whenever accessed just like normally via our fix_protref_prop, as we lookup where `42` points to and it's a PROP_DELETED now, so the PROP_PROTREF gets turned into a PROP_DELETED itself (except I've now moved it into a vtbl function so that proxy objects can override it). Note that prop_fixup on proxy objects should forward to the standard `dispex_prop_fixup` where necessary (to fixup PROTREF as mentioned), so this should be handled already. That PROTREF fixup was already a thing before this patch, actually it's a thing before this entire MR… It's not exclusive to async props. If I'm still misunderstanding, can you please provide a simple case that actually fails, no matter how hacky it is, I don't mind. It doesn't have to even use a mshtml object, just hack something so it "acts" like one? (actually that's how I've been trying to reproduce this, to no avail)
Ah, right, shadow dispids would take care of it. The `PROP_PROXY` thing is confusing to me, I'm not yet sure what to think about it. I thought that the point of this MR is to allow external properties to not need `dispex_prop_t` (just like jscript internal indexed props). I can see how some things are easier this way (through I feel like the same would be true for other parts if we didn't allocate those). It may be useful to allow "shadowing" properties for some cases, but for that a flag in `dispex_prop_t` could be enough, I'm not sure it needs a new property type. Did you consider something like that? Is it not feasible?