Re: W3C Python WebDriver local end

> On my phone but I've been adding support for both strings and numbers as
> status codes to the standalone selenium server for a while. Try testing
> against that rather than a browser directly.

I am using selenium sever standalone 2.40.0. I am guessing that there is a
flag to configure it to use strings rather than numbers or capability that
will switch it to returning string status codes? Running -h doesn't show a
flag that will do this, and a cursory scan of the source code doesn't find
it. Can you point me in the right direction?

> We should probably allow an empty payload to indicate an empty response
> but I can see the argument for consistently returning an empty Json object.

If we want to allow empty responses we should document it :-) The spec also
states that every request should include a Json command payload, but this
is obviously not the possible with the way the API is currently used
(specifically, GET and DELETE requests can't contain a Json payload). I
will add a bug saying we need to fix this.

Finally, the selenium server is pretty generous about what it accepts. Add
> the command name and session I'd and I bet it'll work.

Not generous enough :-) The problem is not the extra fields for command
name and session (at least I presume it is not), but that the parameters
have been moved down a level. To be more concrete, findElements currently
has payload as follows:
{ 'how': 'cssSelector, 'using': '#myId' }
but in the spec it should be:
{ 'name': 'findElements', 'sessionId': '<id>', 'parameters': { 'how':
'cssSelector, 'using': '#myId' } }

Note that 'how' and 'using' are no longer at the top-level of the Json, and
selenium doesn't know to look inside the 'parameters' field for them.


Received on Saturday, 8 March 2014 16:56:10 UTC