Skip to content

[js] Run tests on Grid - #18081

Merged
pujagani merged 7 commits into
SeleniumHQ:trunkfrom
pujagani:js-add-grid-tests
Sep 29, 2026
Merged

pujagani merged 7 commits into
SeleniumHQ:trunkfrom
pujagani:js-add-grid-tests

Conversation

@pujagani

Copy link
Copy Markdown
Contributor

🔗 Related Issues

💥 What does this PR do?

Add Javascript tests for Grid

🔧 Implementation Notes

Tried to take inspiration from Python and Ruby to see if this works

🤖 AI assistance

  • No substantial AI assistance used
  • AI assisted (complete below)
    • Tool(s):
    • What was generated:
    • [ \X] I reviewed all AI output and can explain the change

💡 Additional Considerations

@selenium-ci selenium-ci added C-nodejs JavaScript Bindings B-build Includes scripting, bazel and CI integrations B-devtools Includes everything BiDi or Chrome DevTools related labels Sep 28, 2026
@qodo-code-review

Copy link
Copy Markdown
Contributor

PR Summary by Qodo

Run JavaScript browser tests against a Bazel-managed Grid

🧪 Tests ✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

AI Description

• Add Chrome and Firefox Grid targets for browser tests alongside existing local targets.
• Start each target’s standalone server with Bazel-provided Java, browser, and driver binaries.
• Adapt incompatible and timing-sensitive tests, and document how to run or skip Grid tests.
Diagram

graph TD
  A["Bazel Grid targets"] --> B["Mocha tests"] --> C["Test harness"] --> D["Server launcher"] --> E["Standalone Grid"] --> F["Browser driver"]
  A --> G["Hermetic Java"] --> D
  C -- "Pinned binaries" --> E
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Use an externally managed Grid
  • ➕ Avoids starting a server for every test target.
  • ➕ Uses the harness’s existing SELENIUM_REMOTE_URL support.
  • ➖ Requires separately provisioned infrastructure.
  • ➖ Makes browser and driver versions less tightly coupled to Bazel test inputs.

Recommendation: Prefer the per-target standalone Grid for reproducible, isolated Bazel runs. An external Grid remains useful for environments that already manage shared browser infrastructure.

Files changed (8) +249 / -84

Enhancement (3) +85 / -9
index.jsAllow SeleniumServer to use a specified Java executable +12/-3

Allow SeleniumServer to use a specified Java executable

• Adds a java option to SeleniumServer and uses it for both launching the server and formatting its arguments.

javascript/selenium-webdriver/remote/index.js

util.jsUse the selected Java executable for server version detection +5/-5

Use the selected Java executable for server version detection

• Accepts an optional Java path in version detection and argument formatting, retaining the existing default when none is supplied.

javascript/selenium-webdriver/remote/util.js

index.jsConfigure Bazel-backed standalone Grid sessions +68/-1

Configure Bazel-backed standalone Grid sessions

• Resolves the server JAR and hermetic Java from runfiles, then pins Grid to Bazel-provided Chrome or Firefox binaries when available. Adds env.remote() so tests can identify server-backed sessions.

javascript/selenium-webdriver/testing/index.js

Tests (3) +60 / -56
browsingcontext_inspector_test.jsSkip a flaky Firefox browsing-context assertion +20/-13

Skip a flaky Firefox browsing-context assertion

• Suppresses the Firefox case whose event callback can observe a different context, and records what would make the test reliable.

javascript/selenium-webdriver/test/bidi/browsingcontext_inspector_test.js

contextSwitching_test.jsSkip local-only context switching on Grid +3/-6

Skip local-only context switching on Grid

• Uses the new remote-environment predicate to exclude tests that require geckodriver system access, replacing an environment-variable check.

javascript/selenium-webdriver/test/firefox/contextSwitching_test.js

capabilities_test.jsMake file-upload tests reliable through Grid +37/-37

Make file-upload tests reliable through Grid

• Waits for remote file transfer before submitting the upload form. Ensures drivers are quit even when either capability test fails.

javascript/selenium-webdriver/test/lib/capabilities_test.js

Documentation (1) +18 / -0
TESTING.mdDocument Grid targets and remote-test skips +18/-0

Document Grid targets and remote-test skips

• Adds commands for running remote targets and explains the excluded files. Documents env.remote() for tests that require a local driver.

javascript/selenium-webdriver/TESTING.md

Other (1) +86 / -19
BUILD.bazelGenerate per-browser Grid test targets +86/-19

Generate per-browser Grid test targets

