Closed marcoscaceres closed 1 month ago
Filed Gecko bug.
@martinthomson, @beverloo, looking for interest from a second implementer (and no objections from the third).
Does this have tests?
I couldn't find any existing tests to extend here, presumably due to https://github.com/w3c/push-api/issues/365. So I haven't written any tests for this. Happy to do so if there's a way to do it.
I'm against any significant extension without having a test coverage, but this one is small enough that I guess it's fine given the situation.
We will at least get some limited testing just through the IDL interface. Sadly, most of Push is untested.
Yeah, having some coverage here is in my wishlist. Anyway consider this comment as +1 from Mozilla.
With a +1 from Mozilla and an implementation in Webkit is there anything blocking this from landing? Does it need a statement of non-opposition from Chrome?
We're happy with this, thank you! I'll try to get the change included in Chrome 128.
@bakkot
Does it need a statement of non-opposition from Chrome?
That's correct 👍 It's part of WebApp's working mode. We are all about Team Web! 🥰
implemented in Gecko, as per referenced Mozilla issue 🥳.
Closes #369
The Fetch API is getting a
Uint8Array
-returningbytes()
method alongside its existingarrayBuffer()
method, following the principle that APIs should generally vend byte buffers asUint8Array
s.This PR makes the same change for
PushMessageData
, which has its own distinctarrayBuffer
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
andapplicationServerKey
vendArrayBuffer
s instead ofUint8Array
s, but it's too late to fix those now.The following tasks have been completed:
Implementation commitment:
Preview | Diff