Integration tests for generated Network BiDi domain

• Integration tests for the generated Network domain class
• Tests request/response events, interception, cache behavior, and extra headers
• Validates onBeforeRequestSent(), onResponseCompleted(), addIntercept(), and
 continueRequest() methods
• Tests both Chrome and Firefox browsers

javascript/selenium-webdriver/test/bidi/generated/network_test.js

Integration tests for generated Storage BiDi domain

• Integration tests for the generated Storage domain class
• Tests cookie management: setCookie(), getCookies(), deleteCookies() with various filters
• Validates partition key handling and domain/context-specific cookie operations
• Tests both Chrome and Firefox browsers

javascript/selenium-webdriver/test/bidi/generated/storage_test.js

Integration tests for generated Input BiDi domain

• Integration tests for the generated Input domain class
• Tests keyboard and pointer actions via performActions(), and releaseActions()
• Validates file dialog event handling with browser-specific test skipping
• Tests both Chrome and Firefox browsers

javascript/selenium-webdriver/test/bidi/generated/input_test.js

Integration tests for generated Log BiDi domain

• Integration tests for the generated Log domain class
• Tests console entry listening, JavaScript exception capture, and log entry filtering
• Validates onConsoleEntry(), onJavascriptException(), and onEntryAdded() event methods
• Tests both Chrome and Firefox browsers

javascript/selenium-webdriver/test/bidi/generated/log_test.js

Integration tests for generated Browser BiDi domain

• Integration tests for the generated Browser domain class
• Tests user context creation/removal and client window information retrieval
• Validates createUserContext(), getUserContexts(), removeUserContext(), and
 getClientWindows() methods
• Tests both Chrome and Firefox browsers

javascript/selenium-webdriver/test/bidi/generated/browser_test.js

Bazel build rules for WebDriver BiDi code generation

• Bazel macro generate_bidi_library() that orchestrates CDDL merging, TypeScript generation, and
 compilation
• Implements three-step build process: merge CDDL files, run generate_bidi.mjs generator, compile
 TypeScript to JavaScript
• Custom _compile_bidi_ts rule handles TypeScript compilation with proper output directory
 handling
• Supports enhancements manifest for per-domain customizations

javascript/selenium-webdriver/private/generate_bidi.bzl

Lock file updates for CDDL code generation tools

• Adds cddl@0.20.1 and cddl2ts@0.9.1 as dev dependencies for CDDL parsing and TypeScript
 generation
• Updates package extension checksums and adds new transitive dependencies (ast-types, recast,
 yargs, etc.)
• Removes obsolete ts-declaration-location dependency

pnpm-lock.yaml

Enhancements manifest for generated BiDi domains

• JSON manifest defining per-domain enhancements for generated BiDi modules
• Specifies deprecated compatibility wrappers (e.g., getBrowserInstance(), getNetworkInstance())
• Defines convenience method overloads for Network, Script, BrowsingContext, and Input
 domains
• Allows hand-written additions without modifying generated code

javascript/selenium-webdriver/private/bidi_enhancements_manifest.json

Bazel build integration for BiDi code generation

• Adds js_binary import for the generator script
• Defines generate_bidi_script target wrapping generate_bidi.mjs with CDDL and cddl2ts
 dependencies
• Calls generate_bidi_library() macro to generate BiDi modules from merged CDDL specs (WebDriver
 BiDi, Permissions, Prefetch, UA Client Hints, Web Bluetooth)
• Includes generated BiDi source in the npm package

javascript/selenium-webdriver/BUILD.bazel

Dev dependencies for CDDL code generation

• Adds cddl@^0.20.1 and cddl2ts@^0.9.1 as dev dependencies for CDDL parsing and TypeScript code
 generation

javascript/selenium-webdriver/package.json

pnpm workspace configuration for dependency resolution

• Adds onlyBuiltDependencies configuration
• Defines packageExtensions for transitive dependency resolution (google-closure-deps,
 minimatch, brace-expansion, recast)
• Ensures forward compatibility with pnpm v11+ by using workspace-level configuration

