When its not a browser update that breaks things…

Much as I blame browser updates for breaking WebRTC things, this is not always the case. This time, the addition of a EcmaScript 7 polyfill changed our statistics.

Recently I noticed quite an increase in connections where the candidate pair type was reported as “null”:

This started on November 24th. We didn’t do any WebRTC related changes on that day. So was it a browser upgrade? Firefox 50 recently started rolling out after all. Unfortunately that turned out to have happened a week earlier. Time to dig deeper… this didn’t just affect the new version, but all versions of Firefox. A small percentage of Chrome connections was affected as well which is the baseline we saw between November 8th and 22nd in the first graph.

Drilling down to one of the affected sessions it turned out that the getStats data was no longer transmitted to the server as an Object but an empty array instead. It turns out that we were making a deep copy of the getStats result in rtcstats.js. In Firefox, this was transforming the MapLike object to an array which meant that all code iterating those reports using Object.keys no longer worked. This was rather puzzling since on other pages like the WebRTC samples this code:

var m = new Map();
JSON.stringify(m);

returned “{}” while inside an appear.in room it returned “[]”. The correct behaviour in ECMAScript 7 was the former, so why was it an array on appear.in?

With that extra information in mind it was rather easy to spot the commit that changed this. We started using babel-polyfill that day and that changed how the Map type was serialized.

Mind you that you better get used to working with the new Map objects that getStats should return. Chrome just shipped the spec-version of the stats and iterating them with Object.keys() will no longer work!