Skip to content

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

Open
@nvborisenko

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-needs decisionTLC needs to discuss and agreeB-devtoolsIncludes everything BiDi or Chrome DevTools relatedC-dotnet.NET BindingsI-enhancementSomething could be better

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions