Unprefix mozRTCIceCandidate, mozRTCPeerConnection, and mozRTCSessionDescription

RESOLVED DUPLICATE of bug 1155923

Status

()

Core
WebRTC
P2
normal
Rank:
25
RESOLVED DUPLICATE of bug 1155923
5 years ago
3 years ago

People

(Reporter: emk, Unassigned)

Tracking

(Blocks: 2 bugs)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

5 years ago
We already expose an object named "RTCIceCandidate" without prefix on the global object. Even worse, |new RTCIceCandidate| throws with "RTCIceCandidate is not a constructor". This will hurt the forward compatibility (For example, look at the source of <http://net.ipcalf.com/>).
Chrome already removed the prefixed webkitRTCIceCandidate.
(Reporter)

Comment 1

5 years ago
I have no idea why test_interface.html can't detect the presence of "RTCIceCandidate"...
(Reporter)

Comment 2

5 years ago
Hm, Nightly is no longer exposing unprefixed "RTCIceCandidate". Looks like it was fixed by bug 823512.
(In reply to Masatoshi Kimura [:emk] from comment #2)
> Hm, Nightly is no longer exposing unprefixed "RTCIceCandidate". Looks like
> it was fixed by bug 823512.

Yes, as of FF24, we expose a prefixed mozRTCIceCandidate that works (the one in FF23 didn't).

I understand the goal is to remove the prefixes eventually, but I would think that would need to be a planned effort that hits all the webrtc calls at once, not just one of them.

Furthermore, some have expressed interest in leveraging that moment to introduce API changes, e.g. it may present an opportunity to do something clever with Promises for instance, that we couldn't easily do at another moment, but nothing has been nailed down as of yet.
(Reporter)

Comment 4

5 years ago
(In reply to Jan-Ivar Bruaroey [:jib] from comment #3)
> Yes, as of FF24, we expose a prefixed mozRTCIceCandidate that works (the one
> in FF23 didn't).

Actually FF23 had workable "mozRTCIceCandidate". FF24 removed unworkable "RTCIceCandidate", not added anything.
The problem is, "var RTCIceCandidate = window.RTCIceCandidate || window.mozRTCIceCandidate || window.mozRTCIceCandidate" idiom wouldn't work because of the broken "RTCIceCandidate" in FF22/23.

> I understand the goal is to remove the prefixes eventually, but I would
> think that would need to be a planned effort that hits all the webrtc calls
> at once, not just one of them.

Sure, changing the title. Also note that we already have unprefixed RTCDataChannelEvent and RTCPeerConnectionIceEvent. So things are already inconsistent.

> Furthermore, some have expressed interest in leveraging that moment to
> introduce API changes, e.g. it may present an opportunity to do something
> clever with Promises for instance, that we couldn't easily do at another
> moment, but nothing has been nailed down as of yet.

Is it practical given that Chrome already unprefixed the interface (and even removed the prefixed one)?
Summary: Unprefix mozRTCIceCandidate → Unprefix mozRTCIceCandidate, mozRTCPeerConnection, and mozRTCSessionDescription
(Reporter)

Updated

5 years ago
Blocks: 775235
Keywords: dev-doc-needed
(In reply to Masatoshi Kimura [:emk] from comment #4)
> Sure, changing the title. Also note that we already have unprefixed
> RTCDataChannelEvent and RTCPeerConnectionIceEvent. So things are already
> inconsistent.

Thanks. They were never likely to change. Chrome never prefixed them either AFAIK, only the major objects.

> > Furthermore, some have expressed interest in leveraging that moment to
> > introduce API changes, e.g. it may present an opportunity to do something
> > clever with Promises for instance, that we couldn't easily do at another
> > moment, but nothing has been nailed down as of yet.
> 
> Is it practical given that Chrome already unprefixed the interface (and even
> removed the prefixed one)?

That sounds like a scheduling question, as I don't see how Google unprefixing affects what we do technically when we unprefix, unless you're arguing we need to do this right now, in which case please say why.

Chrome still supports webkitRTCPeerConnection as well AFAICT.

Updated

4 years ago
Blocks: 1033163

Updated

4 years ago
Priority: -- → P2

Updated

3 years ago
backlog: --- → webRTC+
Rank: 25
Dup'ing the older since the newer has patches.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1155923
Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.