[🚀 Feature]: [dotnet] [bidi] Expose BiDi to be truly public low-level API

[nvborisenko]

Description

Now we hide some BiDi API from users (via internal modifier) because we want to hide the complexity of its usage. Great example is network interception: this operation requires to phases: AddIntercept and Subscribe on events. So right now we provide useful API for users to guide them to do the interception properly.

From one point of view Selenium tries to help users, but from other hand the question is why Selenium hides some BiDi spec defined capabilities.

Solution

• Revisit all internal modifiers and make it public
• Move all "helpers/extensions" to OpenQA.Selenium.BiDi.Extensions namespace

Usage

Now user will get all power of spec defined methods. If user starts typing bidi.Network.interce he will be promoted to use:

• AddInterceptAsync native low-level method
• InterceptRequestAsync/InterceptResponseAsync extension methods safe to do the interception properly

Note

There is:

context.Network.IntercepRequestAsync()

If we choose extensions .net model, then properties cannot be extensions. I guess we can mitigate it via flatten methods from all modules, like:

context.InterceptRequestAsync()

It is even simpler, and it even removes extra class.

Have you considered any alternatives or workarounds?

No response

[selenium-ci]

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

Selenium Triage Team: remember to follow the Triage Guide

[nvborisenko]

I don't have arguments why low-level API should hide some methods. So decision will be just reveal it. Any hidden knowledge about its usage can be easily negotiated via documentation (for advanced users). In any case for us it means just follow BiDi spec without headache and hidden stones.