Closed Bug 942060 Opened 6 years ago Closed 6 years ago

[Cost Control] There is no usage data and graph in usage app

Categories

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

All
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3+)

VERIFIED FIXED
1.3 Sprint 6 - 12/6
blocking-b2g 1.3+

People

(Reporter: askeing, Assigned: mai)

References

Details

(Keywords: regression, Whiteboard: [xfail])

Attachments

(3 files)

Attached file NoUsageData.log
### ENV:
Base Img: V1.2_US_20131115.cfg
Gaia:     71063dd91bc8cbb15ba335236ed67a1c5058bd58
Gecko:    http://hg.mozilla.org/mozilla-central/rev/cf378dddfac8
BuildID   20131121040202
Version   28.0a1

### STR
0. flash gaia and gecko
1. go through the FTU
2. connect to Wifi
3. launch Cost Control app, go through the Cost Control FTU
4. enable Wifi usage
5. switch to Cost Control app

### Excepted
1. there are wifi usage data and graph in Cost Control app

### Actual
2. there is no usage data and graph
Attached video No Usage Data Video
It might be the root cause of test_cost_control_reset_wifi.py failed.
Need more investigation.
The log doesn't really specify anything interesting.

A regression range will help figure out what caused this.
blocking-b2g: --- → 1.3?
On today's nightly all automation has passed. A manual check seems to give it a clean bill of health too.

Gaia:     13687c598c3b5ef4cff9eef8d0ed3bb57c5f9d65
Gecko:    http://hg.mozilla.org/mozilla-central/rev/dbf94e314cde
BuildID   20131122040202
Version   28.0a1
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 6 years ago
Resolution: --- → WORKSFORME
Failed again on TWCI and MV Jenkins.

ex: http://qa-selenium.mv.mozilla.com:8080/job/b2g.hamachi.mozilla-central.ui/316/

TEST-START test_cost_control_reset_wifi.py
test_cost_control_reset_wifi (test_cost_control_reset_wifi.TestCostControlReset) ... ERROR

======================================================================
ERROR: None
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/.env/local/lib/python2.7/site-packages/marionette_client-0.6.2-py2.7.egg/marionette/marionette_test.py", line 143, in run
    testMethod()
  File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/tests/functional/cost_control/test_cost_control_reset_wifi.py", line 40, in test_cost_control_reset_wifi
    self.assertNotEqual(cost_control.wifi_data_usage_figure, u'0.00 B', 'No data usage shown after browsing.')
  File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/cost_control/app.py", line 54, in wifi_data_usage_figure
    self.wait_for_element_displayed(*self._wifi_data_usage_figure_locator)
  File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 70, in wait_for_element_displayed
    raise TimeoutException('Element %s present but not displayed before timeout' % locator)
TEST-UNEXPECTED-FAIL | test_cost_control_reset_wifi.py test_cost_control_reset_wifi.TestCostControlReset.test_cost_control_reset_wifi | TimeoutException: Element wifiOverview present but not displayed before timeout
----------------------------------------------------------------------
Ran 1 test in 127.734s
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Blocks: 942733
blocking-b2g: --- → 1.3?
Whiteboard: [xfail]
QA Contact: gbennett
.:Last Working Build:.
Environmental Variables:
Device: Buri 1.3 mozRIL
BuildID: 20131120040202
Gaia: c26480b22ce28c812c347290dd4bad090d83db6f
Gecko: 4f993fa378eb
Version: 28.0a1
Firmware Version: 20131115

.:First Broken Build:.
Environmental Variables:
Device: Buri 1.3 mozRIL
BuildID: 20131121040202
Gaia: 71063dd91bc8cbb15ba335236ed67a1c5058bd58
Gecko: cf378dddfac8
Version: 28.0a1
Firmware Version: 20131115
On the Gaia side, the only relevant patch here is bug 937240.
On the gecko side, it could be bug 937041. Don't know if bug 814637 could play a factor here as well.

Salva - Can you weight in which bug might have caused this regression?
Flags: needinfo?(salva)
Hello Jason. The problem here is related with bug 814637, bug 937041 and bug 937240 in a way we did not predict when adapting the front-end.

In simple words, before, when no data usage was found for an interface, we deal with an empty array of data, now we are not assigning a default empty value and the progression callback is not called.

My recommendation is to address this as a bug given backing the bugs out is a greater effort. What do you think?
Flags: needinfo?(salva)
Assignee: nobody → mri
(In reply to Salvador de la Puente González [:salva] from comment #10)
> Hello Jason. The problem here is related with bug 814637, bug 937041 and bug
> 937240 in a way we did not predict when adapting the front-end.
> 
> In simple words, before, when no data usage was found for an interface, we
> deal with an empty array of data, now we are not assigning a default empty
> value and the progression callback is not called.
> 
> My recommendation is to address this as a bug given backing the bugs out is
> a greater effort. What do you think?

That's fine - agreed a backout would be difficult to do here. We should try to get a fix quickly, however.
Target Milestone: --- → 1.3 Sprint 6 - 12/6
Attached file proposal patch v1
Please, could you review the code?

Regards
Attachment #8338655 - Flags: review?(salva)
(In reply to Jason Smith [:jsmith] from comment #11)
> (In reply to Salvador de la Puente González [:salva] from comment #10)
> > Hello Jason. The problem here is related with bug 814637, bug 937041 and bug
> > 937240 in a way we did not predict when adapting the front-end.
> > 
> > In simple words, before, when no data usage was found for an interface, we
> > deal with an empty array of data, now we are not assigning a default empty
> > value and the progression callback is not called.
> > 
> > My recommendation is to address this as a bug given backing the bugs out is
> > a greater effort. What do you think?
> 
> That's fine - agreed a backout would be difficult to do here. We should try
> to get a fix quickly, however.

Ok, Josh. Here is the patch and all works fine now. Giving the r+
Thanks!
Comment on attachment 8338655 [details]
proposal patch v1

Very nice patch :mai. Address the comments on GitHub but you have the r+.
Attachment #8338655 - Flags: review?(salva) → review+
Attachment #8338655 - Flags: review+ → review?(salva)
Comment on attachment 8338655 [details]
proposal patch v1

All looking nice. Well done.
Attachment #8338655 - Flags: review?(salva) → review+
 Master: d4b9a3d271f0451b4d903a03c2b931b8cc092041
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
already in master 1.3
blocking-b2g: 1.3? → ---
(In reply to Joe Cheng [:jcheng] from comment #17)
> already in master 1.3

Legitimate blockers should be marked as such.
blocking-b2g: --- → 1.3+
Brui
Gaia:     0d57ec2801ae125ec855a19cf956ab118660d694
Gecko:    http://hg.mozilla.org/mozilla-central/rev/a5e7f611546f
BuildID   20131128040201
Version   28.0a1
ro.build.version.incremental=eng.archermind.20131114.105818

Verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.