[COST CONTROL] After flashing, a change of date to a previous date inside the current billing period causes the dots in the data usage graph to disappear

RESOLVED WONTFIX

Status

Firefox OS
Gaia::Cost Control
P1
normal
RESOLVED WONTFIX
5 years ago
2 months ago

People

(Reporter: carlosmartinez, Unassigned)

Tracking

unspecified
1.1 QE5
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:-, b2g18?, b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

Details

Attachments

(5 attachments)

Created attachment 766628 [details]
Data usage graph without a dot indicating the current date

Tested in unagi device with:

Gecko-d7330ac
Gaia-11b472e

from v1-train, and AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.131

STR:
1-Open cost control
2-Configure the billing cycle to be weekly
3-Surf the web using 3G or wifi
4-Go to settings
5-Change the date to a previous date inside the current weekly billing cycle
6-Open cost control
7-Go to data usage graph screen

Expected result --> Date change is handled somehow and data usage graph screen continue working, although data shown should be incorrect

Actual result --> The dot indicating current date disappears once date is changed
After checking the STR, it is true the dots don't appear but it is not accurate to way the usage graph stops working as it still count. The only effect is the dot is not being displayed. Rewording to avoid panic.

Furthermore, this is a very marginal case as it only happens when there is no data in the historical so, with the current implementation, this can only happen if the user changes the date to some date before the starting date using the device (note with the current implementation even Reset does not empty the historical data).

My recommendation is not to block on this bug as it is a UX polish matter.

The bug is related with bug 838556 in such a way we don't have the implementation of what to do when the user changes the system clock yet but we have it defined on new specifications.
Summary: [COST CONTROL] A change of date to a previous date inside the current billing period, causes the data usage graph to stop working → [COST CONTROL] After flashing, a change of date to a previous date inside the current billing period causes the dots in the data usage graph to disappear

Comment 2

5 years ago
UX polish, not blocking.
blocking-b2g: leo? → -

Updated

5 years ago
Priority: -- → P1
Target Milestone: --- → 1.1 QE4 (15jul)
tracking-b2g18: --- → ?

Updated

5 years ago
Target Milestone: 1.1 QE4 (15jul) → 1.1 QE5
Can QA check if this is still reproducing?
Keywords: qawanted

Updated

4 years ago
QA Contact: astole
This issue reproduces on the most recent Buri 1.3 build.

Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20140122004001
Gaia: 744fb691c2b2a25a07c5d19fabf5748ae9aba4d9
Gecko: 71a8786c3815
Version: 28.0a2
Firmware Version: v1.2-device.cfg
Keywords: qawanted
Assignee: nobody → mri
Created attachment 8384496 [details] [review]
patch v1.0

Hi,
in this patch I change the start date when ask for data usage info, if the start date is higher than today.
Salva, could you review the patch?
Regards
Attachment #8384496 - Flags: review?(salva)
Comment on attachment 8384496 [details] [review]
patch v1.0

I'm not sure this is the best option. I'm removing the mark for review and asking for UX input here.
Attachment #8384496 - Flags: review?(salva)
Ayman, attending to [1], could you review this patch? Just tell us if the behaviour seems resonable and if we are moving in the right direction, please. 

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=838556#c9
Flags: needinfo?(aymanmaat)

Comment 8

4 years ago
this is cost control so passing to rafa
Flags: needinfo?(aymanmaat) → needinfo?(hello)

Comment 9

4 years ago
Created attachment 8394049 [details]
2014-03-20-11-56-57.png

I am having difficulty testing this because the date picker in my settings on my test device keeps on coming up devoid of values (see attached) so i cannot switch the date.

...will look further into this

switching ni? from rafa to me as i am looking at this now.
Flags: needinfo?(hello) → needinfo?(aymanmaat)
Created attachment 8394099 [details]
Sample behaviour with the patch

Ayman, I've attached a picture to show the behavior of the patch.
Flags: needinfo?(aymanmaat)

Comment 11

4 years ago
(In reply to marina rodríguez [:mai] from comment #10)
> Created attachment 8394099 [details]
> Sample behaviour with the patch
> 
> Ayman, I've attached a picture to show the behavior of the patch.

thanks very much maria. your attachment demonstrates that this bug is fixed so you can mark it as such.

As a footnote I am surprised to read in comment 1 that the behaviour of the graph when the user sets the phone to a previous date is considered 'UX polish'. For sure from a UX PoV the behaviour/presentation of the graph could be pushed much much further in the event that the user alters the date backwards in order to make it more understandable and usable because the current presentation is not particularly understandable or therefore indeed useful in this event. However this is beyond the scope of this bug.
Comment on attachment 8384496 [details] [review]
patch v1.0

Salva, could you review this patch?
Attachment #8384496 - Flags: review?(salva)
Comment on attachment 8384496 [details] [review]
patch v1.0

Please, this is not as easy and, more important, this patch is not solving the STR described in comment #0

1) The STR says what happens if the user change the date INSIDE the current billing period. I mean, we are showing from Monday to Monday but we are in Satuday, what happen if the user now says we are in Thursday? Are the dots still disappearing? If not, we should close this bug as WORKSFORME. If so, we should look for the proper solution.

