Closed Bug 1326397 Opened 8 years ago Closed 7 years ago

Version comparison of browserVersion capability

Categories

(Remote Protocol :: Marionette, defect)

Version 3
x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: ato, Unassigned)

References

(Blocks 1 open bug)

Details

According to the WebDriver specification we need to do some form of version comparison for the browserVersion capability. The specification does however not go into specifics what version parameters we should accept or deny. The current implementation at the time of writing this ignores browserVersion altogether, but starting with bug 1282873 we will perform a simple string match similar to that for browserName and platformName: If the value is undefined, null, or "*" (wildcard) we accept it. If it is not equal to "firefox" we return an error.
Blocks: webdriver
The spec says: "If the two values do not match, return null." It does not say to return an error. These are desired capabilities, not required capabilities. If the driver can't fulfill it, so long as there isn't an error in the merging with required capabilities, it should "Return matched capabilities." Ruby has the default for these set to "any" as that is what the grid uses, and regardless, this shouldn't break that backward compatibility. Firefox 53.0a1 (2017-01-08) (64-bit) Geckodriver 0.13
(In reply to Titus Fortner from comment #1) > The spec says: "If the two values do not match, return null." It does not > say to return an error. > > These are desired capabilities, not required capabilities. If the driver > can't fulfill it, so long as there isn't an error in the merging with > required capabilities, it should "Return matched capabilities." Firstly I should point out that the specification defines firstMatch/alwaysMatch primitives which Marionette does not yet implement. Whether this should be true for desiredCapabilities/requiredCapabilities is a bit of an open question and no one in the WebDriver working group seem to agree on what the behaviour should be. You are saying that if {desiredCapabilities: {browserName: "foo"}} is sent to geckodriver, it should accept this? However, this is also not on-topic for this bug. > Ruby has the default for these set to "any" as that is what the grid uses, > and regardless, this shouldn't break that backward compatibility. "Any" is not a valid match rule according to the specification. It should be "*", "firefox", or null.
we should add "any" as that is in a lot of Selenium Grid uses that for routing. All clients, both Selenium "official" ones and non-official ones will be using that. We should update the spec to handle "any" as "*"
(In reply to David Burns :automatedtester from comment #3) > we should add "any" as that is in a lot of Selenium Grid uses that for > routing. All clients, both Selenium "official" ones and non-official ones > will be using that. > > We should update the spec to handle "any" as "*" This just shows how clearly having matching capabilities at the the driver- or browser level is pointless. I should also add that assigning arbitrary value to the string "any" means no browser name, browser version, platform name, or platform version can have that string, which seems like a fairly limiting wart.
geckodriver now implements browserVersion matching, and we are removing capabilities matching from the Marionette server in https://bugzilla.mozilla.org/show_bug.cgi?id=1387380.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.