Update CSharp code block reference in options.en.md by kimtg · Pull Request #2612 · SeleniumHQ/seleniumhq.github.io

kimtg · 2026-03-30T04:53:53Z

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

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

Description

Motivation and Context

Types of changes

Change to the site (I have double-checked the Netlify deployment, and my changes look good)
Code example added (and I also added the example to all translated languages)
Improved translation
Added new translation (and I also added a notice to each document missing translation)

Checklist

I have read the contributing document.
I have used hugo to render the site/docs locally and I am sure it works.

netlify · 2026-03-30T04:53:57Z

✅ Deploy Preview for selenium-dev ready!

Name	Link
🔨 Latest commit	`8c1372e`
🔍 Latest deploy log	https://app.netlify.com/projects/selenium-dev/deploys/6a51eec66a3e600008b2e939
😎 Deploy Preview	https://deploy-preview-2612--selenium-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

CLAassistant · 2026-03-30T04:54:00Z

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ diemol
✅ rpallavisharma
❌ kimtg
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

qodo-code-review · 2026-03-30T04:54:04Z

Review Summary by Qodo

Add CSharp code block reference to options documentation

📝 Documentation

Walkthroughs

Description

• Replace placeholder badge with actual CSharp code reference
• Link to specific code example in dotnet SeleniumDocs repository
• Maintain consistency with other language code block references

Diagram

flowchart LR
  A["Badge placeholder"] -- "replaced with" --> B["gh-codeblock reference"]
  B -- "points to" --> C["OptionsTest.cs lines 59-60"]

File Changes

1. website_and_docs/content/documentation/webdriver/drivers/options.en.md 📝 Documentation +1/-1

Replace CSharp badge placeholder with code reference
• Replaced generic badge-code placeholder with specific gh-codeblock reference
• Added path to CSharp example file: /examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60
• Aligns CSharp documentation with Python and Ruby code block references
website_and_docs/content/documentation/webdriver/drivers/options.en.md

qodo-code-review · 2026-03-30T04:54:05Z

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Empty C# code block 🐞 Bug ≡ Correctness

Description

options.en.md now references OptionsTest.cs#L59-60, but OptionsTest.cs ends at line 57, so
gh-codeblock will slice an empty snippet and render a blank code block for the CSharp tab.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
The page now includes a gh-codeblock pointing at OptionsTest.cs#L59-60, but the referenced file
only contains 57 lines. The shortcode computes an index based on the fragment and uses
after/first to slice lines; when the starting index is beyond the file length, the resulting
slice is empty, producing an empty highlighted block.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[407-420]
examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-57]
website_and_docs/layouts/shortcodes/gh-codeblock.html[44-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The C# `gh-codeblock` reference points to a line range that does not exist in the referenced file, which renders an empty code snippet.

### Issue Context
`gh-codeblock` slices the remote file content based on the `#Lx-y` fragment; if `fromLine` is beyond EOF, the snippet becomes empty.

### Fix Focus Areas
- website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416]
- examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-57]

### What to change
- Update the `path=` fragment to a valid line range that exists in the target file **and** actually demonstrates `unhandledPromptBehavior` for C#.
- If there is no valid C# example yet, revert this tab back to `{{< badge-code >}}` until a suitable example is added.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. ~~Code modal ID collision~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

gh-codeblock uses only the file path to generate modal IDs, so adding another snippet from the
already-reused OptionsTest.cs path increases duplicate HTML IDs and can cause “View Complete Code”
to open the wrong modal content.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
options.en.md already embeds multiple gh-codeblock snippets from the same OptionsTest.cs path
(different fragments). The shortcode derives $uniqueId from md5 $path (path only, not fragment),
and uses that value in element IDs; multiple instances on the same page therefore produce duplicate
IDs and event handlers targeting the first matching element.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[114-125]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[155-166]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[195-205]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[407-419]
website_and_docs/layouts/shortcodes/gh-codeblock.html[62-66]
website_and_docs/layouts/shortcodes/gh-codeblock.html[76-90]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Multiple `gh-codeblock` invocations referencing the same file path on the same page create duplicate modal element IDs, which can break the “View Complete Code” behavior.

### Issue Context
`gh-codeblock` sets `$uniqueId := md5 $path`, so the ID does not vary by fragment/line range.

