Closed Bug 1011033 Opened 6 years ago Closed 6 years ago
Restarting B2G fails when the lockscreen is displayed
46 bytes, text/x-github-pull-request
|Details | Review|
This bug is for when running the UI tests against a desktopb2g build and profile that boots into the lockscreen rather than to the FTU. To replicate: 1. start up desktopb2g manually and complete the FTU. Lockscreen should be enabled by default. 2. Stop b2g 3. Run tests against that binary/profile
That's sad, it certainly used to work. :( Can you paste the traceback?
I lost the traceback because I was in the middle of doing something else but should be pretty easy to replicate.
I'm able to replicate this, but only if I specify --restart on the command line. Here's the traceback: Traceback (most recent call last): File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/marionette_test.py", line 152, in run self.setUp() File "/Users/dhunt/workspace/gaia/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 638, in setUp self.device.start_b2g() File "/Users/dhunt/workspace/gaia/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 512, in start_b2g .until(lambda m: m.find_element(*locator).is_displayed()) File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/wait.py", line 143, in until cause=last_exc) TimeoutException: Traceback (most recent call last): File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/wait.py", line 122, in until rv = condition(self.marionette) File "/Users/dhunt/workspace/gaia/tests/python/gaia-ui-tests/gaiatest/gaia_test.py", line 512, in <lambda> .until(lambda m: m.find_element(*locator).is_displayed()) File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/marionette.py", line 1211, in find_element response = self._send_message('findElement', 'value', **kwargs) File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/decorators.py", line 35, in _ return func(*args, **kwargs) File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/marionette.py", line 631, in _send_message self._handle_error(response) File "/Users/dhunt/workspace/mozilla/mozilla-central/testing/marionette/client/marionette/marionette.py", line 662, in _handle_error raise NoSuchElementException(message=message, status=status, stacktrace=stacktrace) TEST-UNEXPECTED-FAIL | test_cold_launch.py test_cold_launch.TestColdLaunch.test_cold_launch | TimeoutException: Traceback (most recent call last): This is because the lockscreen is not an app in the same way as FTU is, and doesn't have the 'render' class. You will find that this issue also exits for the devices if they start with the lockscreen. This is therefore a regression from bug 999355. FWIF, I was recently experimenting with the restart wait, and had some success with the following for both lockscreen and FTU restart scenarios: homescreen = Wait(m, timeout=60).until(expected.element_present(By.ID, 'homescreen')) Wait(m, timeout=60).until(lambda m: homescreen.get_attribute('loading-state') == 'false') :zac I see the 'render' change was reverted a couple of times. Is it bringing much benefit? The bug doesn't give much background. Hopefully bug 924912 will provide a final solution for this, one day.
Summary: Running tests against a desktopb2g profile that does not have ftu fails → Restarting B2G fails when the lockscreen is displayed
I don't think 'render' has made a huge change (hard to tell amongst the noise), but it does take a bit longer to start up which makes me feel better! We reverted it once because we thought it was causing marketplace-tests-gaia a problem but that turned out not to be the case, but then it caused the problem on 1.3t. I'm willing to give the homescreen wait a try.
Assignee: nobody → zcampbell
Duplicate of this bug: 1013016
Note that this also affects b2gperf, and any other package that restarts without performing a reset.
Whiteboard: [c=automation p= s= u=]
I'll take this, and will come back with some results for testing the suggested homescreen wait.
Assignee: nobody → dave.hunt
Status: NEW → ASSIGNED
Using iPython here are the results of my tests. Wait for #homescreen[loading-state=false] to be present With reset: 10 loops, best of 3: 43.6 s per loop Without reset: 10 loops, best of 3: 26.2 s per loop Wait for div.appWindow.active.render to be displayed With reset: 10 loops, best of 3: 41.8 s per loop Without reset: FAILS This looks good. The new wait takes a little longer but to me that's a good indication that we're waiting long enough. I'll submit a patch later today.
Depends on: 1008234
FTR, this doesn't work on v1.3, so we need a solution to that before this can land. I believe we are planning on releasing a version of gaiatest to PyPI which does work for v1.3 (which would be the current master), which we can then pin to.
Comment on attachment 8427750 [details] [review] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/19599 Works well. Nice work!
Attachment #8427750 - Flags: review?(bob.silverberg) → review+
Depends on: 994176
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [c=automation p= s= u=] → [c=automation p= s=2014.07.04.t u=]
You need to log in before you can comment on or make changes to this bug.