New Session parameters

We had an discussion at Mozilla about capabilities, which revealed a
certain amount of confusion caused by the current model. I don't know
that it's worth changing anything at this stage, but I thought it was
worth bringing the substance of the discussion to a wider audience.

The data provided with the New Session command is intended to inform
various nodes along the chain about the kind of session that can be
created. For example with Chromedriver one can use this data to
specify the binary that should be used for the session. However the
current design is specialised to the requirements of a particular type
of intermediary node; one that routes requests across a matrix of
available remote ends. Whilst this is undoubtedly an important kind of
intermediary for many users, designing the entire command around a
particular conception of how this routing should work seems to produce
confusion. For example it is a-priori unclear what happens if I
specify a desired Chrome binary under desiredCapabilities but not
requiredCapabilities, or what happens if I put it in both. For
geckodriver the decision we have made is that you always pick from
requiredCapabilities first and then from desiredCapabilities if
nothing is found, and then fall back to a default. But there's nothing
specified to support this mode of operation for remote ends.

It's also unclear that the current desired/required split is the best
possible model for matrix selection. For example, if you were testing
a workaround for a bug that you knew was introduced in Firefox 46 and
fixed in 49, there's no way (that I know of) to say that you require
firefox >= 46 but <= 49.

It seems like one possible alternate approach here is to leave it
explicitly unspecified in the main spec what fields exist in the New
Session object. Then one would write small specs for different use
cases e.g. routing intermediaries could conform to the "capabilities"
spec that would specify the syntax and semantics for keys labeled
"desiredCapabilities" and "requiredcapabilities". One can also imagine
writing a "browser" spec that would specify keys (in the top level)
such as "binary", "profile" and other things that are common to many
browser implementations, but don't fit into the desired vs required
paradigm. In addition there would have to be some scope for extending
the values sent e.g. allowing specific implementations to take keys
like:

{
"_moz": {"some_firefox_specific_thing": [1,2,3]}
}

If that level of change is too disruptive, I think the spec should be
edited to make it clear how *browsers* are supposed to interpret
desired vs required, or to explicitly undefine the semantics of
desired vs required and just talk about the syntax.

Received on Thursday, 26 May 2016 10:58:08 UTC