963377 - [B2G][Keyboard] Keyboard blocks "cancel" / "ok" options

Status: RESOLVED FIXED

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

Description

[Roland Kunkel [:RolandK]]

Attachment: Logcat

When drop downs & text fields are both present on screen, the user can enter a condition where the keyboard will be brought up in front of the cancel / ok buttons for the scroll-slider options.

Repro Steps:
1) Update Buri to BuildID: 20140121004137
2) Open Calendar App.
3) Select the '+' button in the top right corner.
4) Very quickly, <1 second select both the "Where" text field and any of the options below that prompt the scroll-slider. I.E start date, end date, start time, end time, ect.

Actual:
Keyboard is displayed over the "cancel" and "ok" buttons.

Expected:
"cancel" and "ok" buttons are displayed properly.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140121004137
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Gecko: 6f7dfe36ab6c
Version: 28.0a2
Firmware Version: V1.2-device.cfg

Notes: 
This will occur with APZ disabled.

Repro frequency: 100%
See attached: Logcat, Screenshot

Comment 1

[Roland Kunkel [:RolandK]]

Attachment: Screenshot

This issue does not reproduce on the latest v1.2 build.

Environmental Variables:
Device: Buri 1.2 MOZ
BuildID: 20131021004006
Gaia: 1fd315337d8ae891c3024e4c682c4c50797ea40e
Gecko: d585fe28cd55
Version: 26.0a2
Firmware Version: V1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

Actually - let's see if we can find more realistic end-user STR. Can we see if we can reproduce this without moving at fast speeds?

Comment 3

[pfield]

I've attached a video that demonstrates how easy this issue is to get. I was able to get this issue only pressing around 2 - 3 times. Which is very easy.

This issue occurs on the latest Buri 1.3

Environmental Variables:
Device: buri 1.3 moz
BuildID: 20140130004001
Gaia: 8defa5bf0cbce290c649e564b7f3ebe708e19b23
Gecko: 6b12800e0e46
Version: 28.0a2
Firmware Version: V1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

Where's the video?

Comment 5

[pfield]

Apologies, I forgot to add the URL to the youtube video.

http://www.youtube.com/watch?v=i8cr8f7AhXM

Comment 6

[Jason Smith [:jsmith]]

The video in the STR looks realistic for an end-user, so this seems like something we need to block on.

Comment 7

[pfield]

This issue started to occur on the Buri 1.3 Build ID: 20131121040202

Environmental Variables:
Device: Buri 1.3 moz
BuildID: 20131121040202
Gaia: 71063dd91bc8cbb15ba335236ed67a1c5058bd58
Gecko: cf378dddfac8
Version: 28.0a1
Firmware Version: V1.2-device.cfg


Last working Buri 1.3 Build ID: 20131120040202

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20131120040202
Gaia: c26480b22ce28c812c347290dd4bad090d83db6f
Gecko: 4f993fa378eb
Version: 28.0a1
Firmware Version: V1.2-device.cfg

Comment 8

[Preeti Raghunath(:Preeti)]

Rudy,

Please investigate.

Comment 9

[Hema Koka [:hema]]

Diego - can you investigate and provide any information that can help Rudy when he is back tomorrow.

Comment 10

[David Flanagan [:djf]]

I can reproduce this on a hamachi running yesterday's 1.3 master.

Also setting needinfo for Jan and Yuan who probably have the most directly relevant experience for this bug.  Unfortunately Jan is busy at a Paris workweek and Yuan may still be out for chinese new year

Comment 11

[David Flanagan [:djf]]

I can also duplicate this using UITests->Keyboard.  I scroll down until the email and date fields are visible.  If I tap on email and then on date with the right timing I get the same symptom of both the keyboard and the date picker being exposed with no obvious way to dismiss either one.

Note that if I tap date first the bug does not occur.  It looks like the date picker opens immediately and fades in.  While the keyboard animates up from the bottom after a short delay. During this delay the user can still tap on the date field and bring it up without cancelling the keyboard opening.

The user does have options here. Quickly swiping down on the keyboard will dismiss it (and the date field). It generally takes me a couple of tries to get this to work, though.  Also, tapping the home button and then returning to the app serves to dismiss the date picker and keyboard.  I agree, however, with the blocking decision.

I know that Jan has worked on the keyboard opening animation. The code for it is probably in the system app somewhere.  The date picker is also implemented in the system app.  But the code that handles the user's taps and ultimately causes the keyboard or date picker to be popped up is in b2g/chrome/content/forms.js.  I'm not sure whether the relevant delay is in that gecko file or in the system app.  I'm almost positive that the issue is not in the keyboard app itself, however.

In the past, I know we've had delays before closing a keyboard because the user often switches from one text field to another and we don't want to start dismissing it on a blur event only to reopen it on a focus event that follows immediately afterward.  My point is, that if there is a delay in opening the keyboard, it is probably there for some good reason. The solution probably won't be in removing the delay in opening the keyboard, but in making the keyboard smarter about hiding itself if a date picker is opened in the meantime.

At the risk of flagging the entire keyboard team, I'm going to set needinfo for Tim as well, since he knows this part of the code and this bug should be on his radar.

Comment 12

[David Flanagan [:djf]]

If anyone is available to work on this bug, I'm sure Diego would be happy to have you take it from him. It was assigned to him only out of desperation caused by Chinese new year :-)

Comment 13

[Diego Marcos [:dmarcos]]

I can reproduce the problem as well on master. I'm digging in the code to see what I find. If someone can give me directions I could move faster. If someone has experience on this part of gaia and thinks it's an easy fix go ahead and take it from me. I keep investigating until I hear news from this bug.

Comment 14

[Jean Gong :jgong]

PM team reviewed this bug and it needs to be blocker.

Comment 15

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

It is unfortunate that a regression is only found at this late stage.

Rudy, could you work on this? Thanks.

Comment 16

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 17

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Will take a look.

Comment 18

[Jan Jongboom [:janjongboom] (inactive)]

Let me know if you need anything in Gecko.

Comment 19

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Attachment: Patch V1 - pull request 15976

One-line patch to fix this race condition issue.

[Root Cause]
In the case below, keyboard app would get "input context change" event and notify keyboard manager to show the keyboard.
 1. Click on a input field.
 2. Click on a input type="date" or "time".

The event sequence is:
 1. Keyboard manager would try to show the keyboard for step 1.
 2. Keyboard manager would get blur event for step 2 first before the keyboard app is shown, and it won't reset keyboard state (remove resize event handler, etc.), since the keyboard app is not shown yet.
 3. Keyboard app would get inputcontextchange event after step 2 and notify keyboard manager to show itself, and may overlay on the value selector.

[Solution]
Always reset the keyboard state in KeyboardManager:hideKeyboard(), so that it won't receive resize event from keyboard app when it is not necessary.

Dear Tim,

Could you please help review this patch?
Thanks.

Comment 20

[Anthony Ricaud (:rik)]

Rudy: Because this is a regression, I think it's even more important to fix this with new tests. Is it possible?

Comment 21

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

Sorry, I thought I did yesterday.

And yes, please write a unit test for this.

master: https://github.com/mozilla-b2g/gaia/commit/1aa8e778a0368e98eb1b5d534285a47c29068951

Comment 22

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

v1.3,
https://github.com/mozilla-b2g/gaia/commit/fe1632f6aeed4e6a3db0e5632c69892f2fe7c338