You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.NET libraries are increasingly moving to Async implementations. Selenium should move over to be a completely Asynchronous library, especially since we plan to implement current methods with BiDi that have to be Async.
It is possible to maintain backwards compatibility by implementing existing Synchronous methods by calling the Async methods wrapped in a Run Task, but this doubles the API surface, and is not best practice.
Proposal
Add Async methods to all classes
Rewrite Sync methods to use the Async methods
Write Blog Post talking about the proposed changes
Mark all Sync methods as deprecated
#14051 is an example of doing the first 2 items for the Navigation methods
Question:
Do we want to remove Sync methods for Selenium 5, knowing that Selenium 5 will be backwards incompatible with current Selenium code, or maintain both through Selenium 6?
I'm not sure which major version is better for removing sync API, but I think for WebDriver consumers, after adding async APIs, it will be good to keep deprecated (marked [Obsolete]) sync APIs for at least 3 minor version releases before removing. We'll need some time for such an upgrade.
Are there any plans for the properties that call Sync methods?
Ex: The Title property in WebDriver executes a driver command inside of a getter instead of providing a method. If a GetTitleAsync method were to be added, would a GetTitle method also be added and the property removed/deprecated?
Edit: another thing that would need to be considered is the constructors. Ex: the WebDriver constructor calls StartSession which executes a driver command but the constructor cannot be made async.
Feature and motivation
.NET libraries are increasingly moving to Async implementations. Selenium should move over to be a completely Asynchronous library, especially since we plan to implement current methods with BiDi that have to be Async.
It is possible to maintain backwards compatibility by implementing existing Synchronous methods by calling the Async methods wrapped in a Run Task, but this doubles the API surface, and is not best practice.
Proposal
#14051 is an example of doing the first 2 items for the Navigation methods
Question:
attn: @jimevans / @nvborisenko / @YevgeniyShunevych
Usage example
The text was updated successfully, but these errors were encountered: