Closed Bug 986431 Opened 6 years ago Closed 6 years ago
Investigate why tests are failing with "Keyboard not interpreted as displayed
. Debug is _displayed(): False"
No description provided.
This fails on CI with: Traceback (most recent call last): File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/.env/local/lib/python2.7/site-packages/marionette_client-0.7.5-py2.7.egg/marionette/marionette_test.py", line 163, in run testMethod() File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/tests/functional/clock/test_clock_create_new_alarm.py", line 35, in test_clock_create_new_alarm new_alarm.type_alarm_label(alarm_label_text) File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/clock/regions/alarm.py", line 33, in type_alarm_label self.keyboard.send(value) File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/app.py", line 213, in send self.switch_to_keyboard() File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/app.py", line 149, in switch_to_keyboard %keyboards.is_displayed()) File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/base.py", line 54, in wait_for_condition Wait(self.marionette, timeout).until(method, message=message) File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/.env/local/lib/python2.7/site-packages/marionette_client-0.7.5-py2.7.egg/marionette/wait.py", line 143, in until cause=last_exc) TimeoutException: TimeoutException: Timed out after 30.0481901169 seconds with message: Keyboard not interpreted as displayed. Debug is_displayed(): False I'll investigate this and try to come up with a fix, and start an adhoc job
OS: Linux → Gonk (Firefox OS)
I can see more tests failing for this reason: test_keyboard_predictive_key.py test_clock_create_new_alarm.py test_clock_add_alarm_multiple_times.py
Summary: Investigate test_clock_create_new_alarm.TestClockCreateNewAlarm on CI → Investigate why tests are failing with "Keyboard not interpreted as displayed. Debug is_displayed(): False"
Can we do exploratory testing on trunk to check if predictive text in the keyboard & the clock works fine?
I was not able to reproduce this locally, even though I ran the tests several times. Manually neither. From the stacktrace it looks like the keyboard is not displayed.
test_clock_create_new_alarm seem to work just fine with this fix. Let's test also the recently 2 fails: test_clock_add_alarm_multiple_times and test_url_keyboard from today's build. Started adhoc for "test_url_keyboard": http://selenium.qa.mtv2.mozilla.com:8080/view/B2G%20Master/job/b2g.hamachi.mozilla-central.ui.adhoc/316/console
Comment on attachment 8397056 [details] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17647/files r- , I'd be extremely surprised if this resolved the problem because each time it times out we know this value is False already. The problem is likely to lie in the step *before* this one, or the OOM killer killing the keyboard.
Attachment #8397056 - Flags: feedback?(zcampbell) → feedback-
Or the keyboard crashing.
Comment on attachment 8397056 [details] Link to Github pull-request: https://github.com/mozilla-b2g/gaia/pull/17647/files I think you need to provide some more context to your fix. What investigation have you carried out, why is this an appropriate fix. Without that extra detail, I'm with Zac in feeling that this is a superfluous check.
Attachment #8397056 - Flags: feedback?(dave.hunt) → feedback-
The latest failures when testing Keyboard in UI Tests: http://selenium.qa.mtv2.mozilla.com:8080/job/b2g.hamachi.mozilla-central.ui.2/264/consoleFull
This has been stable lately, we didn't change the tests at all.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
This issue is reproducible in the latest master build. We have test_clock_create_new_alarm failing with this error: http://selenium.qa.mtv2.mozilla.com:8080/view/B2G%20Hamachi/job/b2g.hamachi.mozilla-central.ui.smoketest/728/testReport/junit/test_clock_create_new_alarm/TestClockCreateNewAlarm/test_clock_create_new_alarm/ Gaia 725a23802708eb70e3d7e8a2ce7179adbac806e4 Gecko https://hg.mozilla.org/mozilla-central/rev/d7c07694f339 BuildID 20140429040202 Version 32.0a1 ro.build.version.incremental=eng.tclxa.20131223.163538 ro.build.date=Mon Dec 23 16:36:04 CST 2013 I was not able to reproduce it locally.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
This needs more investigation. Was reproduced in latest build on test_keyboard_basic (test_keyboard.TestKeyboard) Build: Gaia 15ac34804eb8b3c9b2582d7cf754c57e23182df6 Gecko https://hg.mozilla.org/mozilla-central/rev/cf89b5d018f8 BuildID 20140509040202 Version 32.0a1 ro.build.version.incremental=eng.tclxa.20131223.163538 ro.build.date=Mon Dec 23 16:36:04 CST 2013
I've been able to reproduce this failure by running test_clock_create_new_alarm.py on desktopb2g locally: https://pastebin.mozilla.org/5331363 Also, I opened a pull request for trying to re-enable the clock tests on Travis and I saw them failing with the same error: https://travis-ci.org/mozilla-b2g/gaia/jobs/26662625#L1864 I'm still investigating this failure
Viorela, I think you need to look at the steps before the keyboard. Possibly the step that taps onto the input field is not tapping in the right spot and thus the keyboard is never triggered to open.
we can see this reproducing in: Gaia fadfafa17f5175203b8b9457bfb95e5816f54f58 Gecko https://hg.mozilla.org/mozilla-central/rev/b17cad2d1e5e BuildID 20140729040211 Version 34.0a1 ro.build.version.incremental=109 ro.build.date=Mon Jun 16 16:51:29 CST 2014 B1TC00011220
This is also reproducible in latest master build, test_cost_control_data_alert_mobile.py is failing: http://jenkins1.qa.scl3.mozilla.com/job/flame.mozilla-central.ui.functional.non-smoke/127/HTML_Report/ It looks like the input field was not tapped, that's why the keyboard was not displayed. If I tap it manually, the test is passing. I'll still work on this. Device firmware (date) 28 Aug 2014 08:29:26 Device firmware (incremental) eng.cltbld.20140828.112916 Device firmware (release) 4.3 Device identifier flame Gaia date 01 Sep 2014 11:20:22 Gaia revision 44bf2e3bc5dd Gecko build 20140902040205 Gecko revision c360f3d1c00d Gecko version 34.0a1
:geo, are you taking this bug? this one's hot and being requested from our partners, so gaining traction on this.
(In reply to Tony Chung [:tchung] from comment #20) > :geo, are you taking this bug? this one's hot and being requested from our > partners, so gaining traction on this. Yes. I'll assign it to myself as soon as I start investigation on it.
Assignee: nobody → gmealer
QA Whiteboard: [fxosqa-auto-from-s2] [fxosqa-auto-s3]
QA Whiteboard: [fxosqa-auto-from-s2] [fxosqa-auto-s3] → [fxosqa-auto-from-s2] [fxosqa-auto-from-s3] [fxosqa-auto-s4]
I tried to reproduce this on desktop B2G on Mac, but I wasn't able to.
Yeah, I don't think anyone has been able to reproduce this recently. I haven't had any luck either, and Viorela mentioned not being able to do so anymore either. We discussed in the last meeting setting this to WORKSFORME and re-opening if we have another example case. I'll leave this comment here for a day or two, then I'm going to do that.
NI'ing myself to remind myself to do this.
Per inability to repro mentioned in comment 23, marking this WORKSFORME. If it reappears, please reopen this bug with as much information for reproduction as possible.
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.