On Fri May 10 17:20:07 2024 +0000, Gabriel Ivăncescu wrote:
I tried hard to reproduce what you meant but it doesn't seem to be possible? I mean, if o.async1 disappears, it doesn't mean the DISPID disappears. It just becomes PROP_DELETED on jscript or equivalent. Obviously it disappears from the jscript code's perspective, but not when querying the DISPID, the name is still "stored" in the object's props. Am I missing something? I'm just using jscript's facility here. If you mean the "override" rather than the "fixup", then it's done on *existing props* so still have the same DISPID, although it's looked up via name on mshtml side but that's purely implementation detail, since mshtml doesn't know about jscript's DISPID (I guess it could be possible to obtain the name from DISPID via GetMemberName or the like but why complicate it when we can pass the name?). In short: the prop "fixup" doesn't fixup the name, but rather the prop's value/contents (or deletes the prop). But deleted props don't delete the name—and DISPIDs are associated with the name, not the contents of the prop. So:
x = o.async1 // ... x = o.async1First one let's say creates the async1 prop. Then it gets deleted on the file. jscript doesn't know this of course. Next time we obtain it, it's actually deleted, so it returns "undefined". But note that this is done in the getter, which already has the DISPID—the same DISPID as previously. Unless I'm missing something? Maybe I'm testing it wrong.
`o`'s dispid points to a protocol reference, which references the prototype's property by dispid. The prototype reference is never removed in my example (only the property in the prototype, but `o` wouldn't know about it even if it wasn't an "async" property), it would still forward to the prototype, but potentially using a wrong dispid now.