Webrtc-pc: RTCPeerConnection incorrectly adds operation overload via a partial interface

[saschanaz]

http://w3c.github.io/webrtc-pc/#method-extensions

The Web IDL spec says overloads must not be added via any partial types:

Operations must not be overloaded across interface, partial interface, interface mixin, and partial interface mixin definitions.

Instead they must be in the same interface definition.

I suggest we merge 4.4.2 and 4.4.3.1.

[alvestrand]

Merging the sections would be highly confusing.

[henbos]

Possible workaround

Real section
interface RTCPeerConnection extends RTCPeerConnectionLegacyExtension { ... }
Legacy section
interface RTCPeerConnectionLegacyExtension { ... };

[saschanaz]

Merging the sections would be highly confusing.

I think we can merge only IDLs, and keep the docs separate.

Possible workaround

AFAIK adding a different signature in a sub-interface will override the original one.

[bzbarsky]

Merging the sections would be highly confusing.

Merging the IDLs would be less confusing, because it would not have the "oh, actually the behavior is totally not what you thought" effect that you get now. That's why the restriction is in the IDL spec.

The prose can and should stay separated.

[jan-ivar]

@bzbarsky What wrong behavior would it lead to? I added a simple note, but that might not suffice if there's a significant behavior difference here.

[bzbarsky]

What wrong behavior would it lead to?

In the specific case of RTCPeerConnection, say you have code that does:

createOffer(someOptions, 5)

If you are only aware of the one-arg version of the function, you expect this to do the behavior corresponding to someOptions. With the three-arg overload in play, this will always return a rejected promise, because 5 cannot be coerced to RTCPeerConnectionErrorCallback.

[jan-ivar]

With the partial interface in the same spec document, I think it would be hard for an implementer to be unaware, especially with the note now added in https://github.com/w3c/webrtc-pc/pull/1922. Closing.

[saschanaz]

Still an incorrect IDL, though. 🤔 ReSpec may possibly warn about this case later. (https://github.com/w3c/webidl2.js/issues/138)

[jan-ivar]

@saschanaz only if you implement the optional legacy section. Separating these methods out helps clarify that they are optional to implement.

[bzbarsky]

I think it would be hard for an implementer to be unaware

The issue is whether an _author_ is aware... I understand the desire to have the optional legacy section, and I wish there were a good way to do that sort of thing in general without the corresponding confusion about what the behavior is when the optional legacy bits _are_ implemented...

(Of course in practice they are implemented by all browsers in this case, right?)

[jan-ivar]

(Of course in practice they are implemented by all browsers in this case, right?)

Safari Tech Preview (I run an ancient version because OS) has a "Develop / WebRTC / Enable Legacy WebRTC API" pulldown menu option that is off by default, but when I test it, callbacks work regardless, so who knows. Again, this is outdated info, and I don't know what they've decided in their latest version.

In any case, browsers may drop legacy features in the future based on usage telemetry.