Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to implement and ship

79 views
Skip to first unread message

Martin Thomson

unread,
Aug 25, 2015, 4:08:03 PM8/25/15
to dev-platform
WebRTC was shipped with a prefix.

Bug 1155923 moves our codebase to non-prefixed names, but includes a
patch to restore aliases with the prefix. Thus we will expose
`RTCPeerConnection` and use that ourselves, but permit legacy code to
use `mozRTCPeerConnection`.

Maybe some day we can remove the aliases by just backing out the patch
that creates prefixed aliases, but that seems unlikely in the short
term [1][2].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1155923
Link to standard: http://w3c.github.io/webrtc-pc/
Platform coverage: everywhere
Target release: 43
Preference behind which this will be implemented: none
DevTools bug: none

Chrome and Opera ship with a 'webkit' prefix. I'm not aware of any
shipping implementation of this API in other browsers.

[1] Compatibility on the WebRTC API has been very poor in the past.
I'm not aware of any code that doesn't detect browsers based on the
prefixed names and then does something browser-specific.

[2] However, this situation has been improving rapidly. In any case,
a less-than perfect interoperability situation is no excuse for using
prefixes.

Ehsan Akhgari

unread,
Aug 25, 2015, 5:16:24 PM8/25/15
to Martin Thomson, dev-platform
On 2015-08-25 4:07 PM, Martin Thomson wrote:
> WebRTC was shipped with a prefix.
>
> Bug 1155923 moves our codebase to non-prefixed names, but includes a
> patch to restore aliases with the prefix. Thus we will expose
> `RTCPeerConnection` and use that ourselves, but permit legacy code to
> use `mozRTCPeerConnection`.

Is our RTCPeerConnection and the corresponding spec considered as stable?

> Maybe some day we can remove the aliases by just backing out the patch
> that creates prefixed aliases, but that seems unlikely in the short
> term [1][2].

Do the aliases only work when you call them or can the webpage also
detect them? IOW, what would code like below do?

if (window.mozRTCPeerConnection)
foo();
else if (window.RTCPeerConnection)
bar();

Martin Thomson

unread,
Aug 25, 2015, 5:45:08 PM8/25/15
to Ehsan Akhgari, dev-platform
On Tue, Aug 25, 2015 at 2:16 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2015-08-25 4:07 PM, Martin Thomson wrote:
>>
>> WebRTC was shipped with a prefix.
>>
>> Bug 1155923 moves our codebase to non-prefixed names, but includes a
>> patch to restore aliases with the prefix. Thus we will expose
>> `RTCPeerConnection` and use that ourselves, but permit legacy code to
>> use `mozRTCPeerConnection`.
>
> Is our RTCPeerConnection and the corresponding spec considered as stable?

