New issue
Advanced search Search tips

Issue 808201 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Nov 28
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression

Blocked on:
issue 836029



Sign in to add a comment

Inconsistent data used/data saved info in the Data Saver screen in settings

Project Member Reported by mar...@mwiacek.com, Feb 1 2018

Issue description

Device name: s7

From "Settings > About Chrome"
Application version: canary 66.0.3336.0, stable, ...
Operating system: 7

Steps to reproduce:
(1) clean app history
(2) go into any site with enabled data saver
(3) go into data saver screen

Expected result:

data saved on top = sum of data saved in the table on bottom

data used on top = sum of data used in the table on bottom

Actual result:

data user differs a lot, rounding error observed for data saved (for this we just should sum things in table and display THIS in top)

 
Screenshot_20180201-221021.png
112 KB View Download
Screenshot_20180201-221146.png
126 KB View Download
Labels: Needs-triage-Mobile
Cc: pnangunoori@chromium.org
Components: Internals>Network>DataUse
Labels: FoundIn-66 Target-66 M-66 Triaged-Mobile FoundIn-64 FoundIn-65
Status: Untriaged (was: Unconfirmed)
Tested the issue in Android and able to reproduce the issue. Similar behavior is observed since Chrome M-61.

Steps Followed:
1. Launched the Chrome Browser.
2. Reset History and Data Saver - RESET STATISTICS 
3. Browse couple of sites.
4. Navigate to Data Saver page from Chrome settings.
5. In the Data Saver page observe that there is rounding off difference between Data Saved, Data Used and sum of Data Usage breakdown. 

Chrome versions tested:
61.0.3142.0, 64.0.3282.137(Stable), 66.0.3336.4(Canary)

(In the M-60 and earlier builds, data break down is not displayed and couldn't verify sum on those builds)

OS:
Android 7.0.0

Android Devices:
SM-J701F, Build/NRD90M

This seems to be a Non-Regression issue as same behavior is seen since M61. Hence removing the ‘Needs-Bisect’ label. Untriaged for further input's on this issue.

Please navigate to below link for log's and video--
go/chrome-androidlogs/808201

Thanks!
Cc: bengr@chromium.org
Labels: android-fe-triaged
Owner: megjab...@chromium.org
Status: Assigned (was: Untriaged)
Cc: -bengr@chromium.org
Owner: bengr@chromium.org
Basic complaint here is that breakdown counts do not sum to same value as displayed total. Looks like more than just rounding issue - are we not sampling counts consistently for total and breakdown?

Comment 6 by bengr@chromium.org, Mar 26 2018

Components: Internals>Network>DataProxy
Owner: dougarnett@chromium.org
IIRC, the total is stored in a pref while the breakdown comes from a DB, the former for performance. They are written at the same time and *should* agree. I can think of a few ways to fix this:

1) compute the total from the breakdown, but that means more (maybe too much) processing on the main settings page. 
2) move the total to the DB, so that writes happen to the same place.
3) make one the authoritative source, and adjust the "other" bucket to agree.  

I prefer them in that order.
Repro-ed this for inconsistency with Data Used - beyond rounding error. 
Interestingly, Data Saved may be just rounding issue. So perhaps we need to first focus on where breakdown is not getting updated when total is.

Summarizing data from screenshot: 
  - Total Data Used 4.35MB != 2.21MB + 1.21MB + 311KB + 57.41KB
  - Total Data Saved 744KB ~= 684KB + 51.61KB + 7.16KB + 319B
saveddatabreakdown.png
150 KB View Download
Cc: rajendrant@chromium.org
CC-ing Raj in case he might have insight as to where Used count is counted without breakdown counted.
DataReductionProxyNetworkDelegate::CalculateAndRecordDataUsage() only record total and it does have the URL so that looks like a big hole that should be straightforward to fix.
Blockedon: 836029
Refreshed during triage.
Refreshed during triage.
Refreshed during triage
Cc: -rajendrant@chromium.org dougarnett@chromium.org
Owner: rajendrant@chromium.org
Raj, with your data use ascription refactoring landed, do you expect this issue is now resolved? 
Refreshed during triage
Status: Fixed (was: Assigned)
This is fixed when network-service is enabled.

Sign in to add a comment