Add bytes() method for reading bytes into a Uint8Array

[bakkot]

Edit: Replaced by #370.

---

The Fetch API is getting a Uint8Array-returning bytes() method alongside its existing arrayBuffer() method, following the principle that APIs should generally vend byte buffers as Uint8Arrays.

This PR makes the same change for PushMessageData, which has its own distinct arrayBuffer method.

I'm assuming this is uncontroversial given the support from the three major implementations for doing this on Body, but I can open an issue and solicit explicit support separately if you'd prefer. I'll write tests if I get a signal that this is able to go forward.

It's unfortunate that getKey and applicationServerKey vend ArrayBuffers instead of Uint8Arrays, but it's too late to fix those now.

• Modified Web platform tests (link to pull request)

Implementation commitment:

• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
• WebKit (https://bugs.webkit.org/show_bug.cgi?id=274119)

---

Preview | Diff

[bakkot]

I couldn't find any existing tests to extend here, presumably due to #365. So I haven't written any tests for this. Happy to do so if there's a way to do it.

[martinthomson]

This looks fine. IPR commitments, less so. The IPR bot points to the necessary instructions.

[marcoscaceres]

Pinging @martinthomson and @beverloo for input and additional implementer support.

This is implemented in WebKit (thanks @annevk)

@bakkot, argh... small blocker on IPR, as this is substantive contribution. I'll need you to "make a non-member patent licensing commitment" unless you somehow join the working group. I'll see how we make that as painless as possible (hi @siusin, can you help us!).

[bakkot]

Signing such a commitment may be problematic since I do work for a web technologies company which is not a W3C member, even though this work was not done on their behalf. Given that this PR is basically trivial and involved no decisions, I'd prefer not to bother the lawyers just for this. I am happy to close it and let a member make an identical PR if it really can't be marked as non-substantive.

[marcoscaceres]

@bakkot, ok... sounds good.

Coincidently, I had the same idea! 😜
#370

[bakkot]

Sweet, thanks.

Closing in favor of #370.

[marcoscaceres]

Thanks for doing the actual work bakkot!

[anssiko]

This issue was brought to my attention.

I believe @martinthomson in #369 (review) was alluding to https://www.w3.org/2003/12/22-pp-faq.html#non-participants

If joining is not an option, an alternative mechanism available is https://www.w3.org/2023/Process-20231103/#contributor-license

As per the W3C Patent Policy it is generally not appropriate for a WG participant to take a substantive change proposed by a non-participant and merge it on behalf of the non-participant to a document intended to become a W3C Recommendation. This can be seen as a red flag from a Patent Policy perspective. My recommendation is to consult the W3C Team to get this addressed properly. I believe @plehegar is in the best position to help you with that.

[bakkot]

This PR was not merged and can therefore be regarded as merely making the team aware of a change to an upstream API (i.e. the WHATWG Body mixin), since the API here is generally following the shape of that upstream API. Surely it is not the case that when an outside party makes the team aware of a change to another specification that requires said party to sign a patent commitment before that information can be acted upon?

@marcoscaceres's PR implements the corresponding change in exactly the way I would have because there are no possible decisions about this change, but it was his PR which landed, not mine.