Update webdriver-bidi with the new BCD keys

[captainbrosset]

BCD v5.7.0 introduces new keys for webdriver bidi.

The webdriver bidi feature on this repo used to be hardcoded to the following browser versions:

• chrome, chrome_android, edge: 106
• firefox, firefox_android: 102

According to comments that we left when the feature was created, these versions numbers were based on:

• https://developer.chrome.com/blog/webdriver-bidi-2023
• https://bugs.chromium.org/p/chromedriver/issues/detail?id=4016
• https://bugzilla.mozilla.org/show_bug.cgi?id=1753997

Now that BCD has webdriver bidi keys, we can remove our hard-coded values and just start using BCD keys instead. However, doing so in one go, by just adding all of the new BCD keys to our features, makes the feature unsupported on all browsers.

So, we now need to look at the various support data for each key and decide which keys should be part of the feature, which keys might need to be ignored (if any), and which keys should be considered for separate features.

[captainbrosset]

@juliandescottes it'd be great if someone close to the bidi project could take a look at this PR. Feel free to at-mention other people if needed.

One question here is: of the BCD keys in this PR, which represent an initial bidi feature, and more or less match our previously hard-coded data (see PR description).

Also, are there groups of keys we can split out into separate features? Did some of these key come later and represent pieces of capability that developers can use separately from the rest?

Thanks!

[captainbrosset]

Also pinging @OrKoN and @Elchi3. Please see my previous comment. Thanks!

[OrKoN]

The WebDriver BiDi keys look good to me. In general, each feature/method could be used separately by the users depending on the use case. They could be grouped by the module (e.g., webExtension is a module) perhaps? I am not sure how this data will be used so I am not sure if it makes sense. cc @sadym-chromium

[sadym-chromium]

The WebDriver BiDi keys look good to me. In general, each feature/method could be used separately by the users depending on the use case. They could be grouped by the module (e.g., webExtension is a module) perhaps? I am not sure how this data will be used so I am not sure if it makes sense. cc @sadym-chromium

I find this is a great starting point, which can be updated/fixed in case of some inaccuracy.

[captainbrosset]

@ddbeck I had a very informative discussion with @juliandescottes where he went over each and every key told me what each one covered and whether it was important for a basic usage of WebDriver BiDi.

Based on this, I left a lot of comments for posterity, and moved a few keys only to compute_from to pin the feature to its most basic subfeatures.

In doing so, I was still getting no browser supported in the dist file. So I ended up commenting out a bunch of keys, and later found out that they were causing this status mostly because they are marked as partially supported in BCD for Firefox.

I understand that this might change soon, as some/all of the features for these commented out keys are actually supported in Firefox, modulo some minor edge cases. So the data in BCD might change soon, and we might be able to uncomment some of the compute_from keys.

Let me know what you think of this approach. We could also simplify the compute_from block and pin it to these simpler keys:

• webdriver.bidi.session
• webdriver.bidi.script
• webdriver.bidi.browsingContext

