988264 - [Cost Control] When date usage gets reset you can see a wrong screen

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Description

[Loli (:lolimartinezcr)]

Attachment: 2014-04-27-00-02-43.png

1.4
Platform version: 30.0a2
Build ID: 20140325101236
Git commit: b09bf796
Reproducible: 100%

STR)
1) Tap in usage aplication.
2) Tap in settings.
3) Tap in "reset report" fiel and select "weekly" and in "Starting on" future day to the date set. (in my case day seted: 03/28/2014 12:03 AM and day selected: 03/29/2014)
4) Change the date in device to reset (in my case: 03/28/2014 11:59 PM)
5) Wait for time pass.

Actual result:
You see wrong screen (See attached image)

Expected result:
Data usage is reseted and user doesn't see this screen

Comment 1

[Noemí Freire (:noemi)]

Hi,

Just adding that same behavior is seen in today's (3/27) master build:
Device:hamachi
BuildId: 20140326065930
Gecko: 618b2c2
Gaia: 0c9701c
Platform version: 31.0a1


On the other hand, the behavior seen on today's (3/26) v1.3 build is a bit different:
Device:hamachi
BuildId: 20140326055947
Gecko: 6a9a53d
Gaia: 812838a
Platform version: 28.0

1) Tap in Data Usage app
2) Tap in Settings
3) Tap in "reset report" field and select "weekly" and in "Starting on" a future day to the current date set. (in my case current day: 03/26/2014 and day selected: Thursday (03/27/2014)
4) Change the date going through Settings-> Date & Time to 03/26/2014 11:59 PM
5) Wait for 03/27/2014

Actual result:
After the date change the graphic shown is "2014-03-27-00-01-55.png" which is wrong since the data is not reset. After closing and opening again data usage app "2014-04-27-00-02-43.png" message (the one reported in the description) is shown.

Comment 2

[Noemí Freire (:noemi)]

Attachment: 2014-03-27-00-01-55.png

Comment 3

[Marina Rodríguez [:mai]]

Attachment: patch v1.0

Hi Salva,
could you review the patch?

The problem is related with the load of NetworkInterfaces. On this patch, I check if the networkInterfaces are loaded before the resetAll method is launched.

Regards.

Comment 4

[Marina Rodríguez [:mai]]

This bug is regression that was introduced by the use of the new API networkStats.

Comment 5

[Salvador de la Puente González [:salva]]

Comment on attachment 8397077 [details] [review]
patch v1.0

Working fine. Thank you Mai.

Comment 6

[Marina Rodríguez [:mai]]

Master: 48548fbd7a472b1bb3dfa22ac46876c53e850a15

Comment 7

[Marina Rodríguez [:mai]]

Comment on attachment 8397077 [details] [review]
patch v1.0

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 937240
[User impact] if declined: the posibility of a silent error when the automaticaly process of reset network data is launched.
[Testing completed]:yes
[Risk to taking this patch] (and alternatives if risky): no risks
[String changes made]:no

Comment 8

[Lawrence Mandel [:lmandel] (use needinfo)]

Hi Marina. Can you please expand upon your answers so that release management is properly informed for our review?

