Test case id: #7311 PROCEDURE Type 3 digits (666) that matches with contacts A: 776668999, B:566681232 and C:666812547 Open Dialer app and start typing: 1234 EXPECTED The result count is showed. ACTUAL The result count isn't showed until one digit is deleted.

TO COMPLETE THE PROCEDURE & RESULTS: PROCEDURE: Previously there are 3 contacts: A: 776668999, B:566681232 and C:666812547 1. Open Dialer 2. Type '6668' (matching of the 3 contacts) 3. Delete last digit '8' EXPECTED 2. The matching should show on the result count (3 contacts contain the substring 6668). ACTUAL 2. Nothing 3. After delete, the result count is showed.

This works for me on a build from 1436e2778b so it seems like this may be a recent regression.

I'm trying to reproduce this both on gaia/v1-train (e2ef782119) and gaia/master (d94ed01a27) but I don't get the behavior described in comment 1. What I see is the following: 1. Type '6', '6', '6' -> display shows '666', no contact results 2. Type '8' -> display shows '6668', 3 contact results 3. Delete '8' -> display shows '666', still 3 contact results Now, if I wipe and start over once I've type '666' I'll get immediately the 3 contact results which I didn't before (I needed to type '6668' to get them). Could you try again and see if this is the intended behavior and if you're still seeing the problem?

paloma : Leo- this for now given comment #2, please renom if you are able to reproduce on 1.1

I have reproduced this bug on Gecko-b705197.Gaia-c60e350. I see the same results that the comment #3, but I think it's a bug because if you type '6' '6' '6', it should be showed 3 contact reults. Ayman, can you help us with this issue? Thank you.

hi If we have the following 3 numbers: A: 776668999, B: 566681232 C: 666812547 ...its not clear to me why typing 6668 would pick up all three. I would have expected typing 6668 to only pick up 666812547 as this is the only number stating with '6668' Can you explain why it should pick up 776668999 and 566681232 also please? ...i am noticing this also has implications for the passive and active merging of contacts as it is picking up 'duplicates' where i would not have expected it to... e.i. contact 1) with number 666812547 is considered a duplicate of contact 2) with number 776668999 which i would not have expected. ni? to paloma to explain expected logic behind current search implementation so we can move forward from there.

Hi, Dial number suggestion funcionality was defined in the US see bug 838017. Our tests are based on this information, please correct us if something has changed. 1) According to Acceptance Criteria attached there: https://bug838017.bugzilla.mozilla.org/attachment.cgi?id=724367, it will display all contacts which contain the numbers tapped (e.g.6869 matches 686974951 and 666686986). 2) When 3 numbers are tapped, the matches must be shown without requiring to enter fourth digit. This requirement is specified on what we thought was the latest wireframe https://bug838017.bugzilla.mozilla.org/attachment.cgi?id=733894, also atached there.

Let's try to find a regressing bug. This wouldn't be a blocker though.

(In reply to b.paloma from comment #7) > Hi, > > Dial number suggestion funcionality was defined in the US see bug 838017. > Our tests are based on this information, please correct us if something has > changed. > > 1) According to Acceptance Criteria attached there: > https://bug838017.bugzilla.mozilla.org/attachment.cgi?id=724367, it will > display all contacts which contain the numbers tapped (e.g.6869 matches > 686974951 and 666686986). > > 2) When 3 numbers are tapped, the matches must be shown without requiring to > enter fourth digit. This requirement is specified on what we thought was the > latest wireframe > https://bug838017.bugzilla.mozilla.org/attachment.cgi?id=733894, also > atached there. Ah, I see. I can understand that this was probably implemented in order to allow a search to be successfully performed irrespective of the presence or non presence of country dial code either in the results or in the search criteria. Its a great first attempt, but the problem is that the current approach 'pollutes' the results by returning numbers that are irrelevant to what the user is actually looking for. We could do with evolving the current number search algorithm to make it tighter and more robust in the results it returns. its a bit of an IA job, am happy to look into it, but will need time ringfencing for it (In reply to Alex Keybl [:akeybl] from comment #8) > Let's try to find a regressing bug. This wouldn't be a blocker though. No i don't think this should block unless it has impact on the performance / integrity of our find and merge duplicate contact functionality... (i.e. it results in the merging of non duplicate contacts) if it does i would advise to block as it would result in the unrecoverable (as there is no undo functionality upon merging) corruption of the users contact list. I am going to NeedInfo Rafael to test this situation in a merge contacts scenarios.

here is another bug for a dial number suggestion functionality, bug 899916, not sure if it's a dup or not

in regards to regression range, it doesn't look like it's a recent regression, was able to reproduce the issue on older builds back to 5/28, it does not reproduce on 5/22 build, I will be continuing working to narrow down the regression range

In response to Comment 11: Regression range Following STR from Comment 3, can’t repro behavior for 5/24 COM build. Build ID: 20130524070209 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c4378ff5d057 Gaia: cc2fd02fd461aa12c96e02229a78293365d65264 Platform Version: 18.0 RIL Version: 01.01.00.019.105 Following STR from Comment 3, can repro behavior for 5/24 COM build Build ID: 20130524230207 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c4378ff5d057 Gaia: 4d10e1297b859cacc174c0a54af61a7678d7c32d Platform Version: 18.0 RIL Version: 01.01.00.019.105 Example: 1. Type '6', '6', '6' -> display shows '666', no contact results 2. Type '8' -> display shows '6668', 3 contact results 3. Delete '8' -> display shows '666', still 3 contact results 4. If user starts over typing '666' 3 contact results appear which didn't before (needed to type '6668' to get them). Restarting the device and following above example in Comment 12 doesn’t engage at step 4, rather begins at step 1 again showing no contact results for the numeric combination of 666.

I think if there is a new version wireframes this is a new bug, but not regression bug. I'll review this case in merge contacts scenarios, but is independent of this bug.

add to backlog 891754

I just tried to repro this and was unable to.