inconsistent "mode" capabilities

[boneskull]

Does it make sense to have both rcMode and rcSendKeysStrategy? I don't think it does. It would seem that rcMode: <proxy|remote> would be sufficient, and control both regular key presses and text input behavior.

I'd also like to rename rcMode js to proxy

@jlipps

[jlipps]

hmm. the reason i chose js is because we're sending javascript to do it. the fact that we're using chromedriver is kinda beside the point (we could use direct remote debugger calls as well). it's not as if chromedriver has any kind of "remote" functions.

i'm provisionally open to combining the send keys strategy and remote mode into a single capability, i just know someone will want to pick and choose at some point though :-p

[boneskull]

at the very least i think we should be consistent with the names.

picking and choosing is only sort of possible. you can use the proxy to send keystrokes in either mode, but you can't use the remote to send keystrokes if you're not already in remote rcMpde.

another way to do it would be to just use one mode flag and provide a second command, e.g. "tizen: setValue" which does it via rc. and setValue itself is removed and instead just proxies. I'm not sure if that jives with peoples expectations about these APIs though

[jlipps]

yeah... that's probably not a bad idea. it means people can't do element.send_keys('foo') with the remote, but it was always a bit of a lie, because in rc send keys mode it didn't really matter what element you called it on.