Open C Platform versión 32.0a1 Build ID: 20140603121811 Git commit: 26d8fcab Pre-requisited: 1. Wifi usage not 0 2. "Reset report": "Weekly" and "Starting on": (same day of the test) in my case Tuesday. (Day of test: Tuesday 4 June 2014) 3. Postpaid sim card STR: Tap cost control application. Actual result: Graphic shows Wi-Fi usage (Green colour) between Jun 4 and Jun 9 Expected result: Graphic shows Wi-Fi usage (Green colour) *only* Jun 4

Also, it isn't working in Flame Platform versión:32.0a1 Build id: 20140603121811 Git commit: 26d8fcab

Is this happening on 1.4?

(In reply to Jason Smith [:jsmith] from comment #2) > Is this happening on 1.4? Yes, it is reproducible in 1.4

(In reply to Loli from comment #3) > (In reply to Jason Smith [:jsmith] from comment #2) > > Is this happening on 1.4? > > Yes, it is reproducible in 1.4 Ok - leaving qawanted to also check if this happens on 1.3.

(In reply to Jason Smith [:jsmith] from comment #4) > (In reply to Loli from comment #3) > > (In reply to Jason Smith [:jsmith] from comment #2) > > > Is this happening on 1.4? > > > > Yes, it is reproducible in 1.4 > > Ok - leaving qawanted to also check if this happens on 1.3. Not reproducible 1.3

This looks like wrong behavior & a regression. We're reporting usage stats for time in the future, which is incorrect. Note - this is a SIM independent bug, so a window should be possible to do here.

This 'bug' actually looks like expected behavior to me. First of all, they're setting the report to 'Weekly' and not Daily (though there's no Daily available to select). The report shows an accumulative graph which makes sense, because if I was tracking my Data usage, I'd want accumulative numbers, and not daily numbers and I'll have to add daily numbers together myself to know how much Data I've been using. Please clarify on the expected behavior here. Also on 1.3, the graph does not show the horizontal green/violet bars, I'll have to wait a day to know if they're accumulative. Attaching a screenshot on 1.3 Flame.

I don't think so. The graph being shown here is reporting information in the future. Additionally, reset weekly just means that the graph only tracks data within the past 7 days.

(In reply to Jason Smith [:jsmith] from comment #9) > I don't think so. The graph being shown here is reporting information in the > future. Additionally, reset weekly just means that the graph only tracks > data within the past 7 days. The graph shows an accumulative usage starting from the day you selected and ends 7 days later including the starting day. My testing on 1.3 proves my theory. In 1.3 it does the same thing, it just doesn't draw the bar all the way but functionality-wise it does the same thing - it shows accumulative usage. It is suboptimal that the Usage app does not show Daily results, but the current behavior is not wrong either. I could still find the window where it starts drawing the graph with green/violet bars all the way to the right.

(In reply to Pi Wei Cheng from comment #10) > Created attachment 8439342 [details] > 1.3 Flame usage app from yesterday to today > > (In reply to Jason Smith [:jsmith] from comment #9) > > I don't think so. The graph being shown here is reporting information in the > > future. Additionally, reset weekly just means that the graph only tracks > > data within the past 7 days. > > The graph shows an accumulative usage starting from the day you selected and > ends 7 days later including the starting day. > > My testing on 1.3 proves my theory. In 1.3 it does the same thing, it just > doesn't draw the bar all the way but functionality-wise it does the same > thing - it shows accumulative usage. > > It is suboptimal that the Usage app does not show Daily results, but the > current behavior is not wrong either. > > I could still find the window where it starts drawing the graph with > green/violet bars all the way to the right. I disagree. The graph is intending to show data on a daily basis for a weekly timeframe for today & time in the past. The data shown in the graph is indicating data in the future, which is wrong behavior.

b2g-inbound Window: Last Working Environmental Variables: Device: Buri BuildID: 20140505071336 Gaia: 89f76e6668746db9619df132f471b7e5b4908426 Gecko: 0a2b76387829 Version: 32.0a1 Firmware Version: v1.2device.cfg First Broken Environmental Variables: Device: Buri Build ID: 20140505072736 Gaia: 89f76e6668746db9619df132f471b7e5b4908426 Gecko: d33eb4264e5b Version: 32.0a1 Firmware Version: v1.2device.cfg Gaia is the same on both builds, therefore it was affected by Gecko. Gecko Pushlog: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=0a2b76387829&tochange=d33eb4264e5b

Hi Marina, Do you want to take a look at this?

Hi, the graphic always shows the accumulative traffic for this reason, the information showed is correct, because the hight of the Y axis is the same in the future days (same height = no data consumed). The way of draw the graphic change when we start to use the networkStats API, because the costcontrol app draws all the records returned by the database. And the behavior of the database changed. The older database did not return records of dates later than the current date, and the new return a record for each day of the queried period. But, I want to remark that the data showed are fine. Jason, I understand that you prefer the older method when the graphic only draw to the current day. ;) Sorry for my delay in answering

(In reply to marina rodríguez [:mai] from comment #14) > Hi, > the graphic always shows the accumulative traffic for this reason, the > information showed is correct, because the hight of the Y axis is the same > in the future days (same height = no data consumed). I think sounds incorrect to me. You haven't consumed data in the future yet, so there shouldn't be anything showing on Y-axis in the future. Showing a flat line sends a user perception that something did happen on that day, when in reality, it didn't. > > The way of draw the graphic change when we start to use the networkStats > API, because the costcontrol app draws all the records returned by the > database. And the behavior of the database changed. The older database did > not return records of dates later than the current date, and the new return > a record for each day of the queried period. I think that sounds incorrect. Showing time in the future that hasn't occurred yet creates a point of confusion for a user, as he/she knows that day hasn't occurred yet, when in reality, the graph is showing that something has happened. > > But, I want to remark that the data showed are fine. From a stats perspective, I think this does not make sense. We're showing data that's irrelevant since the date hasn't occurred yet. Root cause is a gecko issue, I'm bouncing this over to DOM & asking John to weigh in.

I'm asking for a retest on 1.4 since the window seems to indicate that this does not reproduce on 1.4.

This behaviour is incorrect. As Jason says, we should not show "future" usage. It should not be too hard to solve, just stop drawing when reaching today taking into account time-travelling issues. Let's take a look.

Hi Salva, would you mind reviewing the patch? Regards

API is supposed to return { rxBytes: undefined, tx: undefined, date: new Date(aDate) } if aDate is a future date (i.e., no data consumption). So I think the problem can be solved in gaia.

Comment on attachment 8441290 [details] patch v1.0 Address the problem on GitHub and ask for my review again.

On 1.4 the graph does not show green/violet bars all the way to future dates. See attached screenshot. Device: Flame Build ID: 20140617000202 Gaia: 4b3428e85b428e577a0f96cba6121c4ca1c91f8a Gecko: ba55b5a7b20d Version: 30.0 Firmware Version: v121-2

Bumping to 2.0+ since we can't reproduce on 1.4.

Resolved by Bug 1017581

Tested(In reply to marina rodríguez [:mai] from comment #23) > Resolved by Bug 1017581 Tested today with Flame 2.0 Platform versión: 32.0a2 Build ID:20140620111452 Git commit: a6988c15 and NOT working

(In reply to Loli from comment #24) > Tested(In reply to marina rodríguez [:mai] from comment #23) > > Resolved by Bug 1017581 > > Tested today with > Flame > 2.0 > Platform versión: 32.0a2 > Build ID:20140620111452 > Git commit: a6988c15 > > and NOT working The patch has not been uplifted to 2.0 so that's the reason of the fail in 2.0