2) This patch is solving the problem of what happen if the user say we are before the beginning of the period. In that case the dot is not being shown because "today" is not inside the current period. Back to the example, imagina we are showing from Monday 7 to Monday 14. What happen if the user say we are in Sunday 6? As the Cost Control application can only track the current period, it makes some sense to not display the dot because the dot means today aand your today is before the present period.

What do you think?
Attachment #8384496 - Flags: review?(salva) → review-
Flags: needinfo?(aymanmaat)

Comment 14

4 years ago
Hi salva, you have put an ni? flag for me could you please clarify what information you would like me to provide please?
Flags: needinfo?(aymanmaat) → needinfo?(salva)
Hello Ayman, in comment #11, you said:

> thanks very much maria. your attachment demonstrates that this bug is fixed
> so you can mark it as such.

But as I say in comment #13, point 2, we are solving another problem than that described in comment #0.

> 
> As a footnote I am surprised to read in comment 1 that the behaviour of the
> graph when the user sets the phone to a previous date is considered 'UX
> polish'.

This is not accurate. I'm not saying the scenario in which the user changes the date to a time before / after is a matter of UX polish. Indeed the comment #1 ends saying there is an entire bug to address that issue (bug 838556). I'm saying this specific bug was, at the moment to be opened, a matter of polish. I mean, we made a mistake in the code that shows a side effect preventing the dot to be displayed when meeting the conditions in the description.

> For sure from a UX PoV the behaviour/presentation of the graph
> could be pushed much much further in the event that the user alters the date
> backwards in order to make it more understandable and usable because the
> current presentation is not particularly understandable or therefore indeed
> useful in this event. However this is beyond the scope of this bug.

Indeed, this is in the scope of bug 838556.

Returning to the original matter. I asked for your ni because you said the problem was solved and I wanted to take into account your opinion after explaining why not is solved.

Hope you agree.
Feedback welcome!
Flags: needinfo?(salva) → needinfo?(aymanmaat)

Comment 16

4 years ago
Just a note on this bug. After discussion with Salva yesterday it would seem that the implementation of 838556 specifically in line with comment 9 of 838556 will make this this bug void as the behaviour in comment 0 will not be reproducible. The reason for this is that the implementation of 838556 will make the ‘today’ dot always the last entry on the graph. 

So for example: 

The user turns data usage alert on on, say, March 20 and lets it run for four days and the following values are registered on the graph:

march 20 - 1mb
march 21 - 2mb	
march 22 - 3mb
march 23 - 4mb
march 24 - 5mb <dot here>

today is march 24 with the reading at 5mb. the user then (for whatever crazy reason) decides to change ‘today’ to be march 22 using the system date time settings. The graph therefore relabel its x axis to present as follows:

march 18 - 1mb
march 19 - 2mb	
march 20 - 3mb
march 21 - 4mb
march 22 - 5mb <dot here>

If the user then moves the date system date forwards say 4 days from march 22 to march 26 the graph will relabel its x axis to present as follows:

march 22 - 1mb
march 23 - 2mb	
march 24 - 3mb
march 25 - 4mb
march 26 - 5mb <dot here>

so therefore it is the x axis of the graph that will alter in response to date change, not the content of the graph itself. Therefore this bug should be not be reproducible.

I will leave this open until 838556 is implemented, then it can be tested and closed.
Flags: needinfo?(aymanmaat)
Totally accurate. We are moving on solving this in the back-end. Thank you all.
Assignee: mri → nobody
As bug 838556 is solved, we need QA input here.
Keywords: qawanted
So I did a check on the Flame device and found that the dots go missing if a date is set 2 or more days behind the current date. The dots get replaced with shaded blocks as seen in my screenshot attached. I've attached my results for branch checks for the flame. I'm hoping this provides some useful information for you.

Now I don't know if they've changed to this by design but based on comment 16 saying that dots should be seen, I'm providing current behavior on current devices.

Tested with Shallow Flash on 319mb using Engineering builds

This bug repro's on Flame KK builds: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK, Flame 2.0 Base

Actual Results: Dots for the graph are missing in the usage app when dates are set to a few days prior. 

Repro Rate: 5/5

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141111042605
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: c60fc2c11c0e
Version: 36.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141111072405
Gaia: 4c159e75a1568afbbf0c83c1235ec56facfbe87d
Gecko: d1930a36f9c3
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141110175151
Gaia: dfdd6268b9784eafdd509f0ddf71407698ed5080
Gecko: fcc5d31f84d7
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 Base
BuildID: 20141021162107
Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.0M: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: astole → croesch
Created attachment 8520783 [details]
Flame behavior

Flame Behavior
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
status-b2g-v2.0M: affected → ---
Flags: needinfo?(jmitchell)
QA Contact: croesch
Duplicate of this bug: 1126194

Comment 22

2 months ago
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.