[🚀 Feature]: [dotnet] Provide a possibility to implement BiDi Permissions module

[nvborisenko]

Feature and motivation

https://www.w3.org/TR/permissions/

The implementation should not rely on internal members. The goal is to expose minimal required to make it possible to implement new extendable by the third-partied modules.

Usage example

var bidi = await driver.AsBiDiAsync(); // selenium responsibility

// straightforward API (not yet approved)
var permissionsModule = new PermissionsModule(bidi);

// or as extension to emphasize this is extension
var permissionsModule = bidi.AsPermissions();

await permissionsModule.QueryAsync();

[github-actions]

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[nvborisenko]

I am thinking more about it and coming to a conclusion that "reusing" existing BiDi connection is "not possible". JsonSerializerContext is immutable, reading it as third-party module should initialize his own connection (Broker) providing described json context.

So, I think the following will be more appreciated:

var bidi = await driver.AsBiDiAsync(); // W3C WebDriver implementation

var permissions = await driver.AsBiDiPermissionsAsync(); // It initializes new Broker/WebSocketConnection/JsonContext

Then each bidi and permissions are isolated, and both have own "context" including everything needed to deal with remote end (still immutable). The trick is that remote end send data (responses/events) per WebSocketConnection.

I think this is a good solution. But semantic of this solution is not related to extensibility.

[nvborisenko]

But semantic of this solution is not related to extensibility.

And I am entirely OK with it! Permissions module can be easily implemented (defining his own DTO types), Bluetooth module too.

Appium is a separate topic, but seems yes, we consider Appium as yet another BiDi module (with his own isolated "context").