Stable enough to use the name, certainly [see
https://tools.ietf.org/html/rfc6648]. But maybe that wasn't your
question...

The core parts of the spec are stable and have been for years. There
are parts that are still unstable. I don't expect that to change
appreciably for some time, even though the W3C working group has a
goal for a big 1.0 release.

>> Maybe some day we can remove the aliases by just backing out the patch
>> that creates prefixed aliases, but that seems unlikely in the short
>> term [1][2].
>
> Do the aliases only work when you call them or can the webpage also detect
> them? IOW, what would code like below do?
>
> if (window.mozRTCPeerConnection)
> foo();
> else if (window.RTCPeerConnection)
> bar();

The following code would call foo(). In the patch that I have,
mozRTCPeerConnection looks exactly like RTCPeerConnection. That means
that window.mozRTCPeerConnection is present, can be instantiated, can
be tested with instanceof, and can be passed to any functions that
accept RTCPeerConnection (there aren't any that I can think of there).

The only difference I'm aware of is that constructing the prefixed
version drops a polite warning (using document->WarnOnceAbout()) into
the console.

Ehsan Akhgari

unread,
Aug 26, 2015, 9:37:05 AM8/26/15
to Martin Thomson, dev-platform
On 2015-08-25 5:45 PM, Martin Thomson wrote:
>>> Maybe some day we can remove the aliases by just backing out the patch
>>> that creates prefixed aliases, but that seems unlikely in the short
>>> term [1][2].
>>
>> Do the aliases only work when you call them or can the webpage also detect
>> them? IOW, what would code like below do?
>>
>> if (window.mozRTCPeerConnection)
>> foo();
>> else if (window.RTCPeerConnection)
>> bar();
>
> The following code would call foo(). In the patch that I have,
> mozRTCPeerConnection looks exactly like RTCPeerConnection. That means
> that window.mozRTCPeerConnection is present, can be instantiated, can
> be tested with instanceof, and can be passed to any functions that
> accept RTCPeerConnection (there aren't any that I can think of there).
>
> The only difference I'm aware of is that constructing the prefixed
> version drops a polite warning (using document->WarnOnceAbout()) into
> the console.

Hmm, I see. Have you considered the implications of making the alias
falsey in conditions, similar to document.all? Without doing that, we
would never know if the bar() path in the above example will break
content when we remove the alias.

Also, I think it's probably a good idea to add a use counter for the
aliased name.

Adam Roach

unread,
Aug 26, 2015, 10:08:24 AM8/26/15
to Ehsan Akhgari, Martin Thomson, dev-platform
On 8/26/15 08:36, Ehsan Akhgari wrote:
> Have you considered the implications of making the alias falsey in
> conditions, similar to document.all?

The issue with doing so is that we see code in the wild that looks like
this:

|var NativeRTCPeerConnection = (window.webkitRTCPeerConnection || ||window.mozRTCPeerConnection);|

And a falsey value would simply make things not work.

For all the cases I can think of (at least, in short order), making the
alias falsey breaks as many things as simply removing it.

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863

Ehsan Akhgari

unread,
Aug 26, 2015, 10:57:15 AM8/26/15
to Adam Roach, Martin Thomson, dev-platform
On 2015-08-26 10:08 AM, Adam Roach wrote:
> On 8/26/15 08:36, Ehsan Akhgari wrote:
>> Have you considered the implications of making the alias falsey in
>> conditions, similar to document.all?
>
> The issue with doing so is that we see code in the wild that looks like
> this:
>
> |var NativeRTCPeerConnection = (window.webkitRTCPeerConnection || ||window.mozRTCPeerConnection);|
>
> And a falsey value would simply make things not work.
>
> For all the cases I can think of (at least, in short order), making the
> alias falsey breaks as many things as simply removing it.

That's fair.

Ms2ger

unread,
Aug 26, 2015, 11:26:50 AM8/26/15
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/26/2015 03:36 PM, Ehsan Akhgari wrote:
> Hmm, I see. Have you considered the implications of making the
> alias falsey in conditions, similar to document.all?

No. No. Nononononono.

Ms2ger
-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJV3dq3AAoJEOXgvIL+s8n2LvwIAIgP8Sw0LUU7ietAmwMPzQGU
QykxqEWJr7Y/O+rSU2FmmXzeZWzBRtlh67F5V6yGPPgdljXEtq2pbQjhN3GCM1M/
k7ix7exbJVypy5Xi3NlXIxTaT0leCBImKhZGvkkRfiNap8meWglbFqEY228rNa8M
hw9o5tRvjuhX4INU06ihlvqt/sCJqhyyy5o/ggM2xbuTO0IvksTK4SlGuaK9rxAX
uQDIh+ss7Xv0Cex1izPOOeQkJnyPQtUB7wzf5WSHVXoSh63SDx7MhQ0BFKTOaVVp
PYmW5pndDi4657lzmbzTaW1t418RmvQZ5/RfmKbJJyVAKqnQQ6+/4fGdxE814/M=
=+/Wn
-----END PGP SIGNATURE-----
0 new messages