Closed Bug 898976 Opened 7 years ago Closed 7 years ago
[Contacts] Keyboard does not disappear when clicking ENTER key in contacts search page
1. Title : Keyboard does not disappear when clicking ENTER key in contacts search page. 2. Precondition : 3. Tester's Action : Contacts - Search - Keyboard appears - Click ENTER key 4. Detailed Symptom (ENG.) : Keyboard does not disappear. 5. Expected : keyboard should disappear. 6. Reproducibility: Y 1) Frequency Rate : 100% 7. Gaia revision : 7f3d9b6583aa42eb31c6d93d75715e8516475e04
Severity: normal → critical
blocking-b2g: --- → leo+
Priority: -- → P1
Target Milestone: --- → 1.1 QE5
I don't know hat is the behaviour the reporter is expecting in this bug. The current patch proposes that when the enter key is pressed the Contacts app returns to the Contacts List page and exists search mode. I'm not sure if this is the expected behaviour or are you expecting that the keyboard disappears but the app remains in search mode? thanks
I think there are three possible behaviors related to the Enter key: • hide the keyboard • hide the keyboard and exit search mode (= current patch) • hide the keyboard, select the first contact matching the search pattern, exit search mode Thinking of it, I agree the current solution is not optimal — in fact I’d be tempted to apply the last one. José, what would *you* suggest?
(In reply to Fabien Cazenave [:kaze] from comment #3) > I think there are three possible behaviors related to the Enter key: > > • hide the keyboard > • hide the keyboard and exit search mode (= current patch) > • hide the keyboard, select the first contact matching the search pattern, > exit search mode > > Thinking of it, I agree the current solution is not optimal — in fact I’d be > tempted to apply the last one. José, what would *you* suggest? I would like to go with the last one also. However given the amount of real estate we don't have with these phones (the user can only see three results on the screen) I am of the opinion that a more useful implementation would be the first option as it would allow the user quicker access to more of the results list. So i would say: 1) user opens contacts app 2) user enters search mode 3) user types characters that return more than one contact result 4) user presses enter **Expected** Keyboard closes and user is kept in search mode with filtered list of contacts in view 5) user taps on search field **Expected** Keyboard opens and user can continue to filter further the list of contacts. -----
Thanks Ayman, working on it.
We applied the current patch (hide the keyboard and exit search mode) and will keep the current patch if problem does not occur.
José, I’ve just updated the patch to match the UX expectation. As a bonus, the word suggestion is now properly disabled. :-)
Comment on attachment 783955 [details] link to pull request works perfectly thanks!
Attachment #783955 - Flags: review?(jmcf) → review+
Merged on master: https://github.com/mozilla-b2g/gaia/commit/434853828ed439de0ecea590ab3b5671f3e9f4be
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I was not able to uplift this bug to v1-train. If this bug has dependencies which are not marked in this bug, please comment on this bug. If this bug depends on patches that aren't approved for v1-train, we need to re-evaluate the approval. Otherwise, if this is just a merge conflict, you might be able to resolve it with: git checkout v1-train git cherry-pick -x -m1 434853828ed439de0ecea590ab3b5671f3e9f4be <RESOLVE MERGE CONFLICTS> git commit
This bug was partially uplifted. Uplifted 434853828ed439de0ecea590ab3b5671f3e9f4be to: v1.2 already had this commit Commit 434853828ed439de0ecea590ab3b5671f3e9f4be didn't uplift to branch v1-train
OMG, I completely missed this one. Do we still want to uplift this to v1-train / v1.1.0hd?
Here’s the patch for v1-train in case somebody still wants to merge it on this branch.
You need to log in before you can comment on or make changes to this bug.