Clear network Quality pref if the observed quality matches the expected value |
||||||
Issue descriptionCurrently, if the observed network quality matches the expected value for the current connection type, then the network quality value is not persisted to the disk. This was an optimization to reduce the size of the prefs. However, it is possible that the current network has a persisted ECT which is different from the expected value. In that case, when the prefs are read back at the next startup, the prefs manager will read the old ECT value because of this optimization. To avoid this, we should clear the network quality pref for the current network if the observed quality matches the expected value.
,
Jan 3 2018
,
Jan 8 2018
Requesting merge for CL in #1. It's a pretty safe CL, and well covered by tests. Thanks.
,
Jan 8 2018
This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jan 8 2018
Thanks tbansal@ for the fix. Can you please confirm why this is urgent for M64 vs waiting until M65?
,
Jan 8 2018
This bug causes network quality estimator to compute the network quality incorrectly at the time of Chrome startup. This leads to incorrect results in NetInfo.Connection.EffectiveType and NetInfo.Connection.RTT JavaScript APIs which is in use by developers.
,
Jan 9 2018
Can you please confirm if the fix has been manually verified in canary/dev?
,
Jan 9 2018
Yes, I have verified that the fix has been working for Canary.
,
Jan 9 2018
Approving merge. Branch:3282
,
Jan 10 2018
I decided not to merge this back since there are few merge conflicts. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bugdroid1@chromium.org
, Jan 3 2018