(In reply to marina rodríguez [:mai] from comment #7)
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #): bug 937240
> [User impact] if declined: the posibility of a silent error when the
> automaticaly process of reset network data is launched.
What is the chance of occurrence of a silent error? What are the ramifications of a silent error?
> [Testing completed]:yes
Can you please elaborate on the testing that you have completed. I see no unit tests in your patch. Is there a reason that unit tests can't be written for this change?
> [Risk to taking this patch] (and alternatives if risky): no risks
Is there any other code that relies upon these values and that may be impacted by resetting them at this point?
> [String changes made]:no

Comment 9

[Marina Rodríguez [:mai]]

Hi, 
I'm going to try to explain better this. This only affects to the automatic resetting alarms because it's the only alarm which needs the network interface info. And the probablility is very low.

The silent error is produced when an alarm is fired, and the app is launched on standalone mode, and the network interfaces at this point are not loaded, then the network data is not reset. I said the error was silent because does not emit a message. The following time the user launchs the usage app the data reset is done.

The testting was made on the devices: 
If probe the patch on the following scenarios (with the app launched and when the app is not launched) with the following scenarios:

1. Open CC application
2. tap in settings.
3. Tap in "reset report" field and select "monthly" and in "Starting on" the following day to the actual system day.
4. (Then close de app or not in function the scenario)
5. Go to system, change the system hour to 11:59 PM
6. Wait to change the date

Testing on the logcat if there are any error log, and check on the CC app if the device reset the data correctly.

Regards.

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

Marina - Thank you for the details. One question remains from my comment 8:

I see no unit tests in your patch. Is there a reason that unit tests can't be written for this change?

Comment 11

[Marina Rodríguez [:mai]]

Hi Lawrence,
Sorry, I was not aware that i did not answer this question. It's too complicated reproducing the bug with unit test.
The appropriate tests for replicating this situation are marionette test. Unfortunately, I did not manage to implement this kind of test yet because of the architecture of the app. (Need a simcard to works, the mozmobileconections and networkStats APIs are not available on b2g-desktop still, ...)

Currently, we're working to refactor the app and increasing the coverage test. I hope in a short time we could implement the marionette test on this app.
Regards.

Comment 12

[Noemí Freire (:noemi)]

Hi Ryan,

The patch has just obtained the approval for v1.4. Could you please help us with the uplift to that branch?. Thanks!

Comment 13

[Ryan VanderMeulen [:RyanVM]]

FWIW, I go through the uplift queries on the B2G Landing page daily, so you don't need to needinfo? me on every uplift.
https://wiki.mozilla.org/Release_Management/B2G_Landing#Automatic_Branch_Uplifts

Comment 14

[Noemí Freire (:noemi)]

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #13)
> FWIW, I go through the uplift queries on the B2G Landing page daily, so you
> don't need to needinfo? me on every uplift.
> https://wiki.mozilla.org/Release_Management/
> B2G_Landing#Automatic_Branch_Uplifts

ok, sorry for the inconvenience.

Comment 15

[Ryan VanderMeulen [:RyanVM]]

v1.4: https://github.com/mozilla-b2g/gaia/commit/b3fdccd048b67f07f7102efebbc87bfc4921c2a6

Comment 16

[Loli (:lolimartinezcr)]

Tested and working
Hamachi 
1.4
Gecko 3e007e6
Gaia b4f3b84
Platform version: 30.0a2
Build ID: 20140404101450
Git commit: b4f3b84e

Tested and NOT WORKING, i can see "Usage crashed"
Hamachi 
1.5
Gecko 7649261
Gaia 86ff94b
Platform version: 31.0a1
Build ID: 20140404070420
Git commit: 86ff94b3

Comment 17

[Loli (:lolimartinezcr)]

tested and working
1.5 
Gecko fa7c5ad
Gaia 7c73c66

1.4
Gecko a15cb07
Gaia 441c4bc

Comment 18

[Mike Livingston]

Data does not get reset in 1.3, 1.4 and 2.0. Unable to repro screenshot "2014-04-27-00-02-43.png".

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140525024003
Gaia: 0ce948e378cab7ed3db20231281dd7ca2eb99779
Gecko: 94e367cf6c94
Version: 28.0
Firmware Version: v1.2-device.cfg

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140527000202
Gaia: 0542778892a294d224e75af4a76be5d42938bc90
Gecko: d583ae109f54
Version: 30.0
Firmware Version: v1.2-device.cfg

2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140527040202
Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c
Gecko: cbe4f69c2e9c
Version: 32.0a1
Firmware Version: V10G-2

Comment 19

[Shally Li（leave from Mozilla）]

Hi William,

    I also can repro this bug on latest Flame v2.0,and can't repro on Woodduck v2.0 and Flame v2.1&2.2. Could you help with the bug?
    See attachments: verify_v2.0.mp4 and new_logcat_0000.txt.
    Reproduce rate: 5/5

Repro STR:
1. Open Usage app.
2. Tap on "Settings".
3. Set as "Weekly" in "Reset report" and "Tuesday" in "Starting on".(Today is "Monday,01/26/2015")
4. Go to Settings->Date & Time and change time to "11:59 PM".
5. Wait for "01/27/2015 12:00AM".

Woodduck v2.0 build:
Gaia-Rev        8561b6203888dcf10a0d4a75e81b0d0dd3618875
Gecko-Rev       8596d18e9b5f8ea4fadd952694e2739124a636f9
Build-ID        20150126050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2
FW-Incremental  1422219945
FW-Date         Mon Jan 26 05:06:10 CST 2015

Flame v2.0 build:
Gaia-Rev        2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/ffb9925dd084
Build-ID        20150125000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150125.033105
FW-Date         Sun Jan 25 03:31:16 EST 2015
Bootloader      L1TC000118D0

Flame v2.1 build:
Gaia-Rev        54d92cc0755e5102223276ab23063b5eee74b514
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/522d6c980917
Build-ID        20150125001312
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150125.035903
FW-Date         Sun Jan 25 03:59:13 EST 2015
Bootloader      L1TC000118D0

Flame v2.2 build:
Gaia-Rev        0518f4581a0925c0b703d730ef289ab15cbd1216
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/c6aa604a7967
Build-ID        20150125002503
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150125.035924
FW-Date         Sun Jan 25 03:59:36 EST 2015
Bootloader      L1TC000118D0

Comment 20

[Shally Li（leave from Mozilla）]

Update the "Reproduce rate: 5/5" to "Reproduce rate: 5/10".

Comment 21

[Shally Li（leave from Mozilla）]

Attachment: new_logcat_0000.txt

Comment 22

[Shally Li（leave from Mozilla）]

Attachment: verify_v2.0.mp4

Comment 23

[Marina Rodríguez [:mai]]

Hi Shally,
On the video, the weekly period ends on 3 February, the graph of datausage shows the period defined, on this case the graph ends on 2 february, this day is when the reset  is going to be fired.

Regards

Comment 24

[Shally Li（leave from Mozilla）]

(In reply to Marina Rodríguez [:mai] from comment #23)
> Hi Shally,
> On the video, the weekly period ends on 3 February, the graph of datausage
> shows the period defined, on this case the graph ends on 2 february, this
> day is when the reset  is going to be fired.
> 
> Regards

Hi Marina,
  
    Yes,some problems have happened about the reset of the day. Maybe I can submit a new bug. Thanks.
    And this bug has been successfully verified on Flame v2.0 (Date usage gets reset successfully).
    See attachment: verified_v2.0.mp4.
    Reproduce rate: 0/5 

Flame 2.0 build:
Gaia-Rev        2989f2b2bd12fcc0e9c017d2db766e76a55873b8
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/b4c61fd1dcfc
Build-ID        20150126000204
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150126.033406
FW-Date         Mon Jan 26 03:34:17 EST 2015
Bootloader      L1TC000118D0

Comment 25

[Shally Li（leave from Mozilla）]

Attachment: verified_v2.0.MP4

Comment 26

[Shally Li（leave from Mozilla）]

I sumbit a new bug 1126194 about this problem as mentioned in Comment 23.