pnpm-workspace.yaml

Bazel build file for private BiDi enhancements

• New Bazel build file for the private directory
• Copies bidi_enhancements_manifest.json to bin directory for build-time access
• Exports the manifest file for use by the code generator

javascript/selenium-webdriver/private/BUILD.bazel

Visibility update for CDDL merge tool

• Expands visibility of merge_cddl Python binary to include
 //javascript/selenium-webdriver:__pkg__
• Allows the JavaScript BiDi code generation pipeline to use the CDDL merging tool

py/private/BUILD.bazel

WebDriver BiDi TypeScript code generator from CDDL specification

• Implements a two-pass code generator that transforms WebDriver BiDi CDDL specifications into typed
 TypeScript domain classes
• Pass 1 uses cddl2ts to generate type declarations, then post-processes to deduplicate exports
 and replace any with unknown
• Pass 2 walks the raw CDDL AST to extract commands (groups with method literal and params) and
 events, generating implementation classes with typed methods
• Generates per-domain files with cross-domain import resolution, error handling for BiDi responses,
 and support for enhancements manifest for compatibility shims

javascript/selenium-webdriver/generate_bidi.mjs

...

package.json

Description

The injected deprecated overload for Network.continueWithAuth uses non-null assertions
(username!, password!) on optional parameters, so invalid calls can produce undefined
credentials or unclear runtime failures. Protocol-derived/user inputs should be validated and
rejected with deterministic, actionable errors.

Code

javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[51]

+      "continueWithAuth": "  async continueWithAuth(params: NetworkContinueWithAuthParameters): Promise<void>\n  /** @deprecated Pass a NetworkContinueWithAuthParameters object instead — will be removed in a future major version. */\n  async continueWithAuth(requestId: NetworkRequest, username: string, password: string): Promise<void>\n  async continueWithAuth(\n    paramsOrRequestId: NetworkContinueWithAuthParameters | NetworkRequest,\n    username?: string,\n    password?: string,\n  ): Promise<void> {\n    const params: NetworkContinueWithAuthParameters =\n      typeof paramsOrRequestId === 'string'\n        ? ({\n            request: paramsOrRequestId,\n            action: 'provideCredentials',\n            credentials: { type: 'password', username: username!, password: password! },\n          } as NetworkContinueWithAuthParameters)\n        : (paramsOrRequestId as NetworkContinueWithAuthParameters)\n    await this.bidi.send({\n      method: 'network.continueWithAuth',\n      params: params as unknown as Record<string, unknown>,\n    })\n  }",

Evidence

PR Compliance ID 11 requires early validation of external/protocol/user-derived inputs and
discourages null-forgiving operators like !. The new injected method body constructs credentials
using username! and password! without checking they are present.

javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[51-51]
Best Practice: Learned patterns

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 deprecated overload implementation for `Network.continueWithAuth` uses `username!`/`password!` non-null assertions even though the implementation signature allows them to be omitted, which can lead to undefined credentials being sent or confusing runtime errors.

## Issue Context
This code is injected from the enhancements manifest and becomes part of the published/generated JS/TS API surface.

## Fix Focus Areas
- javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[51-51]

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

Description

resolveInputPath() strips the BAZEL_BINDIR prefix using a hard-coded '/' separator, which can fail
on Windows and yield incorrectly resolved input paths (often double-prefixed) inside Bazel actions.
This can make the generator fail to locate the --cddl/--enhancements inputs on Windows builds.

Code

javascript/selenium-webdriver/generate_bidi.mjs[R138-143]

+function resolveInputPath(p) {
+  if (!p) return null
+  if (!process.env.BAZEL_BINDIR) return resolve(p)
+  const prefix = process.env.BAZEL_BINDIR + '/'
+  return resolve(p.startsWith(prefix) ? p.slice(prefix.length) : p)
+}

Evidence

The generator’s prefix stripping uses a literal BAZEL_BINDIR + '/' which is not Windows-safe,
while other Bazel tooling in this repo explicitly handles Windows path differences (indicating
Windows support is expected).