### Fix Focus Areas
- website_and_docs/layouts/shortcodes/gh-codeblock.html[62-66]
- website_and_docs/layouts/shortcodes/gh-codeblock.html[76-93]

### What to change
- Derive the modal ID from something truly unique per embed, e.g. hash `$fullPath` (includes fragment) instead of `$path`, or concatenate `$path` + fragment before hashing.
- Ensure all `id=` attributes and JS calls (`showCodeModal`, `closeCodeModal`, `copyCode`) use the updated unique ID consistently.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-03-30T04:58:13Z

 {{% /tab %}}
 {{< tab header="CSharp" >}}
-{{< badge-code >}}
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}


1. Empty c# code block 🐞 Bug ✓ Correctness

options.en.md now references OptionsTest.cs#L59-60, but OptionsTest.cs ends at line 57, so gh-codeblock will slice an empty snippet and render a blank code block for the CSharp tab.

Agent Prompt

### Issue description The C# `gh-codeblock` reference points to a line range that does not exist in the referenced file, which renders an empty code snippet. ### Issue Context `gh-codeblock` slices the remote file content based on the `#Lx-y` fragment; if `fromLine` is beyond EOF, the snippet becomes empty. ### Fix Focus Areas - website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416] - examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-57] ### What to change - Update the `path=` fragment to a valid line range that exists in the target file **and** actually demonstrates `unhandledPromptBehavior` for C#. - If there is no valid C# example yet, revert this tab back to `{{< badge-code >}}` until a suitable example is added.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

rpallavisharma · 2026-07-09T04:40:43Z

@kimtg please see the error generated by qodo.

qodo-code-review · 2026-07-09T04:42:43Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

1. Wrong C# example embedded 🐞 Bug ≡ Correctness ⭐ New

Description

The unhandledPromptBehavior CSharp tab embeds code from OptionsTest.cs, but that file only contains
PageLoadStrategy tests and does not demonstrate unhandled prompt behavior. This will render an
unrelated C# example for that section and mislead readers.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
The updated doc embeds a C# snippet from OptionsTest.cs for the unhandledPromptBehavior section,
but the referenced file contains only SetPageLoadStrategy* tests and no unhandled-prompt behavior
example, so it cannot correctly support that documentation section.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[407-416]
examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[10-56]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `unhandledPromptBehavior` section’s C# tab now embeds a snippet from `examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs`, but that file does not contain any example related to unhandled prompt behavior.

## Issue Context
`OptionsTest.cs` currently only contains tests setting `chromeOptions.PageLoadStrategy`.

## Fix
Do one of the following:
1) Point `gh-codeblock` at the correct .NET example file/lines that actually demonstrate unhandled prompt behavior (if it exists), OR
2) Add a correct .NET example (e.g., setting the appropriate option/capability) to an examples file, then update the `gh-codeblock` line-range to that example, OR
3) Revert this C# tab back to `{{< badge-code >}}` until a real example exists.

## Fix Focus Areas
- website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416]
- examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-56]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Empty C# code block 🐞 Bug ≡ Correctness

Description

options.en.md now references OptionsTest.cs#L59-60, but OptionsTest.cs ends at line 57, so
gh-codeblock will slice an empty snippet and render a blank code block for the CSharp tab.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
The page now includes a gh-codeblock pointing at OptionsTest.cs#L59-60, but the referenced file
only contains 57 lines. The shortcode computes an index based on the fragment and uses
after/first to slice lines; when the starting index is beyond the file length, the resulting
slice is empty, producing an empty highlighted block.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[407-420]
examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-57]
website_and_docs/layouts/shortcodes/gh-codeblock.html[44-52]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The C# `gh-codeblock` reference points to a line range that does not exist in the referenced file, which renders an empty code snippet.

### Issue Context
`gh-codeblock` slices the remote file content based on the `#Lx-y` fragment; if `fromLine` is beyond EOF, the snippet becomes empty.

### Fix Focus Areas
- website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416]
- examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-57]

### What to change
- Update the `path=` fragment to a valid line range that exists in the target file **and** actually demonstrates `unhandledPromptBehavior` for C#.
- If there is no valid C# example yet, revert this tab back to `{{< badge-code >}}` until a suitable example is added.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. Malformed codeblock fragment 🐞 Bug ≡ Correctness

Description

