Re: New Session parameters

On Wed, Jun 1, 2016 at 9:21 PM, James Graham <james@hoppipolla.co.uk> wrote:

> On 01/06/16 20:06, Brian Burg wrote:
>
>> This sounds like a good way to enable engine features / integrations
>> programmatically, such as opening the developer tools or turning on
>> the JS debugger. Although, none of these things are “capabilities” in
>> the sense that they are either supported or not. So they don’t make
>> sense as “required capabilities” and shouldn’t be interpreted by
>> intermediary nodes.
>>
>
> Right, so as a slightly more concrete proposal, what about adding an extra
> optional key called "browser" to the body of the New Session request. This
> would have the following structure, with all fields optional:
>
> {
> "binary": <string path to browser binary>,
> "arguments": [<string command line arguments>],
> "preferences": {<preference name>: <preference value>},
> "profile": <string of base64 encoded zip of browser profile
> "proxy": <string proxy url? Or whatever is currently supported by selenium>
> }
>
> Any specific remote end would be allowed to support zero or more of these.
> Implementations could also extend this list, with the understanding that
> future standardised extensions would either have to match the existing
> usage, or choose a different name.
>
> This proposal has a number of advantages, principally simple semantics
> that don't have a desired/required split for cases where that doesn't make
> sense. They also allow local ends to cover many simple cases in a
> browser-independent way. I think the main disadvantages are that it isn't
> compatible with current Selenium, and may not be compatible with existing
> intermediary nodes. I don't know if this is considered a showstopper.
>

Somewhat late to the discussion, but better late than never :)

I'm not sure that this will work as expected. What about the case where I
leave the "browserName" capability blank (indicating I don't care which
browser I want), but provide a number of profiles for use with different
ones (eg. one for if I get a chrome instance, one if I get a firefox
instance, one for IE, one for safari, and one for opera)  This use case
suggests that the browser blob _does_ belong in one of "desired" or
"required" capabilities too --- it's either something the user absolutely
wants, or it's advisory.

The nice thing with having a separate key per blob is that we can roll out
the change slowly. Marionette would be free to add a "moz-marionette" key
and load it with this blob, MS could add "ms-edge" and "ms-ie" if necessary
and so on. Each remote end would then be responsible for processing the
blobs however they want to.

I do agree that we're now very much stretching the meaning of the word
"capability", but, I'd really like to avoid doing things that are
incompatible with existing intermediary nodes --- users and companies have
already made a large investment in their tests and infrastructure, and I
feel we should be treading carefully to help preserve that investment. If
that means some clumsy keys in data, I'm okay with that. OTOH, we've been
telling people for a long time that intermediary nodes should be altering
the contents of the JSON blobs they get. Naturally, the current Selenium
server and grid woefully ignore this. *sigh*

BTW, "proxy" doesn't feel like it should belong there, since that's not
necessarily browser specific but can often be set at the OS level (eg.
Safari on OS X)

Simon