getStats API always returns 1 for mozRTT

RESOLVED FIXED in Firefox -esr52

Status

()

defect
P1
normal
Rank:
19
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: pehrsons, Assigned: ng)

Tracking

({regression})

45 Branch
mozilla55
Points:
---

Firefox Tracking Flags

(firefox-esr45 wontfix, firefox52 wontfix, firefox-esr5254+ fixed, firefox53 wontfix, firefox54 fixed, firefox55 fixed)

Details

()

Attachments

(1 attachment)

Per the description, the values I see for the mozRTT attribute on type: inboundrtp, isRemote: false stats are always 1 in Firefox 45. In Firefox 43 it works fine.

Well, it's actually 0 the first time for audio, but after that always 1.

See the attached URL for a sample fiddle that shows getStats output.
backlog: --- → webrtc/webaudio+
Rank: 19
Keywords: regression
Priority: -- → P1
111:13.84 LOG: MainThread Bisector INFO Last good revision: cc82d9b8f949a60ba3ad9b88c8fca77513e4fa68
111:13.84 LOG: MainThread Bisector INFO First bad revision: d02f5e8ca0dc36845881530734049a064904c002
111:13.84 LOG: MainThread Bisector INFO Pushlog:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=cc82d9b8f949a60ba3ad9b88c8fca77513e4fa68&tochange=d02f5e8ca0dc36845881530734049a064904c002

Looks like it regressed with WebRTC 43.
I can also reproduce with test.webrtc.org.
Rank: 19 → 25
Priority: P1 → P2
bumping priority
Rank: 25 → 22
Quick update--this is impacting users in our production environments.  The inability to display network quality during our video calls leaves users completely blind to their signal strength.  It's a really frustrating defect.
Any updates on this bug? it is still reporting rtt=1.
Rank: 22 → 19
Priority: P2 → P1
Assignee: nobody → na-g
Comment on attachment 8849349 [details]
Bug 1241066 - fix mozRtt always 0 or 1;

https://reviewboard.mozilla.org/r/122138/#review124490

That's gold.
Attachment #8849349 - Flags: review?(jib) → review+
Very nice find.

Question: is it possible to make sure this gets on LTS version 53?  Otherwise I'm going to have to live with this bug for a very, very long time.
Firefox ESR is 52... but it can't hurt to nominate given the size. We should land it first though.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #9)
> Firefox ESR is 52... but it can't hurt to nominate given the size. We should
> land it first though.

Whoops--yes, I'm sorry, I meant 52.  If it could get to 52 for ESR, that'd be super.
What is the justification for firefox52: wontfix???  Doesn't that mean this defect is going to be in ESR for like....close to a year or something?
https://hg.mozilla.org/mozilla-central/rev/778466279711
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
We could try to land this for 54 and think about shipping it in 52.2esr - in June. Maire and Jan-Ivar, what do you think?

Jeremy, the wontfix for 52 under comment 10 was because we had already shipped 52 and 52.0esr. At that point we did have a chance to land the fix for 55 and uplift it. But somehow we missed it. I have to do the same thing this week for 52.1esr, which should release next Wednesday.
Flags: needinfo?(mreavy)
Flags: needinfo?(jib)
Comment on attachment 8849349 [details]
Bug 1241066 - fix mozRtt always 0 or 1;

Wfm. Sorry we dropped the ball.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:

Prevent regression of mozRtt feature in ESR.

User impact if declined: The mozRtt statistic will return 0 or 1 always.
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): Super-trivial fix. No risk.
String or UUID changes made by this patch: none

[Feature/Bug causing the regression]: bug 1198458
[Is this code covered by automated tests?]: Basic code coverage, validity checks only. Real-world range checks hard to automate.
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: yes
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: Not at all
[Why is the change risky/not risky?]: Smallest most innocuous patch I've seen.
Flags: needinfo?(jib)
Attachment #8849349 - Flags: approval-mozilla-esr52?
Attachment #8849349 - Flags: approval-mozilla-aurora?
Correction, I see ESR45 also had this bug, so this uplift would not prevent a regression, though it would fix it.
I am sorry for not noticing this hadn't landed for almost two weeks.

Note to testers: on inbound mozRtt has been renamed to roundTripTime in bug 1344970.
(In reply to Jan-Ivar Bruaroey [:jib] from comment #15)
> [Approval Request Comment]
> If this is not a sec:{high,crit} bug, please state case for ESR
> consideration:

Without this stat, it's impossible to provide users with an indication of their connection quality, since rtt is the most relevant stat for real-time data transfer.  If it's not in ESR52 at some point, I'm going to have to live with this bug until Q1/Q2 of 2018, when ESR59.1 lands.

We currently strongly discourage our users from using FF because of this bug.  There's no way to give users a clear indication their connection sucks.

So I'd argue it's A) incredibly minor and B) actually an extremely important feature for real-time communication.
Comment on attachment 8849349 [details]
Bug 1241066 - fix mozRtt always 0 or 1;

A minor fix. Aurora54+.
Attachment #8849349 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
ESR 45.9 shipping this week is the last planned release off that branch, so marking esr45 as wontfix. Assuming that the esr52 request gets approved, it will be in the 52.2 release in June (52.1 ships this week).
Flags: needinfo?(mreavy)
Comment on attachment 8849349 [details]
Bug 1241066 - fix mozRtt always 0 or 1;

This seems like a very simple fix, ESR52.2+
Attachment #8849349 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52+
You need to log in before you can comment on or make changes to this bug.