Re: New Session parameters

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 

Received on Wednesday, 1 June 2016 20:22:00 UTC