811953 - [keyboard] Submitting a form from a text field with the keyboard up persists the keyboard

Status: VERIFIED FIXED

Description

[Jason Smith [:jsmith]]

Build:

Device - Unagi

Hashes

  <project name="gaia" path="gaia" remote="b2g" revision="1c884f41292650615b04ca9f40cab981ea9e4d00"/>
  <project name="releases-mozilla-aurora" path="gecko" remote="mozilla" revision="76848b5c67e6c164b28f366534e5eeab8fcadc2a"/>

Example Steps (although there's many ways to reproduce this):

1. Go to bugzilla.mozilla.org in the browser
2. In search text box above, type in a valid bug number and hit enter

Expected

The keyboard should disappear upon submitting the form to search.

Actual

The keyboard continues to persist post submitting the form and loading of the next page. As a result, the keyboard remains up while viewing the web content that was loaded.

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Ah!  good catch!  I was trying to figure this out yesterday.  Apparantly if you hit the button on the page to submit it will not persist; if you hit return on the VKB it will persist.  

It only requires a submit form text field: going to http://people.mozilla.com/~nhirata/html_tp/formsninput.html , typing in the username field and then hitting return should show this issue as well.

Comment 2

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Created attachment 681771 [details]
screenshot

Screenshot to show why it's a blocker; I ran into this with yesterday's build just by going to the FTU screen trying to type a password and then hitting the home button.

I am easily able to reproduce this issue now.

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Tim,

I wonder if this is a regression from the recent keyboard changes. Can you take a look?

Drivers, I would block on this because the keyboard is open and points to nowhere. It seems a broken feature.

Comment 4

[Jose Manuel Cantera]

this is also a blocker for FB Deep integration as this bug also happens in the FB Login page

Comment 5

[Alex Keybl [:akeybl]]

Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.

Comment 9

[Tim Taubert [:ttaubert]]

Created attachment 687049 [details] [diff] [review]
remove the focus change delay

Let's remove the focus change delay for now. For one, it doesn't actually work and the keyboard still fades in and out when changing input fields. Second, it's the cause of this bug. We should file a follow-up for switching input fields without a flickering keyboard but I think we should tackle this after bug 766066 that removes the ime-enabled-state-changed handler from forms.js.

Comment 10

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Comment on attachment 687049 [details] [diff] [review]
remove the focus change delay

Review of attachment 687049 [details] [diff] [review]:
-----------------------------------------------------------------

The logic could be done in Gaia to not show/hide the keyboard too fast.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/496c379c8d16

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/496c379c8d16

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/a22fef8e13ae
https://hg.mozilla.org/releases/mozilla-beta/rev/2b31036aab8c

Comment 16

[John Hammink]

Fix verified on 12/3/12 nightly.

Comment 17

[Chris Peterson [:cpeterson]]

I opened bug 819593 for the keyboard flickering problem.