Operations not callable using AddRemoteObject

[Gordy-1]

Hi, operations not working with WebView2 AddRemoteObject API - Properties can be accessed but not operations.

• Remote object registered from C++ as per documentation examples
• Property get and set working
• All operation calls failing when called from JS (sync and async, with and without params)
• applyRemote to call operation also failing

Example JS call:
  chrome.webview.remoteObjects.sync.bridge.Func('param');
Error:
  Uncaught (in promise) Error: The parameter is incorrect. (0x80070057)
    at RemoteMessenger.postSyncRequestMessage (<anonymous>:1:9419)
    at Function.getRemote (<anonymous>:1:20998)
    at Function._getAmbiguous (<anonymous>:1:12818)
    at Object.get (<anonymous>:1:13978)
    at getProp (about:blank:16)

Environment:

• Com objects implemented in C# .NET Framework 4.8
• Edge-Chromium Version 79.0.309.71 (Official build) (64-bit)
• SDK version 0.8.355

[david-risney]

Hi thanks for letting us know about this issue! The HRESULT (0x80070057) should mean that the JS call made it to the native code and there was some sort of failure in invoking the IDispatch on the native side. What is the definition of the object you're calling into?

[Gordy-1]

Plain C# - so generated CCW I assume - The IDispatch I/F is obtained using Marshal.GetIDispatchForObject, then IntPtr is passed to unmanaged C++ code (same process) to register with AddRemoteObject. The C++ code can directly query/invoke using IDispatch::Invoke no problem. In the above test code, definiton is:

    [Guid("B7A5C4C9-F4DA-4CD3-8D01-F7F42512ED08")]
    [ClassInterface(ClassInterfaceType.AutoDual)]
    [ComVisible(true)]
    [ProgId("TestHarnessApp.Test")]
    public class BridgeObject
    {
        public string Func(string param)
        {
            return "Func called with param : " + param.ToString();
        }

[david-risney]

I haven't tried with .NET's IDispatch implementation. Perhaps our code isn't working well with that. Thanks for the bug report!

[RichardSteele]

The same happens with a VB6 (don't ask!) supplied COM object. Intercepting the call to IDispatch::Invoke, I see that in case of a method call wFlags is DISPATCH_PROPERTYGET instead of DISPATCH_METHOD.

[pontusn]

Sounds related to issues #144 and #147 that a I recently reported.

For ATL-based implementations I have a generic workaround that enabled us to continue integration work.

[pagoe-msft]

Hi @Gordy-1,

We have resolved this issue in our most recent SDK update.

https://review.docs.microsoft.com/en-us/microsoft-edge/hosting/webview2/releasenotes?branch=master#09488