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

Status: RESOLVED FIXED

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

Description

[Leo]

Attachment: 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

Comment 1

[Fabien Cazenave [:kaze]]

Attachment: link to pull request

https://github.com/mozilla-b2g/gaia/pull/11275

Comment 2

[Jose Manuel Cantera]

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

Comment 3

[Fabien Cazenave [:kaze]]

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?

Comment 4

[ayman maat :maat]

(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.

-----

Comment 5

[Fabien Cazenave [:kaze]]

Thanks Ayman, working on it.

Comment 6

[Leo]

We applied the current patch (hide the keyboard and exit search mode) and
will keep the current patch if problem does not occur.

Comment 7

[Fabien Cazenave [:kaze]]

José, I’ve just updated the patch to match the UX expectation. As a bonus, the word suggestion is now properly disabled. :-)

Comment 8

[Jose Manuel Cantera]

Comment on attachment 783955 [details]
link to pull request

works perfectly

thanks!

Comment 9

[Fabien Cazenave [:kaze]]

Merged on master:
https://github.com/mozilla-b2g/gaia/commit/434853828ed439de0ecea590ab3b5671f3e9f4be

Comment 10

[John Ford [:jhford] CET/CEST Berlin Time]

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

Comment 11

[John Ford [:jhford] CET/CEST Berlin Time]

This bug was partially uplifted.

Uplifted 434853828ed439de0ecea590ab3b5671f3e9f4be to:
v1.2 already had this commit

Commit 434853828ed439de0ecea590ab3b5671f3e9f4be didn't uplift to branch v1-train

Comment 12

[Fabien Cazenave [:kaze]]

OMG, I completely missed this one. Do we still want to uplift this to v1-train / v1.1.0hd?

Comment 13

[Fabien Cazenave [:kaze]]

Attachment: patch for v1-train

Here’s the patch for v1-train in case somebody still wants to merge it on this branch.

Comment 14

[John Ford [:jhford] CET/CEST Berlin Time]

v1-train: 6ff3a607f873320d00cb036fa76117f6fadd010f

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

v1.1.0hd: 6ff3a607f873320d00cb036fa76117f6fadd010f