The new gh-codeblock reference uses #L59-60 instead of the documented #Lx-Ly format, so the
generated “View on GitHub” URL does not follow the repo’s documented line-range convention. This
makes the outbound link inconsistent with the project’s own gh-codeblock usage examples and may
prevent expected line-range navigation behavior.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
options.en.md introduces the fragment #L59-60. The style guide shows the expected gh-codeblock
line-range format as #Lx-Ly, and the gh-codeblock shortcode constructs the GitHub URL directly
from the provided path (including its fragment), so the malformed fragment becomes part of the
rendered link.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416]
website_and_docs/content/documentation/about/style.en.md[148-191]
website_and_docs/layouts/shortcodes/gh-codeblock.html[22-28]
website_and_docs/layouts/shortcodes/gh-codeblock.html[44-49]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `gh-codeblock` path fragment is `#L59-60`, but the project’s style guide documents `gh-codeblock` line ranges using `#L<from>-L<to>` (e.g. `#L25-L26`). Because the shortcode builds the GitHub URL directly from the provided `path`, the nonstandard fragment is propagated to the “View on GitHub” link.

## Issue Context
The shortcode parses fragments by splitting on `-` and stripping `L`, so the snippet slicing might still work, but the outbound GitHub URL will not match the documented format used elsewhere.

## Fix Focus Areas
- website_and_docs/content/documentation/webdriver/drivers/options.en.md[415-415]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. ~~Code modal ID collision~~ ✓ Resolved 🐞 Bug ☼ Reliability

Description

gh-codeblock uses only the file path to generate modal IDs, so adding another snippet from the
already-reused OptionsTest.cs path increases duplicate HTML IDs and can cause “View Complete Code”
to open the wrong modal content.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
options.en.md already embeds multiple gh-codeblock snippets from the same OptionsTest.cs path
(different fragments). The shortcode derives $uniqueId from md5 $path (path only, not fragment),
and uses that value in element IDs; multiple instances on the same page therefore produce duplicate
IDs and event handlers targeting the first matching element.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[114-125]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[155-166]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[195-205]
website_and_docs/content/documentation/webdriver/drivers/options.en.md[407-419]
website_and_docs/layouts/shortcodes/gh-codeblock.html[62-66]
website_and_docs/layouts/shortcodes/gh-codeblock.html[76-90]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Multiple `gh-codeblock` invocations referencing the same file path on the same page create duplicate modal element IDs, which can break the “View Complete Code” behavior.

### Issue Context
`gh-codeblock` sets `$uniqueId := md5 $path`, so the ID does not vary by fragment/line range.

### Fix Focus Areas
- website_and_docs/layouts/shortcodes/gh-codeblock.html[62-66]
- website_and_docs/layouts/shortcodes/gh-codeblock.html[76-93]

### What to change
- Derive the modal ID from something truly unique per embed, e.g. hash `$fullPath` (includes fragment) instead of `$path`, or concatenate `$path` + fragment before hashing.
- Ensure all `id=` attributes and JS calls (`showCodeModal`, `closeCodeModal`, `copyCode`) use the updated unique ID consistently.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Previous review results

Review updated until commit 8c1372e

Results up to commit bb97ce5

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Malformed codeblock fragment 🐞 Bug ≡ Correctness

Description

The new gh-codeblock reference uses #L59-60 instead of the documented #Lx-Ly format, so the
generated “View on GitHub” URL does not follow the repo’s documented line-range convention. This
makes the outbound link inconsistent with the project’s own gh-codeblock usage examples and may
prevent expected line-range navigation behavior.

Code

website_and_docs/content/documentation/webdriver/drivers/options.en.md[415]
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}

Evidence
options.en.md introduces the fragment #L59-60. The style guide shows the expected gh-codeblock
line-range format as #Lx-Ly, and the gh-codeblock shortcode constructs the GitHub URL directly
from the provided path (including its fragment), so the malformed fragment becomes part of the
rendered link.
website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416]
website_and_docs/content/documentation/about/style.en.md[148-191]
website_and_docs/layouts/shortcodes/gh-codeblock.html[22-28]
website_and_docs/layouts/shortcodes/gh-codeblock.html[44-49]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `gh-codeblock` path fragment is `#L59-60`, but the project’s style guide documents `gh-codeblock` line ranges using `#L<from>-L<to>` (e.g. `#L25-L26`). Because the shortcode builds the GitHub URL directly from the provided `path`, the nonstandard fragment is propagated to the “View on GitHub” link.

