Closed Bug 1020974 Opened 10 years ago Closed 8 years ago

Marionette tap on vertical homescreen does not trigger the keyboard opening

Categories

(Remote Protocol :: Marionette, defect, P1)

Other
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: zcampbell, Unassigned)

References

Details

(Keywords: pi-marionette-userinput, Whiteboard: [affects=b2g])

Attachments

(1 file)

Attached file Test case
Tapping the vertical search bar with Marionette does not open the keyboard.

Test case attached.

logcat next

Device: Flame
Gaia      d2cfef555dabab415085e548ed44c48a99be5c32
Gecko     https://hg.mozilla.org/mozilla-central/rev/51b428be6213
BuildID   20140604235615
Version   32.0a1
ro.build.version.incremental=eng.cltbld.20140605.031251
ro.build.date=Thu Jun  5 03:13:01 EDT 2014
Blocks: 1019906
This blocks full testing of the new homescreen, bumping to P1
Priority: -- → P1
Blocks: 1019905
Whiteboard: [affects=webqa]
Actually tapping on the search bar with marionette opens the keyboard when in debug mode,
the test fails on the next step.
The keyboard disappears when in "switch_to_keyboard" method at "self.marionette.switch_to_frame()" step.

https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/gaiatest/apps/keyboard/app.py#L147


Logcat:

I/Gecko   ( 2054): 1405347007583	Marionette	DEBUG	Got request: switchToFrame, data: {"to":"0","sessionId":{"rotatable":true,"browserVersion":"32.0a2","takesScreenshot":true,"appBuildId":"20140714000202","XULappId":"{3c2e2abc-06d4-11e1-ac3b-374f68613e61}","secureSsl":false,"platform":"ANDROID","browserName":"B2G","version":"32.0a2","device":"msm8610","b2g":true,"nativeEvents":false,"platformVersion":"32.0a2","takesElementScreenshot":true,"platformName":"ANDROID","handlesAlerts":false},"name":"switchToFrame","parameters":{"id":null,"focus":true}}, id: {7b958729-3ca1-4452-99c6-5c2befaf6a59}
I/Gecko   ( 2054): 1405347007606	Marionette	INFO	Switched to frame: {"frameValue":null}
Whiteboard: [affects=webqa] → [affects=b2g]
Attachment #8434970 - Attachment mime type: text/x-python → text/plain
When debugging this it appears that switching frames is firing a inputmethod-contextchange with type of blur for the input and therefore the keyboard is being hidden. Using m.switch_to_frame(focus=False) doesn't appear to help.

Strangely, when adding breakpoints the behaviour is as I would expect, in that with focus=False the keyboard stays open but if focus=True the keyboard is hidden. Without any breakpoints the keyboard appears to always hide the keyboard. Perhaps some kind of race condition.

Malini: Any guesses what's causing this, or suggestions for where to look next?
Assignee: nobody → dave.hunt
Status: NEW → ASSIGNED
Flags: needinfo?(mdas)
not sure about the race condition at all here, I just suggest adding breakpoints before and after the focus() call in switchToFrame to see if some other event is being fired after focus() is called to cause the keyboard to become hidden
Flags: needinfo?(mdas)
Depends on: 1157772
Blocks: 1062309
I'm not actively working on this.
Assignee: dave.hunt → nobody
Status: ASSIGNED → NEW
Closing out B2G related bugs. If these still happen and are valuable, please reopen with details again and how this affects Desktop/Fennec
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: