I'm very proud to announce the 4.0-alpha2 release of the Selenium .NET bindings! There are several exciting things to look forward to in this release. The first is the fixing of several issues that have cropped up because beginning with version 75, Chrome (and ChromeDriver) now use the W3C WebDriver Specification as the default protocol dialect for communication between Selenium and the driver. This has led to a few issues like the loggingPrefs capability being renamed, and the legacy logging APIs (driver.Manage().Logs) no longer working. This functionality should be restored in this release.
By far, the biggest addition to this release of the .NET bindings is the addition of integration with the Chrome DevTools Protocol (CDP). We are extremely excited to be able to bring this feature to users of Selenium. It allows users, using their existing WebDriver instance, to instantiate and use a CDP session, including the two-way communication of events. The .NET API for using CDP is still experimental, and may change between releases until the alpha/beta period is over. But to whet your appetite, here's what code to use this looks like in 4.0.0-alpha02:
The API uses the .NET System.Net.WebSockets.ClientWebSocket implementation for communication with Chrome, which means it's limited to use with Windows 8.1 and above. This is a limitation of the WebSocket implementation, so complaints about that should be directed toward Microsoft. Accordingly, most of the CDP API is async, though the remainder of the WebDriver API is not.
Also, for the moment, the .NET bindings do not implement domains marked as "experimental" in the protocol definition. One thing that we really do not want for Selenium is for it to be tied down to specific versions of Chrome. Since the DevTools Protocol is not subject to any standard, and can be changed at the whim of the Chromium developers, this seems like a potentially suboptimal solution if we do that.
The CDP integration is something we'd really like to get feedback on, so give it a whirl, and let us know what you think.
By far, the biggest addition to this release of the .NET bindings is the addition of integration with the Chrome DevTools Protocol (CDP). We are extremely excited to be able to bring this feature to users of Selenium. It allows users, using their existing WebDriver instance, to instantiate and use a CDP session, including the two-way communication of events. The .NET API for using CDP is still experimental, and may change between releases until the alpha/beta period is over. But to whet your appetite, here's what code to use this looks like in 4.0.0-alpha02:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
IWebDriver driver = new ChromeDriver(); | |
// Cast to role-based interface without throwing exception. | |
IDevTools devTools = driver as IDevTools; | |
if (devTools == null) | |
{ | |
throw new Exception("Driver instance does not support CDP integration"); | |
} | |
DevToolsSession session = devTools.CreateDevToolsSession(); | |
string expected = "Hello Selenium"; | |
string actual = string.Empty; | |
// Two things to note here. First, use a synchronization | |
// object allow us to wait for the event to fire. Second, | |
// we set up an EventHandler<T> instance so we can properly | |
// detach from the event once we're done. "Console" here | |
// is "OpenQA.Selenium.DevTools.Console". | |
ManualResetEventSlim sync = new ManualResetEventSlim(false); | |
EventHandler<Console.MessageAddedEventArgs> messageAddedHandler = (sender, e) => | |
{ | |
actual = e.Message.Text; | |
sync.Set(); | |
}; | |
// Attach the event handler | |
session.Console.MessageAdded += messageAddedHandler; | |
// Enable the Console CDP domain. Note this is an async API. | |
await session.Console.Enable(); | |
// Navigate to a page, and execute JavaScript to write to the console. | |
driver.Url = "http://jimevansmusic.blogspot.com"; | |
((IJavaScriptExecutor)driver).ExecuteScript("console.log('" + expected + "');"); | |
// Wait up to five seconds for the event to have fired. | |
sync.Wait(TimeSpan.FromSeconds(5)); | |
// Detach the event handler, and disable the Console domain. | |
session.Console.MessageAdded -= messageAddedHandler; | |
await session.Console.Disable(); | |
System.Console.WriteLine("Expected message: {0}", expected); | |
System.Console.WriteLine("Actual message: {0}", actual); | |
System.Console.WriteLine("Messages are equal: {0}", expected == actual); |
The API uses the .NET System.Net.WebSockets.ClientWebSocket implementation for communication with Chrome, which means it's limited to use with Windows 8.1 and above. This is a limitation of the WebSocket implementation, so complaints about that should be directed toward Microsoft. Accordingly, most of the CDP API is async, though the remainder of the WebDriver API is not.
Also, for the moment, the .NET bindings do not implement domains marked as "experimental" in the protocol definition. One thing that we really do not want for Selenium is for it to be tied down to specific versions of Chrome. Since the DevTools Protocol is not subject to any standard, and can be changed at the whim of the Chromium developers, this seems like a potentially suboptimal solution if we do that.
The CDP integration is something we'd really like to get feedback on, so give it a whirl, and let us know what you think.