- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 1 Jun 2016 21:21:35 +0100
- To: Brian Burg <bburg@apple.com>, Clay Martin <clmartin@microsoft.com>
- Cc: "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
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.
Received on Wednesday, 1 June 2016 20:22:00 UTC