W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2014

Re: pc.localDescription sync/async issue

From: Benjamin Schwartz <bemasc@google.com>
Date: Fri, 12 Dec 2014 14:51:21 -0500
Message-ID: <CAHbrMsC-5Ga_fcdg-2V3z_qzHM4C2-P+s_FYvZovCTWCWYZA+A@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Incidentally, Chrome 40's behavior has changed here.  Where
localDescription would previously have been null, it is now "empty" instead:

> var pc = new webkitRTCPeerConnection(null);
> pc.localDescription
RTCSessionDescription {sdp: "", type: ""}

On Fri, Dec 12, 2014 at 2:24 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> I just found out that - in our implementation - users can read
> pc.localDescription synchronously right after having called
> setLocalDescription and get the result they are in the process of setting,
> even before it has finished (!)
>
> This seems quite wrong - especially if setLocalDescription were to fail -
> but I'm not confident it's not a spec issue.
>
> Confusingly, the spec in http://w3c.github.io/webrtc-pc/#attributes says:
>
> "The localDescription attribute MUST return the RTCSessionDescription that
> was most recently passed to setLocalDescription(), plus any local
> candidates that have been generated by the ICE Agent since then."
>
> Since setLocalDescription() is asynchronous, this is ambiguous. Could this
> be worded better with regard to what it should return when
> setLocalDescription has been called but its callbacks haven't been?
>
> Hopefully it's uncontentious that it should return null or any previous
> description if there is one.
>
> .: Jan-Ivar :.
>
>
>
Received on Friday, 12 December 2014 19:51:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:42 UTC