Re: New Session parameters

This proposal will not break anyone as current implementations as chrome
has theirs in `chromeOptions` and we have been shoehorning them into
required capabilities in Gecko.

I like the proposal.

David

On 1 June 2016 at 21:21, 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.
>
>