Allow WebDriver Classic commands to be called directly

[shs96c]

Some specifications have extended WebDriver Classic. They have not (and may not) added commands for WebDriver Bidi. Nonetheless, it would be useful to be able to allow these commands to be executed from Bidi.

It's suggested that we add a new classic module, with a single command to execute a known classic command by name and parameters, with a single event which would contain the return value of that command once execution was complete.

[OrKoN]

Can it be a BiDi extension in the WebDriver classic spec? My reasoning is that not every BiDi implementation might have an ability to call into WebDriver Classic.

[whimboo]

Yeah, that would be a problem with Firefox given that the WebDriver classic protocol will not work with Marionette and we do not bundle a BiDi mapper like feature to geckodriver (yet). As such we cannot easily switch between both protocols.

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Enable calling Classic commands directly from Bidi, and agreed to the following:

• ACTION: review existing standards that have webdriver extensions
• ACTION: provide guidelines on how design BiDi extensions

The full IRC log of that discussion

<jgraham> Topic: Enable calling Classic commands directly from Bidi
<orkon> ScribeNick: orkon
<jgraham> github: https://github.com//issues/546
<orkon> shs96c: motivation: there are specs out there that we don't if they will be updated
<orkon> shs96c: it will be useful to call those sections directly from webdriver bidi
<sadym> q+
<orkon> shs96c: otherwise you won't be able to use some of the features
<jgraham> q+ to clarify the design proposal
<orkon> ack next
<orkon> sadym (IRC): do I understand it right it does not make sense to put it into the classic extension to bidi?
<orkon> shs96c: but we want bidi to call into webdriver classic
<orkon> ack next
<Zakim> jgraham, you wanted to clarify the design proposal
<orkon> jgraham: I think it functionally does not make any difference where the spec goes
<orkon> jgraham: just to clarify what you are thinking: let's take an example from the existing spec, something like getAllCookies. So the proposal would be to have a module in bidi to have a module called classic that will say with prose that it defines a command for each classic spec.
<orkon> shs96c: no, the suggestion is to have the classic module with a single command that takes the parameter, the url template, and values of the parameters.
<orkon> jgraham: so it will be modelling HTTP directly?
<orkon> q+
<orkon> jgraham: so you send this command it will response with the command from the classic
<sadym> Q+
<orkon> jgraham: it will be basically saying for each command re-implement the classic command
<whimboo> q+
<orkon> shs96c: I imagining that I will be connecting via chromedriver and geckodriver. So this module can use existing code paths.
<orkon> jgraham: a reasonable question: if you have both http and bidi session, would it make sense to have that?
<orkon> shs96c: not sure I have a good answer
<orkon> jgraham: probably it is not so much more work to update the specs
<orkon> shs96c: I just want to have no regression in capabilties
<orkon> ack next
<jgraham> ack orkon
<jgraham> orkon: Not all BiDi implementations will have access to classic, and if they have access to classic it's not clear that it's much different to just use BiDi.
<jgraham> s/use BiDi/use classic/
<orkon> q?
<orkon> jgraham: potential problem is that changing to async semantics would cause trouble
<orkon> q?
<orkon> ack next
<orkon> sadym (IRC): my concern is that the assumption that not all bidi implementations have a way to invoke classic and that makes the proposal to not acheive its goal
<orkon> q?
<orkon> ack next
<sadym> q+
<shs96c> q+
<orkon> whimboo: that is something complicated especially in our case. But passing classic commands via bidi won't be possible for us. First, we have HTTP web driver and our protocol managers will not be compatible
<orkon> whimboo: we will need to do a big rewrite
<jgraham> q+
<orkon> whimboo: if you need to send some http request from bidi because bidi runs in the browser and if we are testing on the mobile devices and we will need to issue http requests there. Not sure if it is easy enough.
<orkon> whimboo: how much time would cause us to implement this compared to the converting and implementing specs
<orkon> whimboo: so the number of missing APIs from classic is reducing step by step
<orkon> q?
<orkon> ack next
<orkon> sadym (IRC): even though not all the servers have classic. ChromeDriver technically can do what you describe. We have two implementations ChromeDriver and mapper. In mapper it is not possible. But it can be in ChromeDriver.
<orkon> q?
<orkon> ack next
<orkon> shs96c: I am going to suggest that we drop this idea and have an action to review existing standards that have webdriver extensions
<orkon> ACTION: review existing standards that have webdriver extensions
<orkon> q?
<jgraham> q-
<orkon> ACTION: provide guidelines on how design BiDi extensions

[shs96c]

The action items added provide an alternative to this issue. Closing, as this is no longer relevant.