DOM.requestNode returns 0

[lsim]

I have my own dom traversal function window.pathSelector defined in the page, which I want to use from C# via the devtools protocol. The aim is to locate a file input and set its value programmatically.

cwv2 is a fully initialized CoreWebView2 instance.

        var protocolHelper = cwv2.GetDevToolsProtocolHelper();

        var objectId = (await protocolHelper.Runtime.EvaluateAsync($"window.pathSelector('{path}')")).Result.ObjectId;

        var nodeId = await protocolHelper.DOM.RequestNodeAsync(objectId);

        if (nodeId == 0) throw new Exception("DOM.requestNode failed (returned 0)");

        await protocolHelper.DOM.SetFileInputFilesAsync(files.Select(s => s.Replace('\\', '/')).ToArray(), nodeId);

The problem I have is that nodeId is always 0. Does anyone know why that is? objectId appears to be a valid value

I have struggled to put the above together and there is definitely the possibility that I have misunderstood something fundamental.

I have tried calling EnableAsync for Runtime and DOM respectively but no joy. From what I can gather those are mainly for event processing anyway.

Here's hoping someone can help me figure this out.

[lsim]

A bit further experimentation revealed that I was indeed being silly. I can programmatically set the file input as follows (given the same preconditions as the sample above):

        var protocolHelper = cwv2.GetDevToolsProtocolHelper();

        var objectId = (await protocolHelper.Runtime.EvaluateAsync($"window.pathSelector('{path}')")).Result.ObjectId;

        await protocolHelper.DOM.SetFileInputFilesAsync(files.Select(s => s.Replace('\\', '/')).ToArray(), null, null, objectId);

I still don't know why the call to DOM.RequestNodeAsync doesn't return a valid nodeId, but thankfully I don't presently need it to. I guess I'll leave this ticket open in case there's a bug that needs fixing.

[lsim]

I should perhaps add that I saw the same problem before I discovered the lovely DevToolsProtocolHelper package, so it doesn't seem like the problem is in there.

[victorhuangwq]

Are you still facing this issue?

[lsim]

No, I worked around it - but I never found an explanation for the observed behavior.