• Extracts shared large-test inputs and tags, excludes tests that do not suit Grid execution, and adds Chrome and Firefox remote targets. Each remote target includes the server JAR and hermetic JDK.

javascript/selenium-webdriver/BUILD.bazel

@qodo-code-review

qodo-code-review Bot commented Sep 28, 2026 •

Copy link
Copy Markdown
Contributor

Code Review by Qodo

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

Grey Divider


Action required

1. Edge sessions fail in mixed Grid runs ✓ Resolved
Description
pinnedGridArgs() disables driver detection when any selected browser is pinned, even though
PINNED_BROWSERS has no Edge entry. With a comma-separated selection such as chrome,edge or
edge,firefox, pinning Chrome or Firefox leaves the shared Grid without an Edge slot, even when
Edge browser and driver paths are provided.
Code

javascript/selenium-webdriver/testing/index.js[625]

+  return configurations.length > 0 ? ['--detect-drivers', 'false', ...configurations] : []
Evidence
init() accepts comma-separated browser selections, and suite() passes the full selection to
pinnedGridArgs(). The mapping covers Chrome and Firefox but not Edge; although the function skips
browsers without pinned configuration, it still emits --detect-drivers false when another browser
is configured. Grid's addDetectedDrivers() then returns without adding a slot for Edge, despite
the Edge paths supplied by the Bazel browser configuration.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[474-478]
javascript/selenium-webdriver/testing/index.js[598-625]
javascript/private/browsers.bzl[31-45]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[548-568]
javascript/selenium-webdriver/testing/index.js[103-125]
javascript/selenium-webdriver/testing/index.js[473-478]
javascript/selenium-webdriver/testing/index.js[610-625]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[544-553]

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

## Issue description
`pinnedGridArgs()` disables Grid driver detection after configuring any pinned browser, leaving other selected browsers without slots when they are not pinned.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[598-625]

## Recommended Fix
Add pinned configurations for supported browsers, including Edge. Disable driver detection only when every selected browser has an explicit configuration; otherwise retain detection so unconfigured browsers can receive sessions.

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


2. Pinned runs cannot start older servers 📘 Rule violation ☼ Reliability
Description
pinnedGridArgs() adds Grid 4 driver-configuration flags to a locally managed server whenever
Chrome or Firefox paths are pinned, without checking the server version. When SELENIUM_SERVER_JAR
points to a Selenium 3 jar, formatSpawnArgs() retains those unsupported flags, so server startup
fails before the tests run.
Code

javascript/selenium-webdriver/testing/index.js[R618-622]

+      '--driver-configuration',
+      `display-name=${browserName}`,
+      'max-sessions=1',
+      `webdriver-executable=${locate(process.env[driverVar])}`,
+      `stereotype=${stereotype}`,
Evidence
The new startup path always appends pinnedGridArgs() when launching a local jar. The repository
retains an explicit Selenium 3 branch that returns spawn arguments unchanged, while its Grid
changelog documents driver-configuration argument support in the Selenium 4 series.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[474-478]
javascript/selenium-webdriver/testing/index.js[610-625]
javascript/selenium-webdriver/remote/util.js[31-51]
java/CHANGELOG[1076-1083]

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

## Issue description
Pinned browser paths cause the test harness to pass Grid 4 configuration flags to Selenium 3 servers, which the existing server compatibility path does not translate.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[474-478]
- javascript/selenium-webdriver/testing/index.js[610-625]

## Recommended Fix
Use the pinned driver-configuration flags only for servers that support them. Retain a version-compatible startup path for Selenium 3 jars and test both paths.

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


3. Second browser cannot start on Grid ✓ Resolved
Description
suite() creates one shared seleniumServer but initializes it with pinnedGridArgs(browser.name)
for only the first selected browser. When SELENIUM_BROWSER selects multiple browsers with pinned
binaries, that configuration disables driver detection and leaves later browser environments using
the shared server without matching Grid slots.
Code

javascript/selenium-webdriver/testing/index.js[465]

