Version comparison of browserVersion capability

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: ato, Unassigned)

Tracking

(Blocks 1 bug)

Version 3
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

2 years ago
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.
Reporter

Updated

2 years ago
Blocks: webdriver

Comment 1

2 years ago
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
Reporter

Comment 2

2 years ago
(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 "*"
Reporter

Comment 4

2 years ago
(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.
Reporter

Comment 5

2 years ago
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
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.