## Issue Context
The shortcode parses fragments by splitting on `-` and stripping `L`, so the snippet slicing might still work, but the outbound GitHub URL will not match the documented format used elsewhere.

## Fix Focus Areas
- website_and_docs/content/documentation/webdriver/drivers/options.en.md[415-415]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-07-09T04:42:44Z

 {{% /tab %}}
 {{< tab header="CSharp" >}}
-{{< badge-code >}}
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}


1. Malformed codeblock fragment 🐞 Bug ≡ Correctness

The new gh-codeblock reference uses #L59-60 instead of the documented #Lx-Ly format, so the generated “View on GitHub” URL does not follow the repo’s documented line-range convention. This makes the outbound link inconsistent with the project’s own gh-codeblock usage examples and may prevent expected line-range navigation behavior.

Agent Prompt

## Issue description The new `gh-codeblock` path fragment is `#L59-60`, but the project’s style guide documents `gh-codeblock` line ranges using `#L<from>-L<to>` (e.g. `#L25-L26`). Because the shortcode builds the GitHub URL directly from the provided `path`, the nonstandard fragment is propagated to the “View on GitHub” link. ## Issue Context The shortcode parses fragments by splitting on `-` and stripping `L`, so the snippet slicing might still work, but the outbound GitHub URL will not match the documented format used elsewhere. ## Fix Focus Areas - website_and_docs/content/documentation/webdriver/drivers/options.en.md[415-415]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

diemol · 2026-07-11T07:20:58Z

Can you please sign the CLA?

qodo-code-review · 2026-07-11T07:22:50Z

 {{% /tab %}}
 {{< tab header="CSharp" >}}
-{{< badge-code >}}
+{{< gh-codeblock path="/examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs#L59-60">}}


1. Wrong c# example embedded 🐞 Bug ≡ Correctness

The unhandledPromptBehavior CSharp tab embeds code from OptionsTest.cs, but that file only contains PageLoadStrategy tests and does not demonstrate unhandled prompt behavior. This will render an unrelated C# example for that section and mislead readers.

Agent Prompt

## Issue description The `unhandledPromptBehavior` section’s C# tab now embeds a snippet from `examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs`, but that file does not contain any example related to unhandled prompt behavior. ## Issue Context `OptionsTest.cs` currently only contains tests setting `chromeOptions.PageLoadStrategy`. ## Fix Do one of the following: 1) Point `gh-codeblock` at the correct .NET example file/lines that actually demonstrate unhandled prompt behavior (if it exists), OR 2) Add a correct .NET example (e.g., setting the appropriate option/capability) to an examples file, then update the `gh-codeblock` line-range to that example, OR 3) Revert this C# tab back to `{{< badge-code >}}` until a real example exists. ## Fix Focus Areas - website_and_docs/content/documentation/webdriver/drivers/options.en.md[414-416] - examples/dotnet/SeleniumDocs/Drivers/OptionsTest.cs[1-56]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

qodo-code-review · 2026-07-11T07:22:51Z

Code review by qodo was updated up to the latest commit 8c1372e

diemol · 2026-07-18T21:17:26Z

Superseeded by #2724

