Hi again,
Well, this has turned into quite an investigation. Our findings:
This exposes
Good luck!
Well, this has turned into quite an investigation. Our findings:
- The MSHTML/JScript
windowobject requires that callbacks be recognizable as JScript functions, not simplyIDispatchExinstances. Contrary to earlier findings, legacy JScript and pre-Edge Chakra have identical requirements in this area, although they don't seem to recognize each other's functions. Interestingly, functions belonging to other instances of the same script engine are apparently permitted.
- Your change in HostItem.cs assumes that
window(actually any COM object) can be treated as a script object belonging to the current script engine. This enables your callback scenario by tricking ClearScript into givingwindowdirect access to the callback. That is, when your script issues a call such aswindow.setTimeout(callback), ClearScript observes thatwindowandcallbackare script objects belonging to the same script engine and concludes that no proxy is required. The resulting proxy-free (direct) access allowswindowto recognizecallbackas a JScript function.
-
While it enables your scenario, your change in HostItem.cs is generally incorrect. Most COM objects are not script objects; in fact, most script engines don't support COM at all. In this particular case,
windowis a COM object, and it is natively compatible with your script engine (Chakra), but there's no way for ClearScript to detect that or to determine that direct access is actually desirable. Only the application has that knowledge.
HostItemFlags.DirectAccess (commit). Here's how you might use it in your BHO:
engine.AddHostObject("window", HostItemFlags.GlobalMembers | HostItemFlags.DirectAccess, window);window for script access that bypasses ClearScript completely. It should yield better performance, and all callbacks should work. Give it a try. You'll still need your other modifications that enable Chakra support within ClearScript.Good luck!