Proposal to clarify the Blink feature launch process for WebDriver APIs

[Mathias Bynens]

Dear blink-api-owners-discuss@,

The Blink feature launch process is explicitly scoped to web-exposed changes, defined as “affecting web API behavior to the point that developers using that API need to be aware of it”. In practice, if a web page can observe the change, it needs to go through the feature launch process.

However, WebDriver and WebDriver BiDi features are conceptually very similar to such changes, although they are not directly web-exposed. To clarify expectations on feature owners, design & code reviewers, and Blink API owners, I’m proposing that the Blink feature launch process is expanded to also apply to WebDriver features implemented within the scope of the Chromium repository.

In particular, changes to ChromeDriver in the form of new, removed, or changed WebDriver commands and events, whether for WebDriver Classic or the new WebDriver BiDi protocol, are similar in all of the following ways:

• Changes to WebDriver are developer-exposed (but not web-exposed). Developers either rely on these commands/events directly in their automation scripts, or use abstractions like Puppeteer/Selenium that rely on them. Thus, similar compatibility and interoperability concerns apply as for Web-exposed features.

• WebDriver and WebDriver BiDi are Web Standards. (This is a crucial difference between WebDriver and the proprietary Chrome DevTools Protocol.) Any proposed changes must meet the same standardization bar as web-exposed features before shipping. For web-exposed changes, the feature launch process already enforces this by asking for browser vendor signals. 

There are a few differences:

• These features are not Web-exposed; web pages cannot observe them, and neither can non-developer Chrome end users.

• These features technically don’t ship in Chromium/Chrome, but rather in the separate ChromeDriver binary (open-source codebase, part of the Chromium repository). Still, the implementation behind the commands/events generally happens in Blink.

• The size of the affected ecosystem differs (billions of users vs. millions of developers). However, both ecosystems are big enough that standardization and interoperability are valid concerns.

Despite these differences, there is still so much overlap with traditional Blink features that applying the same checks and balances offered by the launch process would be really helpful.

Example

A recent example is the proposal to add Federated Credentials Management API (FedCM) support to WebDriver Classic. Currently, there is no clear process for this situation. What happened in this case was roughly:

• The FedCM feature implementers went above and beyond by proactively thinking about automation support, and coming up with a proposed specification in the form of a doc, separate from the WebDriver Classic spec.

• The ChromeDriver owners receive a CL to review, lacking any prior context (i.e. are involved at the end of the process)

• The ChromeDriver owners review the code changes.

• Even if the implementation looks solid, the ChromeDriver owners are unsure whether to ship the changes. The proposal doc is unclear as to whether other browser vendors agree with the proposed WebDriver commands, if there is a patch integrating it into the main specification, if there are any cross-cutting concerns, etc.
  
  

Under the proposed process, feature owners have more clarity on what is expected from them, and it’s also clearer who owns which aspects of the review:

• The Blink API owners would apply the usual checks and balances, including asking about signals from other browsers and status of standardization. (WebDriver feature reviews are out of scope for TAG reviews, but instead, a BT&TWG review could be requested.)

• Community members are automatically made aware of feature prototyping commencing via an Intent to Prototype, at which time they can provide feedback if they are not already aware.

• The ChromeDriver owners review the design and code changes.

Assessing vendor signals

Q: How should Blink API owners assess vendor signals for automation features?
A: The same way they already do for web-exposed features.

More concretely:

1. For any new features whose spec text has already landed in either the WebDriver or WebDriver BiDi spec, we can trust the standardization process — the proposed patches wouldn’t have landed unless the relevant Working Group consisting of browser vendors and other industry stakeholders would have reviewed, discussed, and approved them. (This is similar to how we treat JavaScript language features as part of the Intents process: TC39 Stage 3 means consensus across browser vendors, and thus meets the standardization bar for an Intent to Ship.)

2. For any new feature proposals that are unmerged PRs to the relevant spec, we’d expect to find evidence of attempts to gather and engage with other browser vendors, ideally via the WebKit/standards-positions and mozilla/standards-positions repositories.