(although these act as "container" features in BCD and don't actually match with anything a developer might do)

[whimboo]

@captainbrosset regarding the partial status for some of the commands and events in Firefox I can say that it means: The API to call this command or get such an event is present. It's just that not all properties are implemented.

So if you want to create something for baseline you probably can take the partial status as implemented in the browser. Only started and not started means the feature is not present.

For me it's currently helpful information to see which commands are fully completed and which aren't. Especially until we have a way to as well cover the relevant payload properties as well. Adding that is quite a bit of work and I'm still not sure if the spreadsheet is the best choice for it (given that it is manually updated and might cause the script from @caugner to break completely).

So would it work for you to account partial as The API is implemented?

[caugner]

Quick update: @whimboo has started adding parameter-level implementation status to the spreadsheet.

[whimboo]

Note that for both Firefox and Chrome the versions for parameters of commands and events have been entered. So we could do another BCD update.

[whimboo]

@captainbrosset we landed the initial import for parameters via github.com/mdn/browser-compat-data/pull/26993. Please let us know if that solves all of your issues. Thanks.

[ddbeck]

I've upgraded BCD and updated the draft features (see #3122). Merging/rebasing with main ought to bring in the (many, many) new BiDi keys that have appeared in BCD.

[whimboo]

So does it mean that it looks better now? Are you satisfied or is there some entry that still needs attention? Thanks.

[captainbrosset]

I'm working on this today and will push a commit soon.

[captainbrosset]

The new BCD keys are helpful. Thank you.

I'm still having a little of trouble with the following BCD keys:

• webdriver.bidi.session.new
• webdriver.bidi.session.end
• webdriver.bidi.browsingContext.contextCreated_event
• webdriver.bidi.browsingContext.contextDestroyed_event

In my conversation with Julian, we had categorized those as critical to be able to use BiDi. However, BCD has the following data about these keys:

• webdriver.bidi.session.new: partially supported in Firefox because multiple sessions can't be created yet.
• webdriver.bidi.session.end: not supported in Chrome/Edge.
• webdriver.bidi.browsingContext.contextCreated_event: partially supported in Firefox because subscribing to this event does not emit events for all already open browsing contexts.
• webdriver.bidi.browsingContext.contextDestroyed_event: same as above.

So my question is: are these BCD keys essential to using BiDi?

[juliandescottes]

The new BCD keys are helpful. Thank you.

I'm still having a little of trouble with the following BCD keys:

* `webdriver.bidi.session.new`

* `webdriver.bidi.session.end`

* `webdriver.bidi.browsingContext.contextCreated_event`

* `webdriver.bidi.browsingContext.contextDestroyed_event`

In my conversation with Julian, we had categorized those as critical to be able to use BiDi. However, BCD has the following data about these keys:

* `webdriver.bidi.session.new`: partially supported in Firefox because multiple sessions can't be created yet.

* `webdriver.bidi.session.end`: not supported in Chrome/Edge.

* `webdriver.bidi.browsingContext.contextCreated_event`: partially supported in Firefox because subscribing to this event does not emit events for all already open browsing contexts.

* `webdriver.bidi.browsingContext.contextDestroyed_event`: same as above.

So my question is: are these BCD keys essential to using BiDi?

Thanks for checking. I guess we can consider session.end as optional, you can always end the session by closing the browser (browser.close command).

For the other ones - partially supported in Firefox - we probably should mark those as complete and create sub-items for the missing features.

[captainbrosset]

Thank you @juliandescottes.

For the other ones - partially supported in Firefox - we probably should mark those as complete and create sub-items for the missing features.

These are:

• webdriver.bidi.session.new
• webdriver.bidi.browsingContext.contextCreated_event
• webdriver.bidi.browsingContext.contextDestroyed_event

@whimboo are you planning on splitting them into sub-features in BCD, so that these keys can be marked as supported, and the new sub-feature keys can represent the more nuanced partial support?

[whimboo]

@whimboo are you planning on splitting them into sub-features in BCD, so that these keys can be marked as supported, and the new sub-feature keys can represent the more nuanced partial support?

Sorry but this mention got under the wire. I've updated session.new and the changes should already be available in BCD. For the browsing context created/destroyed events another PR will be necessary.

Does it look good otherwise?

[caugner]

Should I update our WebDriver BiDi implementation status x BCD integration to automatically set the web-features:webdriver-bidi tag on all BiDi features?

[jgraham]

I think defining webdriver-bidi as a single feature with the overall status based on only a few keys isn't likely to be very helpful. I tend to think we should split this into something closer to per-module features.

[captainbrosset]

I should revisit this. Apologies for being very slow on this.
It might help to split this up by modules. They're not all at the same level of importance. There's probably a core feature which captures at least connecting.

Constraint to keep in mind: we do have an existin bidi feature, with hard-coded status https://github.com/web-platform-dx/web-features/blob/main/features/webdriver-bidi.yml
We should probably reuse the same feature for the "core" feature, even if the status ends up being slightly different than the hard-coded one.

[captainbrosset]

This is blocked on mdn/browser-compat-data#29965 as we need webdriver.bidi.session.new to be marked as fully supported by Firefox to have a decent status.

[whimboo]

This is blocked on mdn/browser-compat-data#29965 as we need webdriver.bidi.session.new to be marked as fully supported by Firefox to have a decent status.

There was a wrong status set for this command for Firefox. I've corrected that. For more details see the comments in the referenced PR.

[captainbrosset]

I just pushed a new attempt at this PR.

The goal here is to start using webdriver bidi BCD keys in web-features, to increase our coverage of BCD.

Initially, I had included all BCD keys in one feature, and had overridden the status to more or less match the browser versions we had before.

I've changed my approach. The feature now contains only the BCD keys which are considered critical to using webdriver bidi at all (and a few spare keys which I didn't know where else to put).

This gives us Chrome/Edge 126, and Firefox 143. I think that's fine because the feature is not Baseline anyway, and it's not too far off from the initial Chrome/Edge 106 and Firefox 102.

As for the remaining keys, I will be submitting follow-up PRs for separate features. Here's the list I have in mind:

• preloadscript
• user context
• realm
• user activation
• screenshot
• download
• user prompt
• history
• node locator
• print
• viewport
• history traversal
• emulation
• file input
• log
• network
• permission
• storage
• webextension