Bump Selenium to 4.49.0 across example bindings - #2830
Merged
Merged
Conversation
Swaps the bundled selenium-server-4.46.0.jar used by Remote WebDriver example test fixtures for 4.49.0, and updates the hardcoded filename references in the Python, Ruby, and .NET example suites. Validated: pytest tests/drivers/test_remote_webdriver.py (3 passed), bundle exec rspec spec/drivers/remote_webdriver_spec.rb (3 passed), dotnet test --filter RemoteWebDriverTest (4 passed). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
✅ Deploy Preview for selenium-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
Code Review by Qodo🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)
Great, no issues found!Qodo reviewed your code and found no material issues that require reviewTip of the day💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full Previous reviewsReview updated until commit 2274b00 Results up to commit 5f5dac3
|
Contributor
PR Summary by QodoBump bundled Selenium server jar to 4.49.0
AI Description
Diagram
High-Level Assessment
Files changed (4)
|
…ersion Selenium.Support/Selenium.WebDriver were still pinned to 4.46.0, the only binding left behind after the server jar bump. Bumping them to 4.49.0 surfaced a compile break in BiDi/CDP/NetworkTest.cs: the 4.49.0 client only ships DevTools protocol domains V151-V153, not the previously pinned V150. Moved the namespace usages, generic domain lookups, and the hardcoded browser version requested from Selenium Manager from 150 to 153 in lock step, matching how they were already paired. Validated: dotnet test --filter NetworkTest -> 7/7 passed (was failing to compile, then failing at runtime with "DevTools version is not in the supported range" before this fix). Full suite: 161/164 passed, 3 failures are pre-existing flakiness unrelated to this change (live-site network timeout and browser-parallelism scroll timing), confirmed by each passing individually in isolation. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
diemol
changed the title
Contributor
|
Code review by qodo was updated up to the latest commit 2274b00 |
diemol
added a commit
that referenced
this pull request
Sep 17, 2026
- gridServer.js still pointed at selenium-server-4.46.0.jar after the merge from trunk (#2830), which renamed the bundled jar to 4.49.0 and didn't touch this file since it didn't exist on trunk at merge time. - Addressed a new Qodo finding surfaced by the previous readiness-check fix: waitForServer only advanced past its overall deadline after an HTTP response ended or errored, so a connection that stalled or aborted mid-response could hang startGrid indefinitely past the declared 60s timeout, with cleanup never reached. Added a per-request timeout (2s) that destroys the stalled request and retries, plus an 'aborted' handler on the response. Verified: npx mocha test/drivers/*.spec.js -> 7/7 passing against the real selenium-server-4.49.0.jar. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ko4CniqqrtSVntSMKyQrqq
diemol
added a commit
that referenced
this pull request
Sep 17, 2026
* Add JavaScript examples for Remote WebDriver docs Every section of the Remote WebDriver doc page (Basic Example, Uploads, Downloads, Browser specific functionalities) had no JavaScript example, only a badge-code placeholder. Adds a remote_webdriver.spec.js covering the same ground as the existing Java/Python/.NET/Ruby examples, plus a gridServer.js helper that spins up a local standalone Grid the same way Python's conftest.py server fixture does, and wires the new examples into the docs via gh-codeblock line references. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * Address Qodo review findings on Remote WebDriver JS examples - gridServer.js: waitForServer now checks the HTTP status code and parses the /status JSON payload for value.ready instead of resolving on any response, and startGrid kills the spawned Java process if the readiness wait fails/times out instead of leaking it. - remote_webdriver.spec.js: the Downloads test now waits until every expected file name is present (not just the last one requested) before asserting the file list, avoiding a flaky race; afterEach now stops the Grid process in a finally block so a rejected driver.quit() can't skip cleanup. - Updated remote_webdriver.en.md gh-codeblock line ranges to match the shifted line numbers in the spec file. Verified: npx mocha test/drivers/*.spec.js -> 7/7 passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ko4CniqqrtSVntSMKyQrqq * Fix jar reference after 4.49.0 bump and harden grid readiness polling - gridServer.js still pointed at selenium-server-4.46.0.jar after the merge from trunk (#2830), which renamed the bundled jar to 4.49.0 and didn't touch this file since it didn't exist on trunk at merge time. - Addressed a new Qodo finding surfaced by the previous readiness-check fix: waitForServer only advanced past its overall deadline after an HTTP response ended or errored, so a connection that stalled or aborted mid-response could hang startGrid indefinitely past the declared 60s timeout, with cleanup never reached. Added a per-request timeout (2s) that destroys the stalled request and retries, plus an 'aborted' handler on the response. Verified: npx mocha test/drivers/*.spec.js -> 7/7 passing against the real selenium-server-4.49.0.jar. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ko4CniqqrtSVntSMKyQrqq * Guard grid readiness polling against duplicate/unhandled retry events Two findings from the previous readiness-check hardening: - The response had no 'error' listener, only 'aborted'. A response that closes mid-stream (e.g. ECONNRESET) emits an unhandled 'error' event, which crashes the Node process instead of triggering a retry. - A single stalled attempt could call retryOrFail() twice: once from the request's 'timeout' handler (which also destroys the request), and again from the resulting response 'aborted' event triggered by that destroy. Each call scheduled its own follow-up attempt, so a stalled server could multiply concurrent polling requests toward the deadline. Added a per-attempt 'settled' guard (retryOnce) shared by the response end/error/aborted handlers and the request timeout/error handlers, so exactly one outcome (resolve or a single retry) is produced per attempt regardless of how many of those events fire. Verified: npx mocha test/drivers/*.spec.js -> 7/7 passing. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Ko4CniqqrtSVntSMKyQrqq --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
Bumps Selenium to 4.49.0 across the example test suites:
Bundled Grid server jar:
selenium-server-4.46.0.jar->selenium-server-4.49.0.jar(new binary downloaded from the officialselenium-4.49.0GitHub release), following the same pattern as the previous bump (0451a8cd7ed, "Bumping to Grid 4.46"). Updated the hardcoded filename in:examples/dotnet/SeleniumDocs/BaseTest.csexamples/python/tests/conftest.py(3 occurrences)examples/ruby/spec/drivers/remote_webdriver_spec.rbexamples/javascript/test/drivers/gridServer.jswas not touched — it doesn't exist ontrunkyet (part of the not-yet-merged Add JavaScript examples for Remote WebDriver docs (#2562) #2829). Whoever merges second should update it..NET client packages:
Selenium.Support/Selenium.WebDriverwere still pinned to 4.46.0 — the only binding left behind (Java, Python, Ruby, JavaScript, and Kotlin were already on 4.49.0). Bumped both to 4.49.0.This surfaced a real compile+runtime break in
examples/dotnet/SeleniumDocs/BiDi/CDP/NetworkTest.cs: the 4.49.0 client only ships DevTools/CDP protocol domains V151-V153, not the previously hardcoded V150 (and the matchingStartDriver("150")browser version request). Moved the namespace usages, generic domain lookups, and the browser version string from 150 to 153 together, keeping the existing pairing pattern intact.Deliberately left untouched:
website_and_docs/content/blog/2026/selenium-4-46-released.md— historical blog content.Motivation and Context
Keeps every language binding's example test suite exercising a current Selenium version (both the server and each client library), and keeps Remote WebDriver/Grid examples working against a current server jar. A user directly asked whether all languages were on 4.49 after reviewing this PR's initial CI results, which surfaced the .NET client gap.
Types of changes
Checklist
Validation
pytest tests/drivers/test_remote_webdriver.py -v-> 3 passedbundle exec rspec spec/drivers/remote_webdriver_spec.rb-> 3 examples, 0 failuresdotnet test --filter RemoteWebDriverTest-> 4 passed;dotnet test --filter NetworkTest-> 7 passed (previously failed to compile, then failed at runtime, before the V150->V153 fix); full suitedotnet test-> 161/164 passed, remaining 3 failures are pre-existing flakiness unrelated to this change (live-site network timeout, browser-parallelism scroll timing) — confirmed by each passing individually in isolation.Note on CI: the
tests (ubuntu/windows, nightly)jobs on this PR fail on an unrelated, pre-existingV150compile error in the nightly .NET client matrix — confirmed already failing ontrunk's scheduled nightly runs for 5+ days before this PR existed. Thestablematrix jobs pass.🤖 Generated with Claude Code