1073788 - [Email] The keyboard is shown even after the form is submitted when click on enter

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[sasikala]

1. Title: The keyboard is shown even after the form is submitted when click on enter while creating an account
2. Precondition: wi-fi should be connected
3. Tester's Action: 
Scenario a)1.Open Email application
           2.On New Account page, fill out the 3 text fields(name, email, password). 
           3.Select Manual setup
           4.Enter hostname -> click on OK button in keyboard
           5.Select enter button -> keyboard still shows but form is submitted

Scenario b)1.Open Email application
           2.On New Account page, fill out the 3 text fields(name, email, password). 
           3.Focus cursor in email field
           4.Select enter button -> keyboard still shows but form is submitted
                
4. Actual Symptom (ENG.) : The form is submitted but the keyboard is still shown
5. Expected: The keyboard should not be shown when the form is submitted

Comment 1

[sasikala]

Attachment: Bug_1073788.patch

Hi Andrew and James,
Kindly provide the feedback on this.
Issue: When user click on enter button and if the cursor is in middle field the focus is not cleared.
Fix: In this patch If user click on enter, checking if the form is valid and if the form is valid, submitting the form and calling blur on the current element else focus on the next form element

Comment 2

[James Burke [:jrburke]]

Comment on attachment 8496402 [details] [diff] [review]
Bug_1073788.patch

I will review, clearing asuth from responsibility.

Comment 3

[James Burke [:jrburke]]

Attachment: Gaia pull request

While the suggested patch does deal with the problem, we had a similar concern for a different form that does not use the FormNavigation (the search form in message_list).

Generically, I think the card infrastructure should just make sure to blur the activeElement if it can be blurred before completing the "show next card" logic.

This patch does that, and I favor this approach, as it avoids us from having to be careful to do a blur for each form that may eventually show up in the email app. But asking original patch author for feedback, if this also accomplishes the goals. I tried some on-device testing, and it does seem to address the goals.

Comment 4

[sasikala]

I have tested the patch and is working fine.This approach is good because it will handle other scenarios as well

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8497153 [details] [review]
Gaia pull request

Yeah, this seems like the right course of action (and I think we've discussed something like this previously; there may be a few bugs we can resolve WFM or fixed after this.)

Comment 6

[James Burke [:jrburke]]

Merged from master:
https://github.com/mozilla-b2g/gaia/commit/2c7158d88f8307b09b0db620ffc9337530e6f06a

from pull request:
https://github.com/mozilla-b2g/gaia/pull/24531

Comment 7

[Edward Chen[:edchen]]

[Environment]
Gaia-Rev        83f495a1c12687970f7f2840c2729795c4b88177
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/0ed32d9a42d6
Build-ID        20141005160202
Version         35.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20140925.192608
FW-Date         Thu Sep 25 19:26:18 EDT 2014
Bootloader      L1TC10011800


[Result]
PASS