I look forward to hearing your thoughts on this proposal.

Thanks,

Mathias Bynens

[Yoav Weiss]

Hey Mathias!

You make a compelling case regarding the parallels between these developer-exposed changes and web-exposed ones. I'd be supportive of adding developer-exposed changes to the API owners' scope.

Cheers :)

Yoav

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CADizRgbfFwHM9zK8%3DVrS_tri8by%3DW%3DGkucyFwsvW3yTihgxeGA%40mail.gmail.com.

[Chris Harrelson]

I'm also supportive of adding WebDriver APIs to our scope. I think it makes a lot of sense, thanks for proposing it it Mathias!

[Mike Taylor]

LGTM as well.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZtYmKEkVnNNgB9vTS%2BuVe-DaRPzMoNXQ%2BMbWhtencURgA%40mail.gmail.com.

[Mathias Bynens]

CL updating https://www.chromium.org/blink/launching-features/: https://chromium-review.googlesource.com/c/website/+/4567530

[Chris Harrelson]

Hearing 3 LGTMs and no objections I'm going to approve Mathias's CL. Welcome WebDriver!

[Rick Byers]

LGTM also

I think there will be nuance to figure out here in practice. Eg. how do we reason about compat risk for webdriver? 

I'm also worried about increasing the barrier to folks trying to do the right thing and add automation. Is the way we think about the right investment level in specs and consensus building the same or different in the webdriver case? In particular, what's the cost if we ship some webdriver commands that end up lacking support from other engines? How hard is it to make breaking changes for the sake of interop later? At a minimum I think our stance on vendor-prefixing is different for WebDriver, right Mathias?

I think we can tackle all these questions on a case-by-case basis with help from experts like Mathias and Philip. But I suggest we be careful to avoid falling into the trap of assuming the cost/benefit tradeoffs (and so the bar we apply) is the same.

Rick

[Mathias Bynens]

There’s precedent for vendor-prefixed commands in ChromeDriver (example).

• If there’s a public spec proposal with strong cross-vendor buy-in, we might be able to ship the command unprefixed.
• In cases where there’s less certainty, we might opt to land a vendor-prefixed version first until we can gather more concrete feedback/signals.

I’d expect most cases to lie somewhere in between these two extremes, and I agree we’d need to tackle these questions on a case-by-case basis. In general, we should maintain a high bar for shipping a non-vendor-prefixed WebDriver command.

[Rick Byers]

Makes sense to me along with the vendor-prefixed escape-hatch option, thanks Mathias.

Rick

[Nicolás Peña Moreno]

Hello API OWNERS,

Is there ChromeStatus support for this decision? It seems to me that a lot of the fields from ChromeStatus do not apply to WebDriver changes, yet it seems a ChromeStatus field is needed since an I2S is needed for these changes. In my opinion, without proper ChromeStatus support to help browser developers do the actually relevant work in these cases, this adds excessive burocratic overhead to changes that are not even web-exposed and I do not agree that this is the right balance.

[Chris Harrelson]

Hi Nicolas,

On Wed, Nov 29, 2023 at 9:35 AM Nicolás Peña Moreno <n...@google.com> wrote:

Hello API OWNERS,

Is there ChromeStatus support for this decision?

Yes! We have approved it and updated the documentation accordingly.

 

It seems to me that a lot of the fields from ChromeStatus do not apply to WebDriver changes, yet it seems a ChromeStatus field is needed since an I2S is needed for these changes. In my opinion, without proper ChromeStatus support to help browser developers do the actually relevant work in these cases, this adds excessive burocratic overhead to changes that are not even web-exposed and I do not agree that this is the right balance.

Could you clarify which fields are not relevant, and file a bug here? If needed we could make a new ChromeStatus feature flow to streamline webdriver feature launches.

[Nicolás Peña Moreno]

Filed https://github.com/GoogleChrome/chromium-dashboard/issues/3524.