Jacek Caban commented on a discussion on dlls/jscript/jsutils.c: https://gitlab.winehq.org/wine/wine/-/merge_requests/7425#note_96014
hres =IWineJSDispatchHost_GetJSDispatch(disp_host, &jsdisp_iface); IWineJSDispatchHost_Release(disp_host); if(SUCCEEDED(hres)) {
jsdisp_t *jsdisp = as_jsdisp((IDispatch*)jsdisp_iface);
if(jsdisp->ctx == ctx) {*r = jsval_obj(jsdisp);return S_OK;}else {jsdisp_release(jsdisp);}
*r = jsval_obj(as_jsdisp((IDispatch*)jsdisp_iface));
return S_OK;I can try to add a test, but it's obviously wrong the way it is now (see below).
Sure, the direction is clear. In this case it's not a question what Windows does, but to make sure Wine works properly and avoid regressions in the future.
Either way, I don't think the fix for lack of context propagation should be done here, it feels like it's unrelated and a bit of a hack, even if it's missing (the propagation).
Well, `IDispatchEx` code path gets it right, so it would be a regression.
Wait, how would it be a regression? The important parts (that end up in Invoke) will still end up through the IDispatch since they have different contexts. I don't see why mshtml objects (that should be jsdisps) should be treated differently than "native" jscript objects?
It's not like making them jsdisps will forcefully ignore the ctx checks and always end up in the jsdisp code path. Those will still be done where necessary, just like for generic jscript objects.