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.