[dotnet] Propagate async from navigation to tests

[RenderMichael]

User description

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Propagates async from navigation, with the exception of NavigationTests.cs (the tests which explicitly validate the sync behavior), and the IWebDriver.Url setter, because there are almost a thousand hits for this...

Motivation and Context

Minimizing sync-over-async is pure goodness. Additionally, It is an eventual goal to make Selenium an Async library: #14067

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

PR Type

Enhancement, Tests

---

Description

• Transitioned test methods to asynchronous implementations.

• Replaced synchronous navigation calls with asynchronous equivalents.

• Updated test signatures to support async/await patterns.

• Enhanced test reliability and alignment with modern .NET async practices.

---

Changes walkthrough 📝

Relevant files

Tests

9 files CookieImplementationTest.cs Converted cookie-related tests to async methods.                  +5/-4      DevToolsProfilerTest.cs Updated DevTools profiler tests to use async navigation.  +1/-1      ExecutingJavascriptTest.cs Refactored JavaScript execution tests for async navigation. +10/-10  NavigationTest.cs Transitioned navigation tests to async methods.                    +3/-3      NetworkInterceptionTests.cs Updated network interception tests to async navigation.    +1/-1      PageLoadingTest.cs Refactored page loading tests for async navigation.            +25/-22  PrintTest.cs Updated print tests to initialize with async navigation.  +3/-2      SlowLoadingPageTest.cs Converted slow-loading page tests to async methods.            +3/-2      FirefoxDriverTest.cs Refactored Firefox driver tests for async addon handling. +11/-10

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 14067 - Partially compliant Compliant requirements: Add Async methods to all classes (for navigation methods) Rewrite Sync methods to use the Async methods (for navigation methods) Non-compliant requirements: Write Blog Post about proposed changes Mark all Sync methods as deprecated

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 PR contains tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Async Validation Ensure that async operations are properly awaited and that test timeouts are adjusted appropriately for async execution private void TestPageLoadTimeoutIsEnforced(long webDriverPageLoadTimeoutInSeconds) { // Test page will load this many seconds longer than WD pageLoadTimeout. long pageLoadTimeBufferInSeconds = 10; string slowLoadingPageUrl = EnvironmentManager.Instance.UrlBuilder.WhereIs("sleep?time=" + (webDriverPageLoadTimeoutInSeconds + pageLoadTimeBufferInSeconds)); driver.Manage().Timeouts().PageLoad = TimeSpan.FromSeconds(webDriverPageLoadTimeoutInSeconds); AssertPageLoadTimeoutIsEnforced(async () => await driver.Navigate().GoToUrlAsync(slowLoadingPageUrl), webDriverPageLoadTimeoutInSeconds, pageLoadTimeBufferInSeconds); } private void AssertPageLoadTimeoutIsEnforced(AsyncTestDelegate delegateToTest, long webDriverPageLoadTimeoutInSeconds, long pageLoadTimeBufferInSeconds) { DateTime start = DateTime.Now; // TODO in NUnit 4, change this to await Assert.ThatAsync Assert.That(delegateToTest, Throws.InstanceOf<WebDriverTimeoutException>(), "I should have timed out after " + webDriverPageLoadTimeoutInSeconds + " seconds"); DateTime end = DateTime.Now; TimeSpan duration = end - start; Assert.That(duration.TotalSeconds, Is.GreaterThan(webDriverPageLoadTimeoutInSeconds));

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Learned best practice	Add null validation checks for required method parameters to prevent NullReferenceExceptions The handler parameter passed to networkInterceptor.AddResponseHandler() should be validated for null before use since it's a required parameter that could be null. Add a null check using ArgumentNullException.ThrowIfNull(). dotnet/test/common/NetworkInterceptionTests.cs [101] +ArgumentNullException.ThrowIfNull(handler, nameof(handler)); networkInterceptor.AddResponseHandler(handler); Apply this suggestion Suggestion importance[1-10]: 6	Low
Update

[RenderMichael]

This will give a warning, but there is no ClickAsync yet. I can add more code to clean it up, but is it worth it?

[nvborisenko]

Sync api is still under focus.

[RenderMichael]

This PR can be a draft until v5 work begins; hopefully this PR is not stake by then.

[nvborisenko]

Instead of staling, I am thinking to create some "next-generation" branch, where we can put our work for v5. Questions:

• how to maintain (resolving conflicts)
• decision what should be included into v5

[RenderMichael]

I think there is no difference between keeping this PR from being stale, and keeping a “next-generation” branch from being stale.

If we want to do v5 work already, we can have feature flags. We can keep trunk backwards-compatible while doing all kinds of work. Many new features (like async APIs) don’t need a feature flag, they can just be internal.

I like the idea of doing v5 work, but without a rough estimate on when v5 is coming (6 months? 3 years?) it may not be worth it to start now.