- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Mar 2018 14:20:50 +0000
- To: public-webrtc-logs@w3.org
> such a weird behaviour to not fire due to user actions, it makes debug logging pretty awful... For better or worse, we have had this pattern since forever in both MediaCapture and WebRTC. I think it partly comes out of a desire meet the "minimal API" test (if it can be polyfilled, polyfill it). For instance, if we decide to fire these events, this needs to be specified exactly. Case in point, Chrome and Firefox both fire an event on pc.close, but do it [differently](https://jsfiddle.net/jib1/LvLro1wc/) (Firefox fires before `pc.close` returns, missing any close handler added right after, whereas with Chrome it works, presumably it queues a task to fire it asap?) As you point out, this assumes a monolithic application. But partly, I think this also started with streams, a container for both local and remote tracks. E.g. `stream.addTrack(track)` does not fire `addtrack` on `stream`, only `pc.setRemoteDescription` does. Here, there are arguably two informal classes of tracks (remote and local), and the `addtrack` API was added explicitly only to solve a problem with remote ones. I think these are the two factors that led us down this path. I don't think the consistency argument runs any deeper than this, but at some point we just need to pick one and stop changing our minds (and the spec). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1799#issuecomment-373392110 using your GitHub account
Received on Thursday, 15 March 2018 14:20:58 UTC