Bug 172867 – Can't extend RTCPeerConnection

• Component: JavaScriptCore
• Status: RESOLVED DUPLICATE

[Andrew Morris]

This code:

class PC extends RTCPeerConnection {}
const pc = new PC();
console.log(pc instanceof PC);

outputs `false`. It should output `true`. Trying to define new methods for pc via the PC prototype also fails. This prevents our attempt to use webrtc/adapter without modifying globals.

[Andrew Morris]

Also seeing this behavior, might be the same underlying issue:

```js
function Foo() {}

Foo.prototype = Object.create(RTCPeerConnection.prototype);
Foo.prototype.constructor = Foo;

console.log(RTCPeerConnection.prototype.constructor !== Foo);
```

Again, output is `false`, should be `true`.

[Radar WebKit Bug Importer]

<rdar://problem/32551195>

[Chris Dumez]

This seems like a generic JS bindings bug where we do not support having a JS class extend a platform object such as RTCPeerConnection or Document (I verified that it does not work for Document either).

[Chris Dumez]

Saam / Keith pointed me to our getDOMStructure() implementation which likely needs to be aware of the fact we're building for a subclass. Ditto for WrapperClass::createPrototype(vm, globalObject)) which likely needs to call createSubclassStructure() if needed.

I am really not familiar with this so I hope what I typed makes sense :)

[youenn fablet]

Sam/Keith, any idea for a workaround? Maybe à JS object wrapping a peerconnection, or a proxy on the peerconnection prototype...

[Keith Miller]

(In reply to Andrew Morris from comment #1)
> Also seeing this behavior, might be the same underlying issue:
> 
> ```js
> function Foo() {}
> 
> Foo.prototype = Object.create(RTCPeerConnection.prototype);
> Foo.prototype.constructor = Foo;
> 
> console.log(RTCPeerConnection.prototype.constructor !== Foo);
> ```
> 
> Again, output is `false`, should be `true`.

Based on my reading of the spec it looks like FF and Chrome are wrong here, although I could be wrong. For some reason they are adding a "constructor" property to the object returned by Object.create which is intercepting your assignment on the next line. See: https://tc39.github.io/ecma262/#sec-object.create.

(In reply to youenn fablet from comment #5)
> Sam/Keith, any idea for a workaround? Maybe à JS object wrapping a
> peerconnection, or a proxy on the peerconnection prototype...

The best workaround I can think of (which is a little annoying is to set the prototype in your constructor) i.e.

class PC extends RTCPeerConnection {
    constructor() {
        super(...arguments);
        this.__proto__ = PC.prototype;
    }
}

That should be roughly the same as RTCPeerConnection properly subclassing.

[Keith Miller]

Created attachment 312077 [details]
WIP

Works for RTCPeerConnection, doesn't seem to work for other Document.

[Alexey Shvayka]

Proper subclassing of WebIDL interfaces was implemented in r256716, including RTCPeerConnection.
Both code snippets in comment #0 and comment #1 now output `true`.

*** This bug has been marked as a duplicate of bug 174313 ***