On Mon Aug 24 20:29:01 2026 +0000, Gabriel Ivăncescu wrote:
Sorry I don't quite understand what you mean. In the generic case, this code basically retrieves a participant and an object from an input raw object. Raw object meaning it can be anything (even pure gecko external object), not ours. But at the same time, it should return the jsdisp if it's a host object with a jsdisp, so that the caller (our jscript) can special case it. This is necessary because we don't place jsdisps into the "cc map", even if they're host objects (and thus have a mshtml host object tied to them). And this is necessary because we have to traverse their jsdisp props and that's something only jscript can do (implementation detail). If I just gave them a custom participant, how would jscript be able to know they're jsdisps and/or retrieve the jsdisp? In summary how the traversal works at a glance for the 3 "types" of objects: * Pure jsdisps are traversed just like before, and their speculative refcount is (temporarily) stored in their ref field. * HostObject jsdisps are treated specially; their speculative refcount is still stored in their (unused) ref field of jsdisp, and they are traversed like pure jsdisps for the jsdisp props, but additionally having their "host side" traversal also done (this is in ADDITION to the jsdisp traversal). (the ref field is unused since we defer it to the mshtml host object, so it's perfectly usable for the GC) * Raw XPCOM objects (e.g. pure gecko objects) are placed in the cc map, and their ref is stored there. These are the only objects for which we need a participant. I mean I could add a custom QI IID that doesn't AddRef just like Gecko does, and then obtain the jsdisp from that if you prefer...? Like a custom interface that just has one method "GetJSDisp" or something along those lines and doesn't AddRef because it *cannot* AddRef while a traversal is happening (this is a Gecko thing, this is why its two QIs there don't AddRef and are also special). Yes, I think that something similar to Gecko would be better as it naturally goes through vtbls without any special-casing like this. If all you need is jsdisp, you could just return `IWineJSDispatch` similar to how `IID_nsCycleCollectionISupports` works, there is no need for an actual new interface, just IID. (If some more abstraction is needed, then an additional static object could be used like `IID_nsXPCOMCycleCollectionParticipant` does.)
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10045#note_149790