34.31 KB, image/png
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
75.54 KB, image/png
28.96 KB, image/png
42.63 KB, image/png
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
UX polish, not blocking.
blocking-b2g: leo? → -
Can QA check if this is still reproducing?
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
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
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.
Ayman, attending to , could you review this patch? Just tell us if the behaviour seems resonable and if we are moving in the right direction, please.  https://bugzilla.mozilla.org/show_bug.cgi?id=838556#c9
this is cost control so passing to rafa
Flags: needinfo?(aymanmaat) → needinfo?(hello)
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.
(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?
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-
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)
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.
Totally accurate. We are moving on solving this in the back-end. Thank you all.
As bug 838556 is solved, we need QA input here.
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
QA Contact: astole → croesch
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
status-b2g-v2.0M: affected → ---
QA Contact: croesch
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.