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.

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?

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.

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

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