Masatoshi Kimura [:emk] Reporter
	Description • 11 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.

	Masatoshi Kimura [:emk] Reporter
	Comment 1 • 11 years ago

I have no idea why test_interface.html can't detect the presence of "RTCIceCandidate"...

	Masatoshi Kimura [:emk] Reporter
	Comment 2 • 11 years ago

Hm, Nightly is no longer exposing unprefixed "RTCIceCandidate". Looks like it was fixed by bug 823512.

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 3 • 11 years ago

(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.

	Masatoshi Kimura [:emk] Reporter
	Comment 4 • 11 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)?

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 5 • 11 years ago

(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.

	Jan-Ivar Bruaroey [:jib] (needinfo? me)
	Comment 6 • 9 years ago

Dup'ing the older since the newer has patches.