On Fri May 10 19:38:37 2024 +0000, Jacek Caban wrote:
`o`'s dispid points to a protocol reference
I meant prototype reference.
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)