1203269 - test_lockscreen_unlock_to_homescreen_with_passcode.py: TimeoutException: TimeoutException: Timed out after 10.0 seconds

Status: RESOLVED FIXED

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

Description

[Nicholas Nelson [:NicholasN]]

Description:

This test times out on the lockscreen, and no numbers are inputted for the code. When reproducing this manually, I experienced no issues with unlocking the device.

Steps:
1. Update a flame device to 20150909030221.
2. Enable screen lock.
3. Lock the device and then wake it up.
4. Input the lock code.

Actual result:
Test times out on lockscreen.

Expected result:
Test completes successfully.

Repro Rate: 5/5 in jenkins adhoc

Traceback (most recent call last):
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_client-0.17-py2.7.egg/marionette/marionette_test.py", line 296, in run
testMethod()
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/tests/functional/lockscreen/test_lockscreen_unlock_to_homescreen_with_passcode.py", line 29, in test_unlock_to_homescreen_with_passcode
homescreen = lock_screen.unlock_to_homescreen_using_passcode(self._input_passcode)
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/apps/lockscreen/app.py", line 84, in unlock_to_homescreen_using_passcode
self.wait_for_lockscreen_not_visible()
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/tests/python/gaia-ui-tests/gaiatest/apps/lockscreen/app.py", line 103, in wait_for_lockscreen_not_visible
Wait(self.marionette).until(expected.element_not_displayed(*self._lockscreen_locator))
File "/var/lib/jenkins/jobs/flame-kk-319.mozilla-central.nightly.ui.functional.non-smoke.1.bitbar/workspace/.env/lib/python2.7/site-packages/marionette_driver-0.13-py2.7.egg/marionette_driver/wait.py", line 143, in until
cause=last_exc)
TimeoutException: TimeoutException: Timed out after 10.0 seconds

Comment 1

[Martijn Wargers (dead)]

When I add a time.sleep(5) between every tap(), I noticed that for some reason on every tap() call, the 2 numbers are added at the same time.
I vaguely remember we had this problem before, didn't we?

Comment 2

[Martijn Wargers (dead)]

I suspect this to be a regression from bug 1187979. Perhaps marionette singleTap is not working correctly? But that would be weird, because everywhere else it doesn't have this problem.
This is the singleTap method that is being called when the tap() method is called on the keypad buttons:
http://mxr.mozilla.org/mozilla-central/source/testing/marionette/listener.js#914

Christiane, perhaps you could give some more insights here on why our tap() method suddenly generates 2 inputs in the keypad?

Comment 3

[Christiane Ruetten [INACTIVE]]

I can't come up with anything obviously wrong with my code, but then again, I am relatively unaware of the internals of browser events. I need to dig deepr into that testing code, but first intuition: Could the cause be that inputpad handles both the 'touchend' and the 'click' event? It goes by the book and calls .preventDefault() on the 'touchend' event to prevent the browser from executing the 'click'.

https://mxr.mozilla.org/gaia/source/apps/system/lockscreen/js/lockscreen_inputpad.js#131

I followed the test code to https://mxr.mozilla.org/gaia/source/tests/python/gaia-ui-tests/gaiatest/apps/lockscreen/regions/passcode_pad.py#32 , but from there I still need to figure out how it ends up at http://mxr.mozilla.org/mozilla-central/source/testing/marionette/listener.js#914 and in which state.

My main concern is that .singleTap() has the potential to emit both touch and mouse events in series, and at this point I can neither say if both are emitted, nor if it would be correctly caught by .preventDefault().

931     if (!actions.mouseEventsOnly) {
932       let touchId = actions.nextTouchId++;
933       let touch = createATouch(el, c.x, c.y, touchId);
934       emitTouchEvent('touchstart', touch);
935       emitTouchEvent('touchend', touch);
936     }
937     actions.mouseTap(el.ownerDocument, c.x, c.y);

Before I dig deeper into Marionette here, perhaps you already have a better idea what's going on there in detail?

Comment 4

[Martijn Wargers (dead)]

Thanks for your help!
I definitely think there is something wrong with Marionette tap() method here. It should behave the same as a user would tap on an element, which is clearly not happening here.

I'm currently looking for a workaround to fix this test, then I'll try to come up with a testcase that exposes the difference between a user tap and a Marionette tap.

I tried to use this instead as a workaround:
Actions(self.marionette).tap(self.marionette.find_element(*button_locator)).perform()
But that also types 2 digits at once in the keypad.

Comment 5

[GitHub Autolander Bot]

Attachment: [gaia] mwargers:1203269 > mozilla-b2g:master

Comment 6

[Martijn Wargers (dead)]

Comment on attachment 8659230 [details] [review]
[gaia] mwargers:1203269 > mozilla-b2g:master

This is the workaround. Somehow the wait(time=0.5) is necessary, otherwise I still get 2 digits to be entered.

Comment 7

[Johan Lorenzo [:jlorenzo]]

Comment on attachment 8659230 [details] [review]
[gaia] mwargers:1203269 > mozilla-b2g:master

This temporary workaround looks good to me.

Comment 8

[No-Jun Park [:njpark]]

Comment on attachment 8659230 [details] [review]
[gaia] mwargers:1203269 > mozilla-b2g:master

Hmm, strange this happens, but workaround looks good to me too.

Comment 9

[Martijn Wargers (dead)]

I filed bug 1203586 as a follow-up.

Comment 10

[Martijn Wargers (dead)]

Merged: https://github.com/mozilla-b2g/gaia/commit/2bd8d1dac1311a9854b75b8ab12f8ada055dce1a