PSA: WebDriver changes now go through the API owners intent process

[Chris Harrelson]

TL;DR: going forward, new WebDriver Classic and WebDriver BiDi APIs in Chromium need to go through the Intent process, including in particular Intent to Prototype and Intent to Ship.

See here for a more detailed description of and motivation for the changes.

Thanks,

Chris, on behalf of the API owners

[Raphael Kubo da Costa]

Op 31-05-2023 om 20:44 schreef Chris Harrelson:

> TL;DR: going forward, new WebDriver Classic and WebDriver BiDi APIs in
> Chromium need to go through the Intent process, including in particular
> Intent to Prototype and Intent to Ship.
>
> See here

> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/SYA56RETDGc/m/yicXrX3qAAAJ> for a more detailed description of and motivation for the changes.

Hi Chris,

Could you elaborate on how the Intent process would apply in terms of
timelines and if some equivalent of a runtime flag would be required?

Looking at the blink-api-owners-discuss thread, I see a focus on
getting more clear vendor signals as well as notifying everyone earlier
with an Intent to Prototype email.

What's unclear to me is whether there's also supposed to be a minimum
amount of time/milestones between an Intent to Prototype and an Intent
to Ship in this case, and also what the difference between an I2P and an
I2S would be here, as there doesn't seem to be a way to gate new
ChromeDriver endpoints and commands behind a flag.

[Chris Harrelson]

On Wed, Jun 7, 2023 at 9:30 AM Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

Op 31-05-2023 om 20:44 schreef Chris Harrelson:
> TL;DR: going forward, new WebDriver Classic and WebDriver BiDi APIs in
> Chromium need to go through the Intent process, including in particular
> Intent to Prototype and Intent to Ship.
>
> See here
> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/SYA56RETDGc/m/yicXrX3qAAAJ> for a more detailed description of and motivation for the changes.

Hi Chris,

Could you elaborate on how the Intent process would apply in terms of
timelines and if some equivalent of a runtime flag would be required?

There are no minimum or maximum amounts of time required before shipping. Just like with other features, landing code for a new feature requires an Intent to Prototype before doing so, and likewise an Intent to Experiment or Intent to Ship is needed before an origin trial or shipping.

What's unclear to me is whether there's also supposed to be a minimum
amount of time/milestones between an Intent to Prototype and an Intent
to Ship in this case, and also what the difference between an I2P and an
I2S would be here, as there doesn't seem to be a way to gate new
ChromeDriver endpoints and commands behind a flag.

If that's true it needs to be fixed. Flag-guarding features is a critically necessary aspect of development best practices for Chromium features, to allow them the time to be implemented incrementally, and also to be turned off if new features cause regressions in the wild. @Mathias Bynens, could you advise on how to add runtime flags for WebDriver?

Thanks,

Chris

[Christian Biesinger]

On Wed, Jun 7, 2023 at 12:48 PM Chris Harrelson <chri...@chromium.org> wrote:

On Wed, Jun 7, 2023 at 9:30 AM Raphael Kubo da Costa <raphael.ku...@intel.com> wrote:

Op 31-05-2023 om 20:44 schreef Chris Harrelson:
> TL;DR: going forward, new WebDriver Classic and WebDriver BiDi APIs in
> Chromium need to go through the Intent process, including in particular
> Intent to Prototype and Intent to Ship.
>
> See here
> <https://groups.google.com/a/chromium.org/g/blink-api-owners-discuss/c/SYA56RETDGc/m/yicXrX3qAAAJ> for a more detailed description of and motivation for the changes.

Hi Chris,

Could you elaborate on how the Intent process would apply in terms of
timelines and if some equivalent of a runtime flag would be required?

There are no minimum or maximum amounts of time required before shipping. Just like with other features, landing code for a new feature requires an Intent to Prototype before doing so, and likewise an Intent to Experiment or Intent to Ship is needed before an origin trial or shipping.

I don't think it's possible to do an origin trial for webdriver commands. How would that work?

 

Christian

[Chris Harrelson]

Good point.

If it's not possible then Intent to Experiment would never happen for webdriver features.

 

 

Christian

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XH8NStGLR6BuhHY8dddwz72vN%2BPu7tg06-JEHvT%3DCLfqQ%40mail.gmail.com.

[Mathias Bynens]

In ChromeDriver, we don’t have feature flags per se. Instead the mechanism we have available is vendor-prefixed command mappings. Features that aren’t considered stable / have received cross-vendor buy-in should not land as an unprefixed WebDriver endpoint.

[Raphael Kubo da Costa]

Op 08-06-2023 om 05:41 schreef Mathias Bynens:

> In ChromeDriver, we don’t have feature flags per se. Instead the
> mechanism we have available is vendor-prefixed command mappings

> <https://source.chromium.org/chromium/chromium/src/+/main:chrome/test/chromedriver/server/http_handler.cc;l=206-209;drc=bdbfa8b9c04dbe680cbfb24f7ef81278c7be2604>. Features that aren’t considered stable / have received cross-vendor buy-in should not land as an unprefixed WebDriver endpoint.

I'm wondering how this would interact with WPT's testdriver.js. Assuming
an RFC has been sent and a new testdriver command is added, there's only
one dispatcher for WebDriver commands. Furthermore, when should the WPT
code start trying to use the unprefixed command assuming that would vary
across milestones?