<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 12/5/21 5:54 PM, Gabriel Ivăncescu
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:fb5d7a95-e549-f9f1-f32d-40ecfb4e7aac@gmail.com">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;"><br>
</blockquote>
<br>
<br>
This seems to be a good place to call the hook, but
could you just keep typeinfo_invoke call here and don't
expose invoke_builtin_function?
<br>
<br>
<br>
</blockquote>
<br>
But I need to expose it for hooks so they can forward to
it. It's either that or I expose typeinfo_invoke. Keep in
mind that, for hooks, the Dispatch object itself may not
exist at all, we can't use it to look up the function,
that's incorrect.
<br>
<br>
That's not the case right now, no, but it will be when
I'll either implement function.apply/call (for all modes)
or the proxy jscript implementation, in further patches.
<br>
<br>
Here's a future example:
<br>
<br>
f = elem.setAttribute;
<br>
f.call(some_other_obj, "a", blah);
<br>
<br>
The hook needs to run on some_other_obj and stringify blah
appropriately before calling the builtin function on
some_other_obj. In fact, we won't have a DispatchEx at
all, just a generic IDispatch with "some_other_obj". </blockquote>
<br>
<br>
I hoped that the result of your 'proxy' patches will be that
those functions will be true JavaScript objects. It means
that MSHTML's function objects will not be relevant in ES5
mode. Why do you still need them?
<br>
>
<br>
</blockquote>
<br>
Yes, that's true, but I need a way to encapsulate a builtin
function (including its hook) into a jscript function.
Currently, I create a ProxyFunction that holds the func_info
opaque pointer and an internal interface pointer that it uses
to call into mshtml.
<br>
<br>
mshtml then uses this entry point to call the hook first,
passing it the func_info and the 'this' dispatch object, and
if no hook reverts back to invoke_builtin_function. Of course
the hook also has to use invoke_builtin_function at some
point, after massaging the args.
<br>
<br>
Either way, the point is that the hook <b
class="moz-txt-star"><span class="moz-txt-tag">*</span>has<span
class="moz-txt-tag">*</span></b> to be called on an
arbitrary object, not the original dispatch it's from, so
that's why I'm passing func_info_t to it, which is needed to
be forwarded into invoke_builtin_function (or another
wrapper).
<br>
</blockquote>
<br>
<br>
I don't think we need that internal interface pointer. Did you
consider something similar to storing a builtin function as
(IID,DISPID) like I suggested earlier? This would not need any
object representing functions on MSHTML side.
<br>
<br>
</blockquote>
<br>
Yes, I had it that way, but I had to change it to handle hooks. I
don't actually use any object though, so it's not a problem. I
just give the func_info_t as an opaque pointer to jscript, and a
function pointer so that it knows what to call (in
ProxyFunction_call) and pass it there.
<br>
<br>
The function pointer points to a function in mshtml that simply
does the necessary things (typically, just invokes
invoke_builtin_function, or for accessors, builtin_propget/put and
the hooks). No actual object is used, but I still need the hooks
patch of course.
</blockquote>
<p><br>
</p>
<p>I still don't see why you need that. IID is enough to make sure
that we're trying to call the function on the right object type.
Once we know that the object type is right, DISPID already
uniquely identifies func_info_t, which MSHTML may get as needed
when the function is called.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Jacek<br>
</p>
</body>
</html>