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
window
object requires that callbacks be recognizable as JScript functions, not simplyIDispatchEx
instances. 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 givingwindow
direct access to the callback. That is, when your script issues a call such aswindow.setTimeout(callback)
, ClearScript observes thatwindow
andcallback
are script objects belonging to the same script engine and concludes that no proxy is required. The resulting proxy-free (direct) access allowswindow
to recognizecallback
as 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,
window
is 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!