Closed Bug 811953 Opened 8 years ago Closed 8 years ago

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

Categories

(Firefox OS Graveyard :: General, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

VERIFIED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: jsmith, Assigned: ttaubert)

References

Details

Attachments

(2 files)

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.
blocking-basecamp: --- → ?
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.
Attached image 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.
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.
blocking-basecamp: ? → +
Priority: -- → P2
this is also a blocker for FB Deep integration as this bug also happens in the FB Login page
Component: Gaia → Gaia::System::Keyboard
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Target Milestone: --- → B2G C2 (20nov-10dec)
Status: NEW → ASSIGNED
Duplicate of this bug: 810312
Duplicate of this bug: 816096
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.
Attachment #687049 - Flags: review?(21)
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.
Attachment #687049 - Flags: review?(21) → review+
Duplicate of this bug: 816999
https://hg.mozilla.org/mozilla-central/rev/496c379c8d16
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: Gaia::Keyboard → General
Fix verified on 12/3/12 nightly.
Status: RESOLVED → VERIFIED
I opened bug 819593 for the keyboard flickering problem.
Depends on: 819593
You need to log in before you can comment on or make changes to this bug.