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"


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

Gonk (Firefox OS)


(Not tracked)



(Reporter: AndreiH, Assigned: gmealer)



(1 obsolete file)

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/", line 163, in run
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/tests/functional/clock/", line 35, in test_clock_create_new_alarm
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/clock/regions/", line 33, in type_alarm_label
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/", line 213, in send
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/", line 149, in switch_to_keyboard
File "/var/jenkins/workspace/b2g.hamachi.mozilla-central.ui/tests/python/gaia-ui-tests/gaiatest/apps/", 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/", line 143, in until
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)
Assignee: nobody → andrei.hutusoru
I can see more tests failing for this reason:
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?
Keywords: qawanted
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.
Keywords: qawanted
Assignee: andrei.hutusoru → nobody
Attachment #8397056 - Flags: feedback?(zcampbell)
Attachment #8397056 - Flags: feedback?(viorela.ioia)
Attachment #8397056 - Flags: feedback?(dave.hunt)
Attachment #8397056 - Flags: feedback?(bob.silverberg) Hamachi/job/b2g.hamachi.mozilla-central.ui.adhoc/315
test_clock_create_new_alarm seem to work just fine with this fix.
Let's test also the recently 2 fails:
test_url_keyboard  from today's build.
Started adhoc for "test_url_keyboard":
Comment on attachment 8397056 [details]
Link to Github pull-request:

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:

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-
Attachment #8397056 - Flags: feedback?(viorela.ioia)
Attachment #8397056 - Attachment is obsolete: true
Attachment #8397056 - Flags: feedback?(bob.silverberg)
The latest failures when testing Keyboard in UI Tests:
This has been stable lately, we didn't change the tests at all.
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:

Gaia      725a23802708eb70e3d7e8a2ce7179adbac806e4
BuildID   20140429040202
Version   32.0a1 Dec 23 16:36:04 CST 2013

I was not able to reproduce it locally.
Resolution: WORKSFORME → ---
This needs more investigation. Was reproduced in latest build on test_keyboard_basic (test_keyboard.TestKeyboard)

Gaia      15ac34804eb8b3c9b2582d7cf754c57e23182df6                         
BuildID   20140509040202                                                   
Version   32.0a1                                                               Dec 23 16:36:04 CST 2013
Priority: -- → P1
I've been able to reproduce this failure by running on desktopb2g locally:
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:
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
BuildID   20140729040211
Version   34.0a1 Jun 16 16:51:29 CST 2014
This is also reproducible in latest master build,  is failing:
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.
Flags: needinfo?(gmealer)
(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.
Flags: needinfo?(gmealer)
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.
Flags: needinfo?(gmealer)
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.
Closed: 6 years ago6 years ago
Flags: needinfo?(gmealer)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.