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
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
Comment on attachment 8496402 [details] [diff] [review] Bug_1073788.patch I will review, clearing asuth from responsibility.
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.
I have tested the patch and is working fine.This approach is good because it will handle other scenarios as well
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
You need to log in before you can comment on or make changes to this bug.