javascript/selenium-webdriver/generate_bidi.mjs[128-143]
javascript/private/jsdoc.bzl[11-24]
javascript/private/closure_js_deps.bzl[49-63]

Agent prompt

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

### Issue description
`resolveInputPath()` assumes forward slashes when stripping the `BAZEL_BINDIR` prefix. On Windows, Bazel/tools often produce paths using backslashes, causing the prefix check to fail and resulting in wrong path resolution.

### Issue Context
The generator is designed to run under Bazel where `js_binary` may `chdir()` into `BAZEL_BINDIR`. Input paths expanded via `$(location ...)` need to be made relative to that CWD.

### Fix Focus Areas
- javascript/selenium-webdriver/generate_bidi.mjs[138-143]

### Suggested fix
Update `resolveInputPath` to normalize both `p` and `process.env.BAZEL_BINDIR` before prefix stripping, e.g.:
- Convert both strings to a single separator style (`replaceAll('\\', '/')`) and strip using that.
- Or use `path.normalize()` and compare using normalized strings.
- Consider using `path.posix` consistently for Bazel-generated paths if they’re always `/`-separated, and explicitly normalize `BAZEL_BINDIR`/args to posix before matching.

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

Description

The generated browsingContext navigationCommitted test asserts navEvent immediately after
navigate() completes without waiting for the WebSocket event listener to run, making the test
timing-dependent and potentially flaky. Other event tests in the same file correctly use
driver.wait(() => event !== null, 5000) before asserting.

Code

javascript/selenium-webdriver/test/bidi/generated/browsing_context_test.js[R215-229]

