1258725 - RTCIceCandidatePairStats.priority is wrong

Status: NEW

(Core :: WebRTC: Signaling, defect, P3)

Description

[Byron Campen [:bwc]]

For some reason, the values in JS do not match the values fed in from C++, although they are close (eg; 9115005270282338815 vs 9115005270282338000). It looks like we're getting some sort of precision loss in here somewhere.

Comment 1

[Byron Campen [:bwc]]

I've verified that the priority values were correct when they were passed off to the autogenerated code (based on webidl), so this is probably outside of our purview, unless "unsigned long long" is the wrong thing to be using in webidl.

Comment 2

[Boris Zbarsky [:bzbarsky]]

JS only has double-precision floating point as a numeric type.  So "unsigned long long" in IDL really means "53-bit integer" in practice.

If the API is relying on exact representation of integers that don't fit in 53 bits, it's a spec bug.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I assume the relevant spec is http://w3c.github.io/webrtc-stats/#widl-RTCIceCandidatePairStats-priority (though our IDL does not link to this; that needs to be fixed).

And that links to https://tools.ietf.org/html/rfc5245#section-5.7.2

Can we control what G and D are there, and make sure they fit in 26 bits?  I guess we're using https://tools.ietf.org/html/rfc5245#section-4.1.2.1 so we can't unless we change away from doing that.  Especially because 65535 is explicitly listed as a required-to-be-supported highest preference value.

Seems to me like we need an issue on the RFC or an issue on the webrtc-stats spec to expose the value in a way that can actually be represented in JS (e.g. two 32-bit ints) or just accept that this attribute will lie...

Comment 4

[Byron Campen [:bwc]]

Yeah, there's nothing we can do to control the range of these values, since the upper 32 bits come from the remote end half the time. I would not be happy letting it lie; there will be a way to get the correct value, standardized or not, because debugging what is happening can be very hard if these values are incorrect. We would need to break it up, I think.

Comment 5

[Bulk Bug Changes for mreavy's org]

Mass change P2->P3 to align with new Mozilla triage process.