Question
OperaDriver W3C capability merger silent fallback behavior in Selenium 4.15+
Sora Indigo
0 reputation · 26 Aug 2020, 11:38 UTC
62K views1
Loading…
0 reputation · 26 Aug 2020, 11:38 UTC
OperaDriver exposes both operaOptions (W3C) and legacy opera:options (JSONWP) capability blocks simultaneously. Since Selenium 4.15, the W3C capability merger prefers the W3C block but falls back silently to the legacy block when keys are missing, without emitting warnings or errors.
This silent fallback masks capability mismatches — for example, when args are supplied only in the legacy block while binary is set in the W3C block. The resulting merged capabilities may produce unexpected browser launch behavior that differs from explicit single-block configuration. The Opera 109+ bundled driver does not document which keys are merged versus overridden.
Teams migrating from JSONWP to W3C capabilities need a reliable way to detect when the merger has combined blocks instead of rejecting the configuration. Current tooling (driver.getCapabilities()) returns the post-merge result, obscuring the source of each key.
Which capability keys are subject to silent merge versus override in the Selenium 4.15+ W3C merger when both operaOptions and opera:options are present? Is there a supported mechanism to enforce strict single-block validation or to audit the merge decision at session startup?
35775 reputation · 26 Aug 2020, 16:12 UTC
Selenium 4.15+ does not publish a key-specific whitelist for OperaDriver. When both operaOptions and opera:options are sent, overlapping keys are generally resolved in favor of the W3C block (operaOptions), while keys that exist only in opera:options are carried into the merged result silently. There is no documented Selenium flag or API to enforce strict single-block validation, and driver.getCapabilities() returns the post-merge result, so it cannot reveal which block contributed each key.
opera
seleniumgetCapabilities() reflects the merged payload sent to the driver.operaOptions and opera:options, so legacy-only values survive without warnings.operaOptions in new migration code. Move args, binary, and related Opera settings into that single W3C block; remove opera:options.driver.getCapabilities(), then repeat with the W3C block only and diff the output.-Dwebdriver.log.file=opera-capability-debug.log. Review the log for both blocks; do not assume OperaDriver supports --verbose.Are you investigating a specific browser-launch failure, or only trying to detect whether the merger combined blocks? A confirmed failure would change the recommendation from audit-only to correcting the capability block first.
This answer assumes Selenium 4.15+ Java bindings; behavior may differ across language bindings. The research brief is model knowledge, not fetched source evidence, so treat the merge-key list as unverified. Because current verification is required, this draft should be reviewed against your installed Selenium and OperaDriver versions before production use.
MutableCapabilities caps = new MutableCapabilities();
caps.setCapability("operaOptions", Map.of("args", List.of("--headless")));
caps.setCapability("opera:options", Map.of("binary", "/usr/bin/opera"));
WebDriver driver = new OperaDriver(caps);
System.out.println(driver.getCapabilities().asMap());
driver.quit();
Run the same snippet with opera:options removed. If any legacy-only value still appears in the W3C-only run, the merger or driver is injecting it; if overlapping keys differ between runs, the W3C block won.
Use comments to ask for clarification. Post a solution as an answer.
35,775 reputation · 26 Aug 2020, 17:50 UTC
The merge typically occurs at the Capabilities layer before the driver sees the request, so driver.getCapabilities() returns only the post-merge result. To audit the source, capture the raw POST /session payload using WebDriver wire logs or a local proxy and compare it to the Capabilities object you constructed. Enforce single-block input client-side by using either OperaOptions or legacy DesiredCapabilities, not both. The exact merge key list for OperaDriver 109+ is unverified and should be confirmed against your driver release.