* Add C# example for unhandledPromptBehavior option Adds the missing SetUnhandledPromptBehavior test to OptionsTest.cs and wires the CSharp tab in the docs to it, replacing the placeholder badge. Based on #2611 and #2612 by kimtg. Co-authored-by: KIM Taegyoon <steloflute@gmail.com> Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: avoid Windows file-lock races in EdgeTest log tests On Windows, msedgedriver can still hold its log file open for a moment after driver.Quit(), so reading the log right after Quit() intermittently threw IOException in LogsToFile, LogsLevel, ConfigureDriverLogs, and DisableBuildCheck. Mirrors the Python and Ruby examples, which read the log while the service is still running instead of after quitting (see 4decac3 for the equivalent Python fix). Also guards the log file deletion in Cleanup() against the same race, tolerating IOException like Python's contextlib.suppress(OSError) and Ruby's FileUtils.rm_f. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: retry reading Edge log file to survive Windows lock window CI showed the log file is locked for the entire life of the Edge driver service on Windows, not just briefly after Quit() -- moving the read before Quit() (previous commit) failed immediately since the driver process was still running. Reading after Quit() is correct, but the OS still needs a moment to release the handle once the process exits, so wrap the read in a short bounded retry instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: null-safe driver.Quit() in EdgeTest cleanup If driver creation throws before the field is assigned, Cleanup()'s unconditional driver.Quit() throws NullReferenceException and masks the real test failure. ChromeTest.cs already uses this driver?.Quit() pattern in its own cleanup; apply it here too. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: widen retry budget for Edge log file read on Windows The previous 2s retry budget (10 x 200ms) wasn't enough -- CI still failed with the same IOException after exhausting all attempts. EdgeDriverService.LogPath is fed by DriverService's async OutputDataReceived event handler (per the Selenium.WebDriver XML docs), so the log FileStream can stay open for several seconds after Quit() returns while the last buffered output drains. Widen the budget to ~9.5s (20 x 500ms) to reliably outlast that tail. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix: narrow EdgeTest log retry to sharing/lock violations only ReadLogLines was retrying on any IOException, so a genuine failure (missing file, bad path, permissions) would silently eat up to ~10s of sleeping before surfacing, slowing down and obscuring real failures. Restrict the retry to the specific Win32 sharing/lock violation HRESULTs the Windows file-lock race actually produces; everything else propagates immediately. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * try: replace log-read retry with explicit service.Dispose() Drop the retry loop and try forcing a real synchronous teardown instead: EdgeDriverService.LogPath is fed by DriverService's async OutputDataReceived handler, so driver.Quit() alone may return before that stream is fully flushed and closed. Holding the service reference and calling service.Dispose() explicitly should block until the log file is actually released, letting us read it with a plain File.ReadAllLines and no polling. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * revert: bring back narrowed retry, keep explicit service.Dispose() The explicit-Dispose-only approach didn't work: CI showed the same IOException immediately after driver.Quit() + service.Dispose(), so DriverService's async OutputDataReceived teardown isn't fully synchronous even through an explicit Dispose() call. Restore the retry (narrowed to actual sharing/lock-violation HRESULTs, ~9.5s budget), and keep the Dispose() call alongside it since it's still correct resource cleanup and may shrink the typical wait. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * simplify: drop HResult filtering and explanatory comments in EdgeTest This is a doc code example, not production code -- the narrowed sharing/lock-violation HResult check added unnecessary verbosity, and comments like "Close the Service log file before reading" get confusing once the file is translated. Keep the retry and service.Dispose(), drop the rest. --------- Co-authored-by: KIM Taegyoon <steloflute@gmail.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

Update CSharp code block reference in options.en.md

2253caf

qodo-code-review Bot reviewed Mar 30, 2026

View reviewed changes

Merge branch 'trunk' into patch-2

bb97ce5

qodo-code-review Bot reviewed Jul 9, 2026

View reviewed changes

Merge branch 'trunk' into patch-2

8c1372e

qodo-code-review Bot reviewed Jul 11, 2026

View reviewed changes

diemol mentioned this pull request Jul 17, 2026

Add C# example for unhandledPromptBehavior option #2724

Merged

6 tasks

diemol closed this Jul 18, 2026

Uh oh!

Uh oh!

Conversation

kimtg commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Motivation and Context

Types of changes

Checklist

Uh oh!

netlify Bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for selenium-dev ready!

Uh oh!

CLAassistant commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review Bot commented Mar 30, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-code-review Bot commented Mar 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

qodo-code-review Bot Mar 30, 2026

Choose a reason for hiding this comment

Uh oh!

rpallavisharma commented Jul 9, 2026

Uh oh!

qodo-code-review Bot commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Previous review results

Uh oh!

qodo-code-review Bot Jul 9, 2026

Choose a reason for hiding this comment

Uh oh!

diemol commented Jul 11, 2026

Uh oh!

qodo-code-review Bot Jul 11, 2026

Choose a reason for hiding this comment

Uh oh!

qodo-code-review Bot commented Jul 11, 2026

Uh oh!

diemol commented Jul 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kimtg commented Mar 30, 2026 •

edited

Loading

netlify Bot commented Mar 30, 2026 •

edited

Loading

CLAassistant commented Mar 30, 2026 •

edited

Loading

qodo-code-review Bot commented Mar 30, 2026 •

edited

Loading

qodo-code-review Bot commented Jul 9, 2026 •

edited

Loading