Closed
Bug 874710
Opened 12 years ago
Closed 11 years ago
[B2G] [Inari] [Contacts] Searching last name and first name does not bring up any contacts
Categories
(Firefox OS Graveyard :: Gaia::Contacts, defect)
Tracking
(tracking-b2g:backlog)
RESOLVED
DUPLICATE
of bug 1088706
tracking-b2g | backlog |
People
(Reporter: dsubramanian, Unassigned)
References
Details
(Whiteboard: inarirun2 [u=commsapps-user c=contacts p=0])
Attachments
(2 files)
Description:
When user searches for contacts using last name followed by first name, there is no contacts listed.
Prerequisite: Have as many contacts as possible in the Contacts App. In this case, I had more than 900.
Repro Steps:
1) Updated to Inari Build ID: 20130515070208
2) Go to the Contacts App
3) Tap on the search field
4) Type in last name("Erickson") followed by first name("Aaron")
Actual: User sees "No Contacts Found"
Expected: User sees the contact list on the search list (Erickson Aaron)
Environmental Variables:
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/d06cfe7d67c2
Gaia: 0ddb515f15cbc6b74fc2742b7599d6ae74c6413f
Notes:
Repro frequency: 100%
Q Analysts Test Team Priority: Pri 3
See attached screenshots for more info.
Fails test case: https://moztrap.mozilla.org/runtests/run/1301/env/315/?pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=5624
UCID: OWD-3999
Other: User is able to search contacts using first name > last name, but not last name > first name
![]() |
Reporter | |
Comment 1•12 years ago
|
||
![]() |
Reporter | |
Comment 2•12 years ago
|
||
Comment 3•12 years ago
|
||
The way the search works is based on what the user sees on the screen, with the specific order.
That means, if the user is called:
Aaron Erickson
We will find this by:
- aaron
- erickson
- aaron erickson
or any substring of the string 'Aaron Erickson', so 'Erikson Aaron' is not a substring, that's why we are not able to find that.
IMHO, this works for me.
Thanks!
Comment 4•12 years ago
|
||
(In reply to Francisco Jordano [:arcturus] from comment #3)
> IMHO, this works for me.
Notice 900 contacts mentioned by the reporter. It is IMHO most likely a duplicate of bug 864906 (or other way around)
Comment 5•12 years ago
|
||
hmm, except here the search actually finishes. In the other bug, it doesn't.
![]() |
Reporter | |
Comment 6•12 years ago
|
||
> The way the search works is based on what the user sees on the screen, with
> the specific order.
The User is able to search contacts using "First name" (Aaron) followed by "Last name" (Erickson), but not using "Last name" (Erickson) followed by "First name" (Aaron)
Comment 7•12 years ago
|
||
Yes, sorry, this is really distinct from bug 864906 ... in the current master, search on large number of contacts works as expected, but this issue can be still reproduced (whether it is a bug, and I would think it is, or whether it is intended, is a different story).
![]() |
||
Comment 8•12 years ago
|
||
What's the requirement for this functionality? How is search supposed to work? Is it possible to search by lastname only, lastname + firstname?
If it SHOULD be possible we should + this bug.
Flags: needinfo?(pdolanjski)
Comment 9•12 years ago
|
||
Again just to be clear,
for searching we are not using the contacts api, we are doing this search based on the search entered, regular expressions and the way we display each contact.
So we will need users to search as they see (saying in other words, as we display) the contacts in the list.
Thanks folks,
F.
![]() |
||
Comment 10•12 years ago
|
||
Flagging the UX team for opinion on this and adding Wilfred to add to the backlog.
I can see the last name + first name search being more common in certain geographies. It is not critical for the current releases, but could be a value add in the future.
blocking-b2g: --- → -
Flags: needinfo?(pdolanjski) → needinfo?(wmathanaraj)
![]() |
||
Updated•12 years ago
|
blocking-b2g: - → koi?
Comment 12•12 years ago
|
||
FTR this works in the Sms app where we use the mozContacts API. We made a small library on top of it ([1]) and it might make sense to move all this to the API instead (see Bug 852577).
We need to think of all use cases thoroughly too (eg: multi-words names).
[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/contacts.js
Comment 13•12 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #12)
> FTR this works in the Sms app where we use the mozContacts API. We made a
> small library on top of it ([1]) and it might make sense to move all this to
> the API instead (see Bug 852577).
>
> We need to think of all use cases thoroughly too (eg: multi-words names).
>
> [1] https://github.com/mozilla-b2g/gaia/blob/master/apps/sms/js/contacts.js
Great point, when the search was implemented we didn't have the cursor API, perhaps now with that API the search is fast enough to bring the results.
Thanks,
F.
Comment 14•12 years ago
|
||
We don't use the cursor API in Sms, but we try to keep the amount of result as small as possible. In SMS we don't need to show more than 3 results, I'm sure the Contacts app has different requirements, but maybe you could still have a limit ?
Comment 15•12 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #14)
> We don't use the cursor API in Sms, but we try to keep the amount of result
> as small as possible. In SMS we don't need to show more than 3 results, I'm
> sure the Contacts app has different requirements, but maybe you could still
> have a limit ?
I guess product people won't like a limit in the search, but definitely let's explore solutions for this.
:)
Thanks Julien!
![]() |
||
Updated•12 years ago
|
Blocks: comms_backlog
blocking-b2g: koi? → ---
Whiteboard: inarirun2 → inarirun2 [u=commsapps-user c=contacts p=0]
![]() |
||
Updated•11 years ago
|
blocking-b2g: --- → backlog
Assignee | ||
Updated•11 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Comment 16•11 years ago
|
||
Has been implemented in bug 1088706. This now causes bug 1135905.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•