Closed Bug 898976 Opened 7 years ago Closed 7 years ago

[Contacts] Keyboard does not disappear when clicking ENTER key in contacts search page.

Categories

(Firefox OS Graveyard :: Gaia::Contacts, defect, P1, critical)

x86
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g-v1.1hd fixed, b2g-v1.2 fixed)

RESOLVED FIXED
1.1 QE5
blocking-b2g leo+
Tracking Status
b2g18 --- fixed
b2g-v1.1hd --- fixed
b2g-v1.2 --- fixed

People

(Reporter: leo.bugzilla.gaia, Assigned: kaze)

Details

(Whiteboard: [TD-69750])

Attachments

(3 files)

Attached video screen shot
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
Whiteboard: [TD-69750]
Target Milestone: --- → 1.1 QE5
Assignee: nobody → kaze
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?
Flags: needinfo?(leo.bugzilla.gaia)
Flags: needinfo?(aymanmaat)
(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.

-----
Flags: needinfo?(aymanmaat)
Thanks Ayman, working on it.
Flags: needinfo?(leo.bugzilla.gaia)
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
Flags: needinfo?(kaze)
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?
Flags: needinfo?(kaze)
Attached file patch for v1-train
Here’s the patch for v1-train in case somebody still wants to merge it on this branch.
v1-train: 6ff3a607f873320d00cb036fa76117f6fadd010f
v1.1.0hd: 6ff3a607f873320d00cb036fa76117f6fadd010f
You need to log in before you can comment on or make changes to this bug.