Closed Bug 1011033 Opened 6 years ago Closed 6 years ago

Restarting B2G fails when the lockscreen is displayed

Categories

(Firefox OS Graveyard :: Gaia::UI Tests, defect, P3)

x86_64
Linux
defect

Tracking

(b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S5 (4july)
Tracking Status
b2g-v2.0 --- fixed

People

(Reporter: zcampbell, Assigned: davehunt)

References

Details

(Keywords: perf, Whiteboard: [c=automation p= s=2014.07.04.t u=])

Attachments

(1 file)

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.
Flags: needinfo?(zcampbell)
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.
Flags: needinfo?(zcampbell)
Assignee: nobody → zcampbell
Duplicate of this bug: 1013016
Note that this also affects b2gperf, and any other package that restarts without performing a reset.
Keywords: perf
Whiteboard: [c=automation p= s= u=]
Assignee: zcampbell → nobody
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.
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+
Landed in:
https://github.com/mozilla-b2g/gaia/commit/8f7131ed14fc1eccfe5c0e68bc5154e3fac8fc01
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [c=automation p= s= u=] → [c=automation p= s=2014.07.04.t u=]
Target Milestone: --- → 2.0 S5 (4july)
You need to log in before you can comment on or make changes to this bug.