Closed Bug 1073788 Opened 6 years ago Closed 6 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
2.1 S6 (10oct)

People

(Reporter: sasikala.paruchuri8, Assigned: jrburke)

References

Details

(Whiteboard: [LibGLA,TD100757,QE2, B])

Attachments

(2 files)

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
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
Attachment #8496402 - Flags: feedback?(jrburke)
Attachment #8496402 - Flags: feedback?(bugmail)
Whiteboard: [LibGLA,TD100757,QE2, B]
Comment on attachment 8496402 [details] [diff] [review]
Bug_1073788.patch

I will review, clearing asuth from responsibility.
Attachment #8496402 - Flags: feedback?(bugmail)
Attached file 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.
Flags: needinfo?(sasikala.paruchuri8)
Attachment #8496402 - Flags: feedback?(jrburke)
I have tested the patch and is working fine.This approach is good because it will handle other scenarios as well
Flags: needinfo?(sasikala.paruchuri8)
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.)
Attachment #8497153 - Flags: review+
Merged from master:
https://github.com/mozilla-b2g/gaia/commit/2c7158d88f8307b09b0db620ffc9337530e6f06a

from pull request:
https://github.com/mozilla-b2g/gaia/pull/24531
Assignee: nobody → jrburke
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S6 (10oct)
[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
Status: RESOLVED → VERIFIED
Duplicate of this bug: 1094489
You need to log in before you can comment on or make changes to this bug.