### 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

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.

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

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

.: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?

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?

(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.

Please, could you review the code? Regards

(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+.

Comment on attachment 8338655 [details] proposal patch v1 All looking nice. Well done.

Master: d4b9a3d271f0451b4d903a03c2b931b8cc092041

already in master 1.3

(In reply to Joe Cheng [:jcheng] from comment #17) > already in master 1.3 Legitimate blockers should be marked as such.

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