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)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: zcampbell, Unassigned)
References
Details
(Keywords: pi-marionette-userinput, Whiteboard: [affects=b2g])
Attachments
(1 file)
353 bytes,
text/plain
|
Details |
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
Comment 1•10 years ago
|
||
This blocks full testing of the new homescreen, bumping to P1
Priority: -- → P1
Updated•10 years ago
|
Keywords: ateam-marionette-userinput
Updated•10 years ago
|
Whiteboard: [affects=webqa]
Comment 2•10 years ago
|
||
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}
Reporter | ||
Updated•10 years ago
|
Whiteboard: [affects=webqa] → [affects=b2g]
Updated•10 years ago
|
Attachment #8434970 -
Attachment mime type: text/x-python → text/plain
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
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)
Comment 5•9 years ago
|
||
I'm not actively working on this.
Assignee: dave.hunt → nobody
Status: ASSIGNED → NEW
Comment 6•8 years ago
|
||
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
Updated•1 year ago
|
Product: Testing → Remote Protocol
You need to log in
before you can comment on or make changes to this bug.
Description
•