+      it('fires navigationCommitted on page navigate', async function () {
+        const contextId = await driver.getWindowHandle()
+        let navEvent = null
+
+        await browsingContext.onNavigationCommitted((params) => {
+          if (params.context === contextId) {
+            navEvent = params
+          }
+        })
+
+        await browsingContext.navigate({ context: contextId, url: Pages.emptyPage, wait: 'complete' })
+
+        assert.ok(navEvent, 'navigationCommitted event should have fired')
+        assert.strictEqual(navEvent.context, contextId)
+        assert.ok(navEvent.url)

Evidence

The test currently asserts immediately, while nearby event tests use explicit waits, demonstrating
the risk of event delivery racing with the assertion.

javascript/selenium-webdriver/test/bidi/generated/browsing_context_test.js[180-230]

Agent prompt

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

### Issue description
`navigationCommitted` test asserts immediately after navigation without waiting for the event callback to fire.

### Issue Context
The same file uses `driver.wait(() => event !== null, 5000)` for other event assertions (e.g., contextCreated/contextDestroyed, fragmentNavigated), so this test is inconsistent and can be racy.

### Fix Focus Areas
- javascript/selenium-webdriver/test/bidi/generated/browsing_context_test.js[214-230]

### Suggested fix
Insert:
```js
await driver.wait(() => navEvent !== null, 5000)
```
between the `navigate(...)` call and the assertions.

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

Description

The PR validates the generated BiDi bindings primarily via browser-based tests that require real
Chrome/Firefox sessions, which are slower and more failure-prone than small/unit tests. Where
feasible, generator correctness (type splitting, AST command/event extraction, manifest injection)
should be covered by small tests to improve speed and reliability.

Code

javascript/selenium-webdriver/test/bidi/generated/browser_test.js[R29-35]

+suite(
+  function (env) {
+    let driver
+
+    beforeEach(async function () {
+      driver = await env.builder().build()
+    })

Evidence

PR Compliance ID 4 prefers small/unit tests where feasible. The added tests instantiate real
browsers via env.builder().build() and explicitly run across Browser.CHROME and
Browser.FIREFOX, indicating the new coverage is primarily end-to-end rather than unit-level for
generator logic.

AGENTS.md: Prefer Unit (Small) Tests and Avoid Mocks that Misrepresent API Contracts
javascript/selenium-webdriver/test/bidi/generated/browser_test.js[29-35]
javascript/selenium-webdriver/test/bidi/generated/browser_test.js[119-121]

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 BiDi code generator functionality is exercised via end-to-end browser tests, but lacks small/unit tests that validate the generator logic deterministically.

## Issue Context
Rule prefers small/unit tests where feasible to reduce flake and runtime. Much of the generator behavior (parsing fixtures, command/event extraction, type post-processing, enhancements injection) can be verified without starting browsers.

## Fix Focus Areas
- javascript/selenium-webdriver/test/bidi/generated/browser_test.js[29-35]
- javascript/selenium-webdriver/test/bidi/generated/browser_test.js[119-121]

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

Description

Generated Domain.create(driver) calls driver.getBidi() without verifying the session supports
BiDi, so unsupported sessions can throw confusing TypeErrors (e.g., dereferencing webSocketUrl).
Existing hand-written BiDi entrypoints validate webSocketUrl first and throw a clear "WebDriver
instance must support BiDi protocol" error.

Code

javascript/selenium-webdriver/generate_bidi.mjs[R828-831]

+  lines.push(`  static async create(driver: unknown): Promise<${className}> {`)
+  lines.push(`    const bidi = await (driver as { getBidi(): Promise<BidiConnection> }).getBidi()`)
+  lines.push(`    return new ${className}(bidi)`)
+  lines.push(`  }`)

Evidence

The generated factory unconditionally calls getBidi(), while WebDriver#getBidi() assumes
webSocketUrl exists and immediately calls .replace(...) on it; existing BiDi modules explicitly
check capabilities before calling getBidi().

javascript/selenium-webdriver/generate_bidi.mjs[822-832]
javascript/selenium-webdriver/lib/webdriver.js[1308-1313]
javascript/selenium-webdriver/bidi/browser.js[29-35]

Agent prompt

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

### Issue description
Generated domain factories (`static async create(driver)`) call `driver.getBidi()` without validating BiDi support. When `webSocketUrl` is absent, `WebDriver#getBidi()` will fail with a non-actionable runtime error.

### Issue Context
The existing hand-written BiDi modules call `driver.getCapabilities().get('webSocketUrl')` and throw a clear error before attempting a BiDi connection; generated domains should match this behavior for consistency and debuggability.

### Fix Focus Areas
- javascript/selenium-webdriver/generate_bidi.mjs[822-832]
- javascript/selenium-webdriver/lib/webdriver.js[1308-1313]
- javascript/selenium-webdriver/bidi/browser.js[29-35]

### Proposed fix
In `generateClass`, emit a guard inside `static async create(driver)`:
- Check `driver` has `getCapabilities()` and that `caps.get('webSocketUrl')` is truthy.
- If not, throw `Error('WebDriver instance must support BiDi protocol')` (matching existing modules).
- Then call `getBidi()` as today.

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

Description

The generator parses the --cddl input without first validating that the resolved path exists/is
readable, which can lead to unclear failures in CI/build actions. This violates the requirement to
validate preconditions for automation scripts and fail safely with explicit errors.

Code

javascript/selenium-webdriver/generate_bidi.mjs[R171-179]

+  const cddlPath = resolveInputPath(args.cddl)
+  const outputDir = resolve(args['output-dir'])
+  const specVersion = args['spec-version']
+
+  const enhancements = loadEnhancements(args.enhancements)
+
+  console.log(`Parsing CDDL: ${cddlPath}`)
+  const ast = parse(cddlPath)
+  console.log(`  ${ast.length} top-level definitions`)

Evidence

PR Compliance ID 11 requires validating required inputs/artifacts in automation scripts. The
generator logs Parsing CDDL and calls parse(cddlPath) without an existence/readability check, so
a missing/bad --cddl path will fail without an explicit, prevalidated error.

javascript/selenium-webdriver/generate_bidi.mjs[171-179]
Best Practice: Learned patterns

Agent prompt

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

## Issue description
`generate_bidi.mjs` resolves `--cddl` to `cddlPath` and immediately calls `parse(cddlPath)` without checking whether the file exists/is readable. In CI/Bazel actions this can surface as an opaque error and may not clearly indicate the missing/incorrect input.

## Issue Context
Compliance requires validating preconditions and failing safely in automation scripts.

## Fix Focus Areas
- javascript/selenium-webdriver/generate_bidi.mjs[171-179]

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

Description

The onJavascriptLog and onBeforeRequestSent tests include tautological assertions
(entries.length >= 0 and event.request.headers.length >= 0) that always pass and therefore do
not validate the behavior or payload they claim to cover, reducing overall test effectiveness. This
conflicts with PR Compliance ID 6’s requirement to add appropriate tests for changes.

Code

javascript/selenium-webdriver/test/bidi/generated/log_test.js[R174-189]

+    describe('onJavascriptLog', function () {
+      it('can listen to javascript log entries', async function () {
+        const entries = []
+
+        await log.onJavascriptLog((params) => {
+          entries.push(params)
+        })
+
+        await driver.get(Pages.logEntryAdded)
+
+        // Trigger a JS error to produce a javascript log entry
+        await driver.findElement({ id: 'jsException' }).click()
+
+        // onJavascriptLog covers JS-level log entries
+        assert.ok(entries.length >= 0) // may or may not fire depending on driver impl
+      })

Evidence

PR Compliance ID 6 requires tests that meaningfully validate behavior changes. In the cited tests,
assert.ok(entries.length >= 0) and assert.ok(event.request.headers.length >= 0) are always true
for any array-like value (including empty arrays), so these assertions will pass regardless of
whether the generated BiDi log/network events are correct, demonstrating that the tests do not
actually verify the expected functionality or correctness of the received payload.

AGENTS.md: Add or update tests for changes; prefer small unit tests and avoid mocks
javascript/selenium-webdriver/test/bidi/generated/log_test.js[174-189]
javascript/selenium-webdriver/test/bidi/generated/network_test.js[56-60]

Agent prompt

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

## Issue description
Replace tautological assertions in the `onJavascriptLog` and `onBeforeRequestSent` generated BiDi tests that currently check only that `.length >= 0`, because these always pass and do not verify correct behavior or payload structure.

## Issue Context
PR Compliance ID 6 expects tests to validate functionality and behavior changes; assertions that are always true weaken coverage and can allow regressions in generated log and network event handling to slip through undetected.

## Fix Focus Areas
- javascript/selenium-webdriver/test/bidi/generated/log_test.js[174-189]
- javascript/selenium-webdriver/test/bidi/generated/network_test.js[56-60]

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

Description

The Bazel TypeScript compilation for generated BiDi modules uses tsc --removeComments, which
strips the generator’s injected license header and JSDoc @deprecated documentation from emitted
artifacts. This defeats the generator’s explicit intent to embed these comments and reduces
maintainability/documentation quality in the published package.

Code

javascript/selenium-webdriver/private/generate_bidi.bzl[R39-45]

+    args = ctx.actions.args()
+    args.add("--target", "ES2020")
+    args.add("--module", "NodeNext")
+    args.add("--moduleResolution", "NodeNext")
+    args.add("--declaration")
+    args.add("--removeComments")
+    args.add("--outDir", js_outputs[0].dirname)

Evidence

The generator explicitly defines a license comment block and the manifest injects JSDoc comments,
but the build rule compiles with --removeComments, which strips them from generated outputs.

javascript/selenium-webdriver/private/generate_bidi.bzl[39-45]
javascript/selenium-webdriver/generate_bidi.mjs[620-636]
javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[2-7]

Agent prompt

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

### Issue description
Generated BiDi TS files intentionally include a license header and enhancement-injected JSDoc (e.g., `@deprecated`). The custom Bazel `tsc` invocation uses `--removeComments`, which removes these comments from emitted outputs.

### Issue Context
- The generator emits `LICENSE_HEADER` into every generated domain file.
- The enhancements manifest injects JSDoc `@deprecated` wrappers/types.
- `--removeComments` removes this documentation from outputs (and may also impact `.d.ts` comment retention depending on compiler behavior).

### Fix Focus Areas
- javascript/selenium-webdriver/private/generate_bidi.bzl[39-45]
- javascript/selenium-webdriver/generate_bidi.mjs[620-636]
- javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[2-7]

### Proposed fix
Remove `args.add("--removeComments")` from the generated BiDi compilation rule so that:
- The license header remains present in distributed generated artifacts.
- Deprecation JSDoc remains available to users and tooling.

If size is a concern, consider a separate minification/strip step at packaging time rather than stripping at compile time.

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

Description

The new test navigates to http://doesnotexist.invalid/ using BiDi `browsingContext.navigate(...,
wait: 'complete')` without any explicit timeout/cancellation, which can hang or become
timing-dependent based on DNS/network behavior and BiDi readiness semantics. This can delay the
suite (potentially up to the transport send timeout) and cause non-deterministic CI failures,
violating the requirement for deterministic failure paths in async/network operations.

Code

javascript/selenium-webdriver/test/bidi/generated/network_test.js[R114-116]

+        await browsingContext
+          .navigate({ context: contextId, url: 'http://doesnotexist.invalid/', wait: 'complete' })
+          .catch(() => {})

Evidence

PR Compliance ID 11 requires timeouts/cancellation for async waits and network I/O, yet the added
test code performs an awaited navigation to an intentionally invalid host (doesnotexist.invalid)
with wait: 'complete' and no bounding timeout/cancellation wrapper. Because the test awaits
navigate(...) before it waits for errorEvent, any delayed or never-returning navigation blocks
the rest of the test (making the later 5s driver.wait(...) ineffective), and in the existing BiDi
implementation the underlying send() has a ~30s command timeout, meaning the stall can last up to
~30 seconds per run and contribute to flakiness/timeouts.

javascript/selenium-webdriver/test/bidi/generated/network_test.js[114-116]
javascript/selenium-webdriver/test/bidi/generated/network_test.js[105-121]
javascript/selenium-webdriver/bidi/browsingContext.js[162-180]
javascript/selenium-webdriver/bidi/index.js[21-21]
javascript/selenium-webdriver/bidi/index.js[200-204]
Best Practice: Learned patterns

Agent prompt

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

## Issue description
A test performs an awaited BiDi navigation to a non-existent host using `wait: 'complete'` without any explicit timeout/cancellation, so the test can hang or block for a long time (up to the transport/command timeout) before it can assert the expected fetch error event.

## Issue Context
Compliance requires deterministic failure paths (timeouts/cancellation) for async waits and network I/O. The current test intentionally navigates to `http://doesnotexist.invalid/` and swallows the navigation error, but it does not bound how long the navigation attempt itself can take; since `navigate()` is awaited before waiting for `errorEvent`, a stalled/never-completing navigation makes the later 5s `driver.wait(...)` ineffective and can slow/flake CI.

## Fix Focus Areas
- javascript/selenium-webdriver/test/bidi/generated/network_test.js[114-116]

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

Description

Generated on<Event>() helpers add a new WebSocket message listener every time they’re called and
provide no unsubscribe/cleanup mechanism, leading to leaked listeners and duplicate callbacks over
time. The listener also blindly JSON.parses incoming frames without guarding or validation,
risking MaxListenersExceededWarning and unhandled exceptions/crashes on malformed or non-JSON data.

Code

javascript/selenium-webdriver/generate_bidi.mjs[R902-918]

+  lines.push(`  async ${onMethodName}(callback: ${cbType}): Promise<void> {`)
+  lines.push(`    await this.bidi.subscribe('${methodStr}')`)
+  // Use the raw WebSocket message listener — the same pattern as the hand-coded
+  // logInspector.js / browsingContext.js classes.  bidi/index.js intentionally
+  // ignores WebSocket messages without a numeric "id" in its response dispatcher,
+  // so event payloads must be captured directly from the socket instead.
+  lines.push(`    const ws = this.bidi.socket`)
+  lines.push(`    ws.on('message', (data: { toString(): string }) => {`)
+  lines.push(`      const msg = JSON.parse(data.toString()) as {`)
+  lines.push(`        method?: string`)
+  lines.push(`        params?: unknown`)
+  lines.push(`      }`)
+  lines.push(`      if (msg.method === '${methodStr}') {`)
+  lines.push(`        callback(${paramsTypeName ? `msg.params as ${paramsTypeName}` : 'msg.params'})`)
+  lines.push(`      }`)
+  lines.push(`    })`)
+  lines.push(`  }`)

Evidence

PR Compliance ID 10 requires cleanup/rollback for async workflows that register state/resources, but
the new generateEventMethod emits code that registers a persistent WebSocket message listener
without any disposal path, so repeated on<Event>() calls accumulate listeners. PR Compliance ID 11
requires early validation of protocol-derived inputs and deterministic failures, yet the generated
handler trusts arbitrary WebSocket payloads and calls JSON.parse without try/catch or shape
checks, allowing malformed frames to throw asynchronously. The existing BiDi transport
(bidi/index.js) is cited as already documenting the MaxListenersExceededWarning risk and using a
single shared dispatcher with guarded JSON parsing, indicating the generated approach reintroduces
known failure modes.

javascript/selenium-webdriver/generate_bidi.mjs[902-918]
javascript/selenium-webdriver/generate_bidi.mjs[897-918]
javascript/selenium-webdriver/bidi/index.js[58-81]
javascript/selenium-webdriver/generate_bidi.mjs[909-916]
Best Practice: Learned patterns

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 generated `on…` event methods install a new `ws.on('message', ...)` listener on every call and never remove it, which can leak listeners, multiply callbacks, and trigger MaxListeners warnings over time. The handler also performs an unguarded `JSON.parse` on protocol-derived WebSocket frames (without try/catch or validation), which can throw on malformed/non-JSON payloads and crash or produce unclear asynchronous failures.

## Issue Context
This event-handling code is emitted into the generated BiDi domain classes and may be invoked repeatedly by consumers across many domains and events. The existing BiDi transport implementation in `bidi/index.js` already explains why adding many message listeners is problematic and uses a single shared dispatcher with guarded JSON parsing; the generator should align with that approach. Protocol/WebSocket payloads are external inputs and should be validated early to produce deterministic, actionable failures.

## Fix Focus Areas
- javascript/selenium-webdriver/generate_bidi.mjs[897-920]
- javascript/selenium-webdriver/bidi/index.js[58-81]
- javascript/selenium-webdriver/generate_bidi.mjs[909-916]

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

Description

The new genrule command constructs a shell invocation with $@ and $(SRCS) unquoted, which is
unsafe if paths contain spaces/special characters and can cause non-deterministic CI/tooling
behavior. Build/tooling scripts should use safe argument handling.

Code

javascript/selenium-webdriver/private/generate_bidi.bzl[R113-119]

+    native.genrule(
+        name = merged_name,
+        srcs = [cddl_file] + extra_cddl_files,
+        outs = [name + "_merged.cddl"],
+        cmd = "$(location " + merge_tool + ") $@ $(SRCS)",
+        tools = [merge_tool],
+    )

Evidence

PR Compliance ID 13 requires safe argument handling in build/CI/scripts/tooling. The added genrule
uses a raw cmd string with unquoted $@/$(SRCS), which is not robust to special characters in
paths.

javascript/selenium-webdriver/private/generate_bidi.bzl[113-119]
Best Practice: Learned patterns

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 `native.genrule` command string passes `$@` and `$(SRCS)` without robust quoting/argument handling, which is a common source of brittle CI behavior.

## Issue Context
Compliance requires build/tooling glue to use safe argument handling; consider replacing the genrule with a small Starlark rule using `ctx.actions.run` so arguments are passed as an argv list.

## Fix Focus Areas
- javascript/selenium-webdriver/private/generate_bidi.bzl[113-119]

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

Description

The BrowsingContext enhancement methods back() and forward() always call traverseHistory with
context: '' (empty string), so these convenience methods will consistently fail with an invalid
browsing context id.

Code

javascript/selenium-webdriver/private/bidi_enhancements_manifest.json[R12-13]
...