the latest (unpublished) version of the webrtc-stats removed the selector concept (@vr000m can you point out the PR that did this?).
It is still in webrtc-pc, "selector" is mentioned 33 times :-(
note that in some places using the word "selector" may still make sense such as
Gather the stats indicated by selector according to the stats selection algorithm.
from the rtpsender.getStats description.
@fippo I searched for the PR (see: https://github.com/w3c/webrtc-stats/pulls?page=4&q=is%3Apr+is%3Aclosed) but couldn't find what you're referring to.
Here is the latest statistics "tip of tree': https://rawgit.com/w3c/webrtc-stats/master/webrtc-stats.html
The final decision was to keep the selector and return the marching object (sender or receiver)
*Let selector be a RTCRtpSender or RTCRtpReceiver on connection which track member matches selectorArg. *
If no such sender or receiver exists, or if more than one sender or receiver fit this criteria, return a promise rejected with a newly created InvalidAccessError.
@vr00m This currently reflected in the specification, right? Just trying to figure out if there is something to fix and if so, what.
I think we're good (thankfully), I misinterpreted the lack of the word "selector" in -stats.
wait, we might have an issue in the text @vr000m cites:
http://w3c.github.io/webrtc-pc/#rtcpeerconnection-interface-extensions-2
That step (4) does not seem to cover the case that selector is null.
@fippo Opened new issue: https://github.com/w3c/webrtc-pc/issues/1374