+            args: pinnedGridArgs(browser.name),
Evidence
The testing API supports comma-delimited browser selection, and the harness iterates over those
browsers while constructing the module-global server only once. The new pinning call uses the first
browser to create a single browser-specific driver configuration; subsequent environments reuse that
server, and pinned configuration disables discovery of additional drivers.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[101-110]
javascript/selenium-webdriver/testing/index.js[460-470]
javascript/selenium-webdriver/testing/index.js[600-614]
javascript/selenium-webdriver/testing/index.js[358-362]
javascript/selenium-webdriver/testing/index.js[94-112]
javascript/selenium-webdriver/testing/index.js[460-478]
javascript/selenium-webdriver/testing/index.js[587-615]
java/src/org/openqa/selenium/grid/node/config/NodeFlags.java[158-179]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[406-459]
javascript/selenium-webdriver/testing/index.js[431-484]
javascript/private/browsers.bzl[8-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 managed Selenium server is shared across browsers selected by `SELENIUM_BROWSER`, but its pinned driver configuration covers only the first browser. Multi-browser runs with pinned binaries therefore lack Grid slots for later browsers.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[431-484]
- javascript/selenium-webdriver/testing/index.js[587-615]

## Recommended Fix
Before starting the shared server, build its arguments from all selected browsers, emitting a `--driver-configuration` group for each browser with complete pinned driver and browser paths. Keep default Grid detection when no selected browser has a complete pinned configuration. Add a test with a comma-delimited Chrome and Firefox selection and both binaries pinned.

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



Remediation recommended

4. Manual CI skips full tests ⊘ Outdated
Description
os-tests-full checks inputs.smoke, but the top-level CI workflow calls this reusable workflow
without passing that input, so its workflow_call default is true. When a maintainer manually
dispatches top-level CI, the event is not schedule and the full JavaScript matrix is skipped.
Code

.github/workflows/ci-javascript.yml[82]

+    if: github.event_name == 'schedule' || !inputs.smoke
Evidence
Top-level CI declares manual dispatch and calls the JavaScript reusable workflow without a smoke
input. That call receives the new workflow_call default of true; the new full-matrix condition
is therefore false for a manual dispatch.

.github/workflows/ci.yml[10-14]
.github/workflows/ci.yml[175-181]
.github/workflows/ci-javascript.yml[5-10]
.github/workflows/ci-javascript.yml[80-83]

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

## Issue description
Manually dispatching the top-level CI workflow skips the JavaScript full matrix because its reusable-workflow call receives the default `smoke: true`.

## Fix Focus Areas
- .github/workflows/ci.yml[175-181]
- .github/workflows/ci-javascript.yml[5-10]
- .github/workflows/ci-javascript.yml[80-83]

## Recommended Fix
Pass `smoke: false` from the top-level caller for `workflow_dispatch`, while retaining smoke-only behavior for ordinary calls. Preserve the directly dispatched JavaScript workflow's ability to select smoke-only runs.

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


5. Network peers control test browsers ✓ Resolved
Description
The new Grid targets start SeleniumServer without restricting its listener to loopback, leaving
the standalone server's WebDriver routes unauthenticated. When a CI worker's ephemeral test port is
reachable from another machine, that machine can create sessions and control the test browser.
Code

javascript/selenium-webdriver/testing/index.js[R463-466]

+          seleniumServer = new remote.SeleniumServer(seleniumJar, {
+            java: bazelJava(),
+            args: pinnedGridArgs(browser.name),
+          })
Evidence
The PR's Grid targets supply the server JAR and activate this startup path. The new constructor
options omit loopback and a Java host argument; the Java listener defaults to 0.0.0.0, while
authentication is installed only when credentials are configured. Network reachability depends on
the worker's network configuration.

javascript/selenium-webdriver/BUILD.bazel[337-359]
javascript/selenium-webdriver/testing/index.js[460-474]
java/src/org/openqa/selenium/netty/server/NettyServer.java[129-134]
java/src/org/openqa/selenium/grid/commands/Standalone.java[202-213]

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

## Issue description
New Grid targets start an unauthenticated standalone server that binds to all network interfaces by default.
## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[461-466]
- javascript/selenium-webdriver/remote/index.js[239-246]
## Recommended Fix
Pass `--host 127.0.0.1` to the standalone server and set `loopback: true` on `SeleniumServer` so both the Java listener and the JavaScript client use loopback.

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


Grey Divider

Context sources
Review mode: 🚀 Fast: The push makes a localized change to Grid test-server driver pinning in one function, with contained behavior and no security, API, schema, or broad cross-cutting risk.

Grey Divider

Tip of the day
💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Previous reviews

Review updated until commit 8ecd483

Results up to commit 0de34e8 🧠 Deep


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


Action required
1. Second browser cannot start on Grid ✓ Resolved
Description
suite() creates one shared seleniumServer but initializes it with pinnedGridArgs(browser.name)
for only the first selected browser. When SELENIUM_BROWSER selects multiple browsers with pinned
binaries, that configuration disables driver detection and leaves later browser environments using
the shared server without matching Grid slots.
Code

javascript/selenium-webdriver/testing/index.js[465]

+            args: pinnedGridArgs(browser.name),
Evidence
The testing API supports comma-delimited browser selection, and the harness iterates over those
browsers while constructing the module-global server only once. The new pinning call uses the first
browser to create a single browser-specific driver configuration; subsequent environments reuse that
server, and pinned configuration disables discovery of additional drivers.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[101-110]
javascript/selenium-webdriver/testing/index.js[460-470]
javascript/selenium-webdriver/testing/index.js[600-614]
javascript/selenium-webdriver/testing/index.js[358-362]
javascript/selenium-webdriver/testing/index.js[94-112]
javascript/selenium-webdriver/testing/index.js[460-478]
javascript/selenium-webdriver/testing/index.js[587-615]
java/src/org/openqa/selenium/grid/node/config/NodeFlags.java[158-179]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[406-459]
javascript/selenium-webdriver/testing/index.js[431-484]
javascript/private/browsers.bzl[8-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 managed Selenium server is shared across browsers selected by `SELENIUM_BROWSER`, but its pinned driver configuration covers only the first browser. Multi-browser runs with pinned binaries therefore lack Grid slots for later browsers.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[431-484]
- javascript/selenium-webdriver/testing/index.js[587-615]

## Recommended Fix
Before starting the shared server, build its arguments from all selected browsers, emitting a `--driver-configuration` group for each browser with complete pinned driver and browser paths. Keep default Grid detection when no selected browser has a complete pinned configuration. Add a test with a comma-delimited Chrome and Firefox selection and both binaries pinned.

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



Remediation recommended
2. Network peers control test browsers ✓ Resolved
Description
The new Grid targets start SeleniumServer without restricting its listener to loopback, leaving
the standalone server's WebDriver routes unauthenticated. When a CI worker's ephemeral test port is
reachable from another machine, that machine can create sessions and control the test browser.
Code

javascript/selenium-webdriver/testing/index.js[R463-466]

+          seleniumServer = new remote.SeleniumServer(seleniumJar, {
+            java: bazelJava(),
+            args: pinnedGridArgs(browser.name),
+          })
Evidence
The PR's Grid targets supply the server JAR and activate this startup path. The new constructor
options omit loopback and a Java host argument; the Java listener defaults to 0.0.0.0, while
authentication is installed only when credentials are configured. Network reachability depends on
the worker's network configuration.

javascript/selenium-webdriver/BUILD.bazel[337-359]
javascript/selenium-webdriver/testing/index.js[460-474]
java/src/org/openqa/selenium/netty/server/NettyServer.java[129-134]
java/src/org/openqa/selenium/grid/commands/Standalone.java[202-213]

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

## Issue description
New Grid targets start an unauthenticated standalone server that binds to all network interfaces by default.
## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[461-466]
- javascript/selenium-webdriver/remote/index.js[239-246]
## Recommended Fix
Pass `--host 127.0.0.1` to the standalone server and set `loopback: true` on `SeleniumServer` so both the Java listener and the JavaScript client use loopback.

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


Results up to commit 98d21bb ⚖️ Balanced


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


Remediation recommended
1. Manual CI skips full tests ⊘ Outdated
Description
os-tests-full checks inputs.smoke, but the top-level CI workflow calls this reusable workflow
without passing that input, so its workflow_call default is true. When a maintainer manually
dispatches top-level CI, the event is not schedule and the full JavaScript matrix is skipped.
Code

.github/workflows/ci-javascript.yml[82]

+    if: github.event_name == 'schedule' || !inputs.smoke
Evidence
Top-level CI declares manual dispatch and calls the JavaScript reusable workflow without a smoke
input. That call receives the new workflow_call default of true; the new full-matrix condition
is therefore false for a manual dispatch.

.github/workflows/ci.yml[10-14]
.github/workflows/ci.yml[175-181]
.github/workflows/ci-javascript.yml[5-10]
.github/workflows/ci-javascript.yml[80-83]

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

## Issue description
Manually dispatching the top-level CI workflow skips the JavaScript full matrix because its reusable-workflow call receives the default `smoke: true`.

## Fix Focus Areas
- .github/workflows/ci.yml[175-181]
- .github/workflows/ci-javascript.yml[5-10]
- .github/workflows/ci-javascript.yml[80-83]

## Recommended Fix
Pass `smoke: false` from the top-level caller for `workflow_dispatch`, while retaining smoke-only behavior for ordinary calls. Preserve the directly dispatched JavaScript workflow's ability to select smoke-only runs.

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


Results up to commit 9cd49a0 ⚖️ Balanced


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


Action required
1. Edge sessions fail in mixed Grid runs ✓ Resolved
Description
pinnedGridArgs() disables driver detection when any selected browser is pinned, even though
PINNED_BROWSERS has no Edge entry. With a comma-separated selection such as chrome,edge or
edge,firefox, pinning Chrome or Firefox leaves the shared Grid without an Edge slot, even when
Edge browser and driver paths are provided.
Code

javascript/selenium-webdriver/testing/index.js[625]

+  return configurations.length > 0 ? ['--detect-drivers', 'false', ...configurations] : []
Evidence
init() accepts comma-separated browser selections, and suite() passes the full selection to
pinnedGridArgs(). The mapping covers Chrome and Firefox but not Edge; although the function skips
browsers without pinned configuration, it still emits --detect-drivers false when another browser
is configured. Grid's addDetectedDrivers() then returns without adding a slot for Edge, despite
the Edge paths supplied by the Bazel browser configuration.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[474-478]
javascript/selenium-webdriver/testing/index.js[598-625]
javascript/private/browsers.bzl[31-45]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[548-568]
javascript/selenium-webdriver/testing/index.js[103-125]
javascript/selenium-webdriver/testing/index.js[473-478]
javascript/selenium-webdriver/testing/index.js[610-625]
java/src/org/openqa/selenium/grid/node/config/NodeOptions.java[544-553]

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

## Issue description
`pinnedGridArgs()` disables Grid driver detection after configuring any pinned browser, leaving other selected browsers without slots when they are not pinned.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[598-625]

## Recommended Fix
Add pinned configurations for supported browsers, including Edge. Disable driver detection only when every selected browser has an explicit configuration; otherwise retain detection so unconfigured browsers can receive sessions.

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


2. Pinned runs cannot start older servers 📘 Rule violation ☼ Reliability
Description
pinnedGridArgs() adds Grid 4 driver-configuration flags to a locally managed server whenever
Chrome or Firefox paths are pinned, without checking the server version. When SELENIUM_SERVER_JAR
points to a Selenium 3 jar, formatSpawnArgs() retains those unsupported flags, so server startup
fails before the tests run.
Code

javascript/selenium-webdriver/testing/index.js[R618-622]

+      '--driver-configuration',
+      `display-name=${browserName}`,
+      'max-sessions=1',
+      `webdriver-executable=${locate(process.env[driverVar])}`,
+      `stereotype=${stereotype}`,
Evidence
The new startup path always appends pinnedGridArgs() when launching a local jar. The repository
retains an explicit Selenium 3 branch that returns spawn arguments unchanged, while its Grid
changelog documents driver-configuration argument support in the Selenium 4 series.

AGENTS.md: Preserve Public API and ABI Compatibility and Deprecate Before Removal
javascript/selenium-webdriver/testing/index.js[474-478]
javascript/selenium-webdriver/testing/index.js[610-625]
javascript/selenium-webdriver/remote/util.js[31-51]
java/CHANGELOG[1076-1083]

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

## Issue description
Pinned browser paths cause the test harness to pass Grid 4 configuration flags to Selenium 3 servers, which the existing server compatibility path does not translate.

## Fix Focus Areas
- javascript/selenium-webdriver/testing/index.js[474-478]
- javascript/selenium-webdriver/testing/index.js[610-625]

## Recommended Fix
Use the pinned driver-configuration flags only for servers that support them. Retain a version-compatible startup path for Selenium 3 jars and test both paths.

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


Grey Divider

Qodo Logo

Comment thread javascript/selenium-webdriver/testing/index.js Outdated
Comment thread javascript/selenium-webdriver/testing/index.js
Comment thread .github/workflows/ci-javascript.yml
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 98d21bb

@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit a062c17

Comment thread javascript/selenium-webdriver/testing/index.js Outdated
Comment thread javascript/selenium-webdriver/testing/index.js Outdated
@qodo-code-review

Copy link
Copy Markdown
Contributor

Code review by qodo was updated up to the latest commit 9cd49a0

@qodo-code-review

Copy link
Copy Markdown
Contributor

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

@pujagani
pujagani merged commit 891d5b4 into SeleniumHQ:trunk Sep 29, 2026
29 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

B-build Includes scripting, bazel and CI integrations B-devtools Includes everything BiDi or Chrome DevTools related C-nodejs JavaScript Bindings

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants