Re: [webrtc-pc] negotiationneeded may still fire when it shouldn't (#2477)

A basic **solution A** to the first problem may be to introduce yet another internal slot: **[[NegotiationBegun]]**, but setting and clearing it may get messy. And it doesn't address the 2nd.

A **solution B** might solve both: (Collapse the whole algorithm into one _queued-then-chained task_)

 _"Queue a task to [chain](https://w3c.github.io/webrtc-pc/#dfn-chain) the following steps to connection's operations chain:_
 1. _If connection.[[IsClosed]] is true, abort these steps._
 2. _If connection's signaling state is not "stable", abort these steps._
 3. _If the result of [checking if negotiation is needed](https://w3c.github.io/webrtc-pc/#dfn-check-if-negotiation-is-needed) is false, clear the negotiation-needed flag by setting connection.[[NegotiationNeeded]] to false, and abort these steps._
 4. _If connection.[[NegotiationNeeded]] is already true, abort these steps._
 5. Set connection.[[NegotiationNeeded]] to true.
 5. _Fire an event named negotiationneeded at connection."_

This is shorter than before (10 → 6 steps), and still respects all required behaviors, I think.

**Bonus:** solution B may also mitigate https://github.com/w3c/webrtc-pc/issues/2476, since the [check if negotiation is needed](https://w3c.github.io/webrtc-pc/#dfn-check-if-negotiation-is-needed) algorithm now seems guaranteed never to run while JSEP is running in parallel.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2477#issuecomment-587607171 using your GitHub account

Received on Tuesday, 18 February 2020 18:22:27 UTC