Bug 265565 - Sync and update 'WebSocket.idl' as per WebIDL Specification
Summary: Sync and update 'WebSocket.idl' as per WebIDL Specification
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: Safari Technology Preview
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2023-11-30 00:24 PST by Ahmad Saleem
Modified: 2023-12-07 00:25 PST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ahmad Saleem 2023-11-30 00:24:40 PST
Hi Team,

While looking into WebSockets.idl file in reference to web-spec, I noticed few things:

Web-Socket: https://websockets.spec.whatwg.org/#the-websocket-interface

1) Following constructor should be as per Web-Spec:

Current:

constructor(USVString url, optional sequence<DOMString> protocols = []);

From Web-Spec:

constructor(USVString url, optional (DOMString or sequence<DOMString>) protocols = []);

NOTE: If we have second constructor to separate 'DOMString' and 'sequence<DOMString>' but then we have below issue.

> Constructor with 'protocol' while I think it should be 'protocols'. It has missing 's'. I checked 'Gecko' (Websocket.webidl) and didn't find constructor with 'protocol'.

2) 'bufferedAmount' should be 'long long' rather than just 'long':

Current:

readonly attribute unsigned long bufferedAmount;

From Web-Spec:

readonly attribute unsigned long long bufferedAmount;

3) In 'messaging' for 'send()', we have it as 'ArrayBuffer' rather than using typedef 'BufferSource' (looks cleaner IMO):

typedef (ArrayBufferView or ArrayBuffer) BufferSource;

and then:

undefined send((BufferSource or Blob or USVString) data);

rather than current four line:

    undefined send(ArrayBuffer data);
    undefined send(ArrayBufferView data);
    undefined send(Blob data);
    undefined send(USVString data);

__

I just wanted to raise so we can track all of them. I might not be able to fix this quite easily. So I will leave it for others to figure out.

Thanks!
Comment 1 Anne van Kesteren 2023-11-30 03:33:21 PST
1) Argument names are not web-exposed so don't matter. Using the specification-provided IDL is possible here, but will require more complicated C++. Not entirely clear what ends up being more efficient, but we do try for our C++ to match the specification so maybe we should do it.

2) This seems potentially worth addressing, but requires some investigation into what underlying type we use. If that's always equivalent to long or less this would not be a change worth making as it's not web-exposed either way.

3) Same as 1.


I believe that for none of these you can write a test to demonstrate Safari is different from Chrome or Firefox.

Hope that helps!
Comment 2 Radar WebKit Bug Importer 2023-12-07 00:25:13 PST
<rdar://problem/119299711>