Bug 265565 – Sync and update 'WebSocket.idl' as per WebIDL Specification

• Status: NEW
• Component: DOM

[Ahmad Saleem]

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!

[Anne van Kesteren]

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!

[Radar WebKit Bug Importer]

<rdar://problem/119299711>