Update Chromium versions for WebTransport API

[queengooborg]

This PR updates and corrects version values for Chromium (Chrome, Opera, Samsung Internet, WebView Android) for the WebTransport API, based upon results from the mdn-bcd-collector project (v7.1.3).

Tests Used:
https://mdn-bcd-collector.gooborg.com/tests/api/WebTransport
https://mdn-bcd-collector.gooborg.com/tests/api/WebTransportBidirectionalStream

Check out the collector's guide on how to review this PR.

---

Note: the alternative names were removed from the data because I could not find any evidence of them in Chrome 97. This data was added in #18209 but the author mentioned the data wasn't quite definitive.

[Elchi3]

Note: the alternative names were removed from the data because I could not find any evidence of them in Chrome 97. This data was added in #18209 but the author mentioned the data wasn't quite definitive so I believe it's purely incorrect.

Maybe @chrisdavidmills could review here and/or find out the definite answer.

[chrisdavidmills]

I (am pretty sure) I got these alternative names from https://web.dev/webtransport/; I thought it would be important to make sure we mention them because it would look weird to have MDN docs with one set of member names, and the official Google Chrome tutorial with different names.

However, looking again, I can no longer see usage of receiveStreams and receiveBidirectionalStreams as expected, so I think those should be removed.

I can still see mention of createSendStream(), so in my mind that one should be kept, but I'll mail the spec author/implementer and ask for insight.

[queengooborg]

However, looking again, I can no longer see usage of receiveStreams and receiveBidirectionalStreams as expected, so I think those should be removed.

I found that the article was modified in between the opening of your PR and this PR to where receive[Bidirectional]Streams is no longer referenced.

---

In regards to the BidirectionalStream, I see that the name hadn't been changed since the article file was originally created (or rather, renamed from QuicTransport) all the way back in 2020. A link to the spec is included on the page, which points to WebTransportBidirectionalStream. Additionally,

What is interesting, though, is that in the current version of the IDL for this interface, there is an ImplementedAs=BidirectionalStream attribute applied to the interface. I don't know what this attribute is supposed to do as it's not a WebIDL standard ExtAttr, but it doesn't seem to affect what name the interface is exposed with:

Looking deeper through the history, it appears that Chrome's IDL did originally call this interface BidirectionalStream, but it was renamed in late 2021, before Chrome 97 shipped in early 2022.

---

Here's what I think happened:

1. The web.dev article was written early on, when the draft was still in its early stages
2. In this early stage, interfaces had different names, for example QuicTransport vs. WebTransport
3. As the spec developed, the names of interfaces had changed, as well as specific features
4. Chrome's source code followed the updates, retaining parity with the spec
5. However, nobody updated the web.dev article in between, causing it to collect dust

[chrisdavidmills]

Good analysis, thanks @queengooborg .

In addition, I got some feedback from the implementer/spec author.

• createSendStream() is indeed a name from back in the early days when the spec was called QuicTransport.
• BidirectionalStream was changed to WebTransportBidirectionalStream around the original time the origin trial ended, which was Chrome 94 according to ChromeStatus.

So upshot is, I think we can get rid of all the alternative names without any problems.

In terms of version number, I think we could put everything at 97 except for:

• WebTransport servercertificateHashes option, which was shipped in 100 (https://chromestatus.com/feature/5690646332440576). I put this in my data correctly.
• WebTransport BTOB readers, which was shipped in 109 (https://chromestatus.com/feature/5948016536584192). This is correct in my data too.

[queengooborg]

Thanks for the confirmation, @chrisdavidmills! Would you say that these changes are good, then?

[chrisdavidmills]

Thanks for the confirmation, @chrisdavidmills! Would you say that these changes are good, then?

Yes.

[queengooborg]

Awesome, I'll consider that to be official approval for this PR and merge this for tomorrow's (today's) release!