[🐛 Bug]: [bidi] Generated layers don't hold numbers to their declared ranges #18195

Tracking

• JavaScript: <PR #>
• Python: <PR #>
• Ruby: [rb] hold BiDi numbers to their declared ranges #18198
• Java: <PR #>

Description

Follow-on from #18194

ADR 17786 decision 4 holds every value to its declared type, and decisions 5 and 7 enforce that before sending and on receipt. A CDDL range or .ge / .gt bound is part of a number's declared type, and that PR carries those bounds into the shared schema as min / max / exclusiveMin / exclusiveMax. No generated layer reads them yet. .NET is left out because its BiDi layer is hand-written.

Bounded fields

A value below min, above max, or equal to an exclusive bound should error before sending and raise on receipt. 38 fields declare their own bounds (browsingContext.LocateNodesParameters.maxNodeCount: (js-uint .ge 1), browsingContext.SetViewportParameters.devicePixelRatio: (float .gt 0.0), emulation.GeolocationCoordinates.heading: (0.0...360.0)), and about 100 more reference js-int or js-uint, whose bounds a field's own bounds narrow. Of the fields a browser sends, only session.ManualProxyConfiguration.socksVersion declares its own bound; the rest are js-int or js-uint.

Tests should cover the edges in both directions: maxNodeCount 0 and 1, devicePixelRatio 0, heading 360, and a negative network.ResponseData.status on receipt.

Bounded union arms in lists and maps

The only bounded list elements and map values sit in a union: browsingContext.PrintParameters.pageRanges is a list of js-uint / text, and the Firefox vendor session.CapabilityRequestFirefoxOptions.prefs is a map of text / bool / js-int. A union arm's bounds apply wherever a binding checks that arm; where a binding doesn't check these elements or values yet (#18193, #18106), the bounds come with that fix.

Binding Implementation Suggestions

JavaScript

Check the bounds in validateValue (javascript/selenium-webdriver/bidi/serialization/record.js:32), in the primitive branch (:42) and on a ref node after its alias resolves (:148), since {ref: 'js-uint', min: 1} only checks the alias's bounds there. Both directions go through validateValue, and the generated metadata already carries the bounds. pageRanges follows, since validateValue already checks union list elements. prefs doesn't: the generator passes defineRecord only extensible (javascript/selenium-webdriver/generate_bidi.mjs:893), so a field-less map record's values go unchecked, a gap #18106 doesn't list.

Python

In the generator, combine a field's bounds with those of the alias chain _leaf_primitive follows (py/generate_bidi_protocol.py:659) and emit them through _wire_args (:842); today maxNodeCount renders as meta("maxNodeCount", primitive="int"). Carry them on _Wire (py/selenium/webdriver/common/_bidi/serialization.py:89) and check them in _validate_outbound_scalar (:499) and _read_scalar (:401). pageRanges waits on #18193 (it is list[Any]) and prefs on #18192.

Ruby

In the generator, combine a field's bounds with those of its alias chain beside leaf_primitive (rb/lib/selenium/webdriver/bidi/support/bidi_generate.rb:1119) and emit them with the field facts (:389); today maxNodeCount renders as {wire_key: 'maxNodeCount', required: false, primitive: 'integer'}. Carry them on Record::Field (rb/lib/selenium/webdriver/bidi/serialization/record.rb:32) and check them in check_outbound_primitive (:207) and check_primitive (:290). prefs already renders as map: %w[string boolean integer] and is checked by check_outbound_map (:216) and check_map (:300), so its integer arm can carry js-int's bounds now; pageRanges waits on #18193.

Java

Replace the js-int / js-uint name checks (java/src/org/openqa/selenium/bidi/BiDiGenerator.java:1407, :1484) with the schema's bounds, following aliases and applying the field's own. Today only a field typed directly as js-int or js-uint is checked, so maxNodeCount: 0 passes and socksVersion, devicePixelRatio, and every number bound go unchecked. The generated constructor serves both directions, so one check covers both. pageRanges waits on #18193 (it is List<Object>); Java doesn't generate the Firefox vendor types, so prefs doesn't apply.