css-meeting-bot
commented
11 months ago The Browser Testing and Tools Working Group just discussed Extension commands.
The full IRC log of that discussion
<jgraham> Topic: Extension commands<jgraham> github: https://github.com/w3c/webdriver-bidi/issues/506
<jgraham> q?
<orkon> shs96c: one of the things people want to do is to extend the specification in certain way. Later there is a discussion about WebUSB. Previously not all extensions were supported. So in WebDriver Classic we have a concept of extensions and then primarily take form of extensions command. If you are a vendor, your command begins with the well known prefix.
<jgraham> RRSAgent: make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2023/09/14-webdriver-minutes.html jgraham
<orkon> shs96c: in web driver bidi it might be more complicated, we might want to allow specifying complete modules. For example, cdp commands could be in a cdp module.
<orkon> shs96c: another place we want to do it is extensions to existing modules. E.g., adding specific methods to the browsing context. And finally the a11y conversation we would like to have additional locator strategies.
<orkon> shs96c: extensions for the spec that makes them different that they will be defined in another spec. E.g., webusb webdriver extensions will be in the web usb spec.
<jgraham> q?
<orkon> q+
<jgraham> ack orkon
<orkon> AlexRudenko: what is missing from the spec?
<shs96c> q+
<orkon> jgraham: so in bidi at the moment we talk about extensions commands but we don't have in specs what other specs can and cannot do 1) defining commands in existing modules 2) defining modules
<orkon> jgraham: for example, if I am making a command, what is the style I should use?
<orkon> jgraham: e.g., what string formatting does webdriver bidi use?
<orkon> jgraham: it would else help us to have consistency
<orkon> jgraham: another question for some places we need to add explicit extension points
<orkon> jgraham: this is how the capability matching currently works when it delegates to the webdriver spec
<orkon> jgraham: https://github.com/w3c/webdriver/issues/1701
<jgraham> q?
<jgraham> ack shs96c
<jgraham> q+
<orkon> shs96c: there is an argument that we need to add extensions to existing modules. For example, extending the new features in a namespace before moving to the spec
<orkon> shs96c: the guideline could be if the module is defined in the webdriver bidi spec, send PR to the webdriver bidi spec?
<orkon> jgraham: for vendor extensions it makes sense that they could be anywhere like parameters on existing commands. For the stuff coming from other specs, everything I saw so far can be a separate module. So it should be a preferred way for specs to do that.
<orkon> jgraham: there is an interesting non spec discussion on what tooling we need to make it work
<orkon> jgraham: with cddl documents we have no way of generating the cddl derived from another spec
<jgraham> q?
<jgraham> ack jgraham
<orkon> jgraham: there is a general agreement about it
<jfernandez> q+
<jgraham> ack jfernandez
<jgraham> https://github.com/w3c/webdriver/issues/1725
<jgraham> * Topic: https://github.com/w3c/webdriver/issues/1725
<orkon> jfernandez: regarding the syntax in extensions, there is a conflict between one that was created by Chrome. It is SPC Transaction Mode.
<jgraham> * github: https://github.com/w3c/webdriver/issues/1725
<orkon> jfernandez: I added a new extension command in order to define that permissions should not be required enumeration (?)
<jgraham> q+
<orkon> jfernandez: there is a conflict in recommendations and there is no sense to have two different enumerations with difference formats
<orkon> jfernandez: the extension we are implementing is not the spec so we can do whatever we want
<orkon> jfernandez: the only important thing is that we have an agreement on the formart
<shs96c> q+ to add some background on how the casing used in webdriver came about. Happy to skip that if there's no interest
<jgraham> ack jgraham
<orkon> jfernandez: what syntax do we want for enums?
<shs96c> q?
<orkon> jfernandez: there is an agreement that it should camel case
<orkon> jgraham: did an audit of what webdriver does
<orkon> jgraham: in webdriver bidi we use camelCase for things that look like js code (further details https://github.com/w3c/webdriver/issues/1725#issuecomment-1545817156)
<orkon> jgraham: we use lowercase in a bunch of places
<orkon> jgraham: and there are cases where we taken format from JS
<jfernandez> for refrerence, these are the casing rules defined in the W3C design principles
<jfernandez> https://w3ctag.github.io/design-principles/#casing-rules
<orkon> jgraham: proposal is that those value is camel case and we fix realm values
<orkon> jgraham: what do people think about changing realm types?
<orkon> jgraham: we could make bidi locator strategies match the new convention
<orkon> jgraham: compared to lowercase camel case allows automatic conversion
<sadym> q+
<orkon> jgraham: with lowercase it is more difficult
<jgraham> ack shs96c
<Zakim> shs96c, you wanted to add some background on how the casing used in webdriver came about. Happy to skip that if there's no interest
<orkon> shs96c: originally webdriver was taken java objects and name conventions matched Java
<orkon> shs96c: with the exception when we needed to use keys in a dictionary
<orkon> shs96c: it was before the design guidelines existed
<orkon> shs96c: for locator strategies we can change them as they are not speced
<orkon> s/speced/spec'ed/
<orkon> shs96c: similarly for error codes we could change it. Jim and I will be most affected but managable.
<jgraham> q+
<orkon> shs96c: I see no potential problems following James' proposal
<jgraham> ack sadym (IRC)
<jgraham> q?
<jgraham> ack sadym
<orkon> sadym (IRC): there are some clients that implemented parts of bidi selenium and webdriver. If we rename it, we should do it as early as possible
<orkon> shs96c: for selenium it would not be much effort. Cannot speak for webdriver.io
<orkon> shs96c: if it is the breaking change worth making for consistency, we can do it because it is still early in the spec and now is the time for changes like this
<orkon> sadym (IRC): is selenium version ties to the browser version?
<orkon> shs96c: there is a protocol converter that allows mapping enums
<orkon> shs96c: similarly we also don't pass locator names unchanged
<orkon> AlexRudenko: it is managable if it is not a difficult rename (only format changes). We could be breaking things for a while but we are not shipping it for the users so can afford it.
<JimEvans> q+
<jgraham> ack jgraham
<orkon> jgraham: sounds like we have agreement on the first part that we need to adopt camel case
<orkon> jgraham: changing chromium/firefox/tests sounds like a lot of work
<orkon> jgraham: making breaking changes is painful and hard
<orkon> jgraham: for the value types and the error types, we just say it is inconsistent for historical reasons
<sadym> q+
<orkon> jgraham: in practice no one is probably affected by the format
<orkon> jgraham: for the value types we can make an argument that it matches the constructor name conversion so that they match HTML and EcmaScript
<orkon> jgraham: that makes us consistent with other spec
<orkon> s/spec/specs/
<orkon> jgraham: hopefully no one in other specs introduces case sensitive identifies which would make us ambigious
<jgraham> ack Jim Evans
<orkon> Jim Evans: for enumerated value it is not a big deal
<orkon> Jim Evans: it is easy to map values in enums
<orkon> * in enums (for me)
<orkon> jgraham: what is the effort for renaming
<orkon> q+
<jgraham> ack next
<jgraham> ack sadym
<orkon> sadym (IRC): serialzation from our side could be complicated to rename but it is doable
<jgraham> ack orkon
<orkon> sadym (IRC): it is not a show stopper but if we have other arguments it can overweight
<orkon> AlexRudenko: probably WPT and serialization is the most effort
<jgraham> q?
<orkon> jgraham: we reached a half decision and can revisit tomorrow. Moving on to the next topic.
OrKoN
whimboo
WebDriver Classic allowed other specs & vendors to define extension commands and capabilities.
Similarly, WebDriver BiDi allows extension modules. Let’s use this issue to track such modules in other specs and repos: