27103 2014-10-19 20:56:23 +0000 Allow nested dictionaries in capabilities 2015-05-30 19:44:23 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified All All RESOLVED FIXED P2 normal --- 20860 1 vlotoshnikov public-browser-tools-testing ato dburns mike public-browser-tools-testing oldest_to_newest 113429 0 vlotoshnikov 2014-10-19 20:56:23 +0000 Section "3.1.2 Methods" specifies for method get(): "Return type: (DOMString or boolean or long), nullable". https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#methods "capabilities" dictionary also is specified to only be allowed DOMString or boolean or long values, too. Some existing drivers - to not name names - don't comply with that, e.g. browserXOptions' value below is not a DOMString or boolean or long: { "desiredCapabilities": { "browserName": "browserX", "platform": "platformY", "browserXOptions": { "browserXSetting": "customValue" } } } Should the spec change to allow the nested dictionaries (and effectively arbitrary JSON) in the capabilities? Or do we want to change existing implementations that aren't currently compliant? 113430 1 vlotoshnikov 2014-10-19 21:29:18 +0000 "proxy" capability* is also likely to be specified as a nested dictionary. * Proxy is not yet specified; https://www.w3.org/Bugs/Public/show_bug.cgi?id=26391 113443 2 ato 2014-10-20 12:21:33 +0000 The spec currently advises the use of the "-BROWSER-" (-webkit-, -moz-) prefix when introducing remote specific capabilities. And I think the current prose assumes that the capabilities is a flat one dimensional key-value map although that's not explicit in the current wording. This was done to avoid clashes with current and future capabilities (for the role interfaces) introduced by the spec. If we decide to allow nested objects, it really makes a lot more sense to allow any JSON structure including arrays. 120614 3 dburns 2015-05-30 19:43:50 +0000 This has been fixed in https://github.com/w3c/webdriver/commit/f05cbd4f94c05d17d1adef698dff319972bcbcee