1112416 - Keyboard becomes black after tapping on Rocketbar and then tap on Phone field in Add Contact screen

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Input Mgmt, defect)

Description

[Pi Wei Cheng [:piwei] (inactive)]

Attachment: logcat on Flame 2.2

Issue found while verifying for bug 1097936. Keyboard turns black after tapping on Rocketbar and then tapping on Phone field again while inside Add Contact page in Contacts app.

Prerequisites:
- DUT is connected to internet
- Rocketbar has been previously accessed so it won't prompt for geolocation when tapped on

STR:
1) Open Contacts app
2) Add a new contact by tapping on the plus icon
3) Tap on Phone field to bring up the number keypad
4) Tap on Rocketbar to turn number keypad into a regular keyboard
5) Tap on Phone field again

Expected: Regular keyboard turns into number keyboard

Actual: Regular keyboard turns into black space

Repro rate: 9/10

Attaching a logcat.

Tested on a b2g inbound build to make sure fix for bug 1106651 didn't fix this issue.

Device: Flame 2.2 Master (512MB mem, shallow flash)
BuildID: 20141216150511
Gaia: d22dfece04fc00457e8369c660c11f945b088d2f
Gecko: 8bf703caae32
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 1

[Pi Wei Cheng [:piwei] (inactive)]

Adding a video:

http://youtu.be/IpbH-vP5AgM

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Looks like a blocker to me.

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

After probing System app with app manager I can rule out Input Method API here. This is probably an input mgmt regression.

:mnjul, could you take a look? Thanks. Please set regressionwindow-wanted if you need it.

Comment 4

[John Lu [:mnjul][Please NI or I'll miss]]

Yeah lemme take a look today. Keeping NI for reminding.

Comment 5

[John Lu [:mnjul][Please NI or I'll miss]]

Yah there is a racing on input management/keyboard. I'll provide a band-aid fix.

Comment 6

[John Lu [:mnjul][Please NI or I'll miss]]

Attachment: Proposed Patch (PR @ GitHub)

The scenario

B(lur) sequence
IM-B1 / KeyboardManager receives blur
IM-B2 / InputWindowManager tries to close the inputApp
IM-B3 / InputWindow starts closing transition
IM-B4 / InputWindow finishes closing transition and InputWindowManager deactivates the inputApp
KB-B5 / Keyboard receives inputContextChange = null

F(ocus) sequence
IM-F1 / KeyboardManager receives focus on tel input
IM-F2 / InputWindowManager tries to open the inputApp; InputWindow activates the inputApp and waits for inputApp to be ready
KB-F3 / Keyboard receives inputContextChange = tel input
KB-F4 / Keyboard is ready through mozbrowserresizeevent to InputMgmt
KB-F5 / and InputWindowManager

The only thing we can guarantee w.r.t ordering is that IM-F1 is after IM-B1, and that B5 is after B4 after B3 after B2 after B1, and the same for F sequence.

If the (partial) ordering is [IM-B4, IM-F1, IM-F2, KB-F3, KB-B5] then KB-B5 will abort KB-F3's progress of becoming ready and the F sequence will stuck at IM-F2's wait for KB-F4's finish.

--

So, this band-aid fix sets a _pendingReady flag at KB-F2 so when we're closing a inputWindow with _pendingReady = true, we won't deactivate its inputApp, effectively terminating B sequence at IM-B4.

Tim, please review the patch, thanks. As offline discussed we'll still see a blank but interaction-able area out there, which is probably a graphics bug. I'll videotape the issue for QA's reference and I'll file that follow-up bug.

And I'll file a "let InputMgmt implement AbortableTaskQueue" bug later.

I have not traced the regressing bug and I'll be onto it soon. It's either the "remove timeout" or the IWM/IW, I believe.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 8537644 [details] [review]
Proposed Patch (PR @ GitHub)

Please make sure this won't break in "fast focus-blur-focus between two apps" situation.

Comment 8

[John Lu [:mnjul][Please NI or I'll miss]]

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #6)
> I have not traced the regressing bug and I'll be onto it soon. It's either
> the "remove timeout" or the IWM/IW, I believe.

I didn't bisect this successfully because in earlier Gaia versions the rocketbar is too hard to trigger in other apps :/

Comment 9

[John Lu [:mnjul][Please NI or I'll miss]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #7)
> Comment on attachment 8537644 [details] [review]
> Proposed Patch (PR @ GitHub)
> 
> Please make sure this won't break in "fast focus-blur-focus between two
> apps" situation.

Yeah it works. (Offline demo'ed to Tim.)

Try run before landing: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=09db7982e26c (which is not available due to bug 1112456, I guess)

Comment 10

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8537644 [details] [review]
Proposed Patch (PR @ GitHub)

Tim,

I found the cause for blank-but-interactionable keyboard when switching back from Rocketbar to Contacts app and it's Gaia-related.

AppTransitionController would automatically setVisible(false) on its appWindow when it's transitioned to |closed| state [1]; as my prior patch did not re-setInputMethodActive(true), the inputWindow would remain in a ... limbo state? Why it was interactionable is beyond me.

The correct way is to not setVisible(false) in AppTransitionController when its appWindow is an inputWindow. For sure, the visibility and activeness of an InputWindow should be under total control of InputWindowManager & InputWindow.

So the patch has been amended as such. Please check and/or discuss and/or come for a demo.

With this patch, when you switch from Rocketbar to Contacts app, you see the Tel keyboard sliding up, just like how I demo'ed with LOL keyboard -> Built-in keyboard under the same steps. (the similarity actually makes sense, doesn't it!)

[1] https://github.com/mozilla-b2g/gaia/pull/26838/files#diff-0

Comment 11

[Joshua Mitchell (Inactive)]

Qa-Wanted - can we get a branch check and make sure no other branches are affected

Comment 12

[Pi Wei Cheng [:piwei] (inactive)]

This issue does NOT occur on Flame 2.1 and Flame 2.0.

Behavior on 2.1: At step 5, tapping on Phone field acts as an action to close the Rocketbar interface and does not automatically bring number keypad up. Phone field needs to be tapped again in order to bring number pad up.

Behavior on 2.0: Rocketbar cannot be accessed while in an app, therefore unable to follow STR.

Device: Flame 2.1
BuildID: 20141216151310
Gaia: 14315733e2d265a42f9ab02d1aba191789870f70
Gecko: ddecea83ce6e
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Device: Flame 2.0
BuildID: 20141216151108
Gaia: d04710d5d643eeff5a6493aef92a1af672a2769c
Gecko: 4d62570b77e4
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

----

Adding a regression keyword on there even though 2.1 acts a bit differently while doing STR.

Comment 13

[John Lu [:mnjul][Please NI or I'll miss]]

Master: https://github.com/mozilla-b2g/gaia/commit/94ca2a544d720b5acabdf34dbcf606972e0924b1

Will keep an eye on Input Mgmt / Keyboard bug reports.

Comment 14

[Yeojin Chung [:YeojinC]]

This issue is verified fixed on Flame 2.2.

Result: The number pad reappears when the number field is selected.

Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141219040202
Gaia: deb90229734e5397cda806fb11f2e001fba83399
Gecko: 021b09e92d30
Gonk: e5c6b275d77ca95fb0f2051c3d2242e6e0d0e442
Version: 37.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

+ for fixed regression.