Closed Bug 1112416 Opened 5 years ago Closed 5 years ago
Keyboard becomes black after tapping on Rocketbar and then tap on Phone field in Add Contact screen
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
Adding a video: http://youtu.be/IpbH-vP5AgM
Looks like a blocker to me.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
blocking-b2g: --- → 2.2?
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.
Assignee: timdream → nobody
Status: ASSIGNED → NEW
Component: Gaia::Keyboard → Gaia::System::Input Mgmt
Yeah lemme take a look today. Keeping NI for reminding.
Yah there is a racing on input management/keyboard. I'll provide a band-aid fix.
Assignee: nobody → jlu
Status: NEW → ASSIGNED
Target Milestone: --- → 2.2 S2 (19dec)
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.
Attachment #8537644 - Flags: review?(timdream)
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.
(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 :/
(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 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 ; 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!)  https://github.com/mozilla-b2g/gaia/pull/26838/files#diff-0
Attachment #8537644 - Flags: review+ → review?(timdream)
Qa-Wanted - can we get a branch check and make sure no other branches are affected
QA Whiteboard: [QAnalyst-Triage?]
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.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Master: https://github.com/mozilla-b2g/gaia/commit/94ca2a544d720b5acabdf34dbcf606972e0924b1 Will keep an eye on Input Mgmt / Keyboard bug reports.
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
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
+ for fixed regression.
blocking-b2g: 2.2? → 2.2+
You need to log in before you can comment on or make changes to this bug.