102954 - [branch only] CJK LDAP matches fail on unique matches if the 1st keyword entry is erased over

Status: RESOLVED INCOMPLETE

(MailNews Core :: LDAP Integration, defect)

Description

[Katsuhiko Momoi]

** Observed with 20011003 branch pull with dmose's patches in 
Bug 101086 **

This problem was exposed when I tried dmose's patch in Bug 101086.
Since it does not seem to be related to the patches, I am filing
a separate bug. This problem does not occur on the current trunk build
with the same patches and looks like an area mscott touched on recently.

Problem description:

1. Use an internal LDAP intl test server: polyglot
2. Open a mail compose window and type in a single Japanese
   character which has a uique match in the LDAP database,
   e.g. ŽR  (View this report with encoding set to Japanese (Shift_JIS)
   and copy/paste the character into an addressing field.
3. Erase back the character with the Backspace key.
4. Now try step 2 again. This time, you will not see any match
   displayed. You can try other unique matching cases, e.g. ‘ë
   All unqiue match cases fail to display. If you type in a 
   character which has multiple matches, they display.
5. If you hit <CR>, however, the unique match does get committed.
6. If you start auto-completion in another address field line or
   on another mail compose window, it succeeds.

** This problem is not observed with trunk builds.

Comment 1

[Jaime Rodriguez, Jr.]

is this worthy of nsbranch+, or this something that will hit after 095?

Comment 2

[Katsuhiko Momoi]

Now that the fix for Bug 101086 is in the branch,
let's see if this bug can be verified to exist there.
It was visible on my private build with dmose's patches.
Should check it again on the trunk but my earlier finding
was that the problem does not occur there.

I'm hoping that ji can check this out. 

Comment 3

[ji]

With 10/08 branch build, I can't reproduce this problem.
I tried the two examples that Kat has mentioned in the report, the unique match
does come up in To: field even after I erased over and retyped again.

Comment 4

[Katsuhiko Momoi]

ji, thank you. I was wondering if the result I 
saw had to do with the fact that my test was done 
on a debug build.
I'll re-check it later today with a published build
and if it does not occur there, I will be happy
to close this bug. 

Comment 5

[ji]

It seems this problem exists when matching with PAB is not checked on and only
ldap server is used for auto-complete. But it's a generic problem and is
reproducible with ascii data.   

Comment 6

[ji]

And I can see this problem on 10/05 trunk build when matching with PAB is not
checked.

Comment 7

[ji]

Did little more testing, this bug behaves differently with CJK data and ascii
data when matching with PAB is unchecked.
With ascii data, if you erase the match completely and retype from the very
beginning, the unique match does come up. But if you don't erase the match
completely, like leaving the firstname (must longer than 2 letters) in the
field, the match doesn't come up.

With CJK data, if you erase the match completely and retype from the very
beginning, the unique match doesn't come up, and it is the problem that this bug
reported. And this problem doesn't exist when both matching with PAB and ldap
server are checked.

Comment 8

[Jaime Rodriguez, Jr.]

this is not for 094, right?

Comment 9

[Katsuhiko Momoi]

If all agree that the 2 workarounds I suggested above can alleviate
the problem and are easily discoverable, then this probably is not
a stop-ship bug. I would like to hear others' opinions on this.

Comment 10

[Katsuhiko Momoi]

> With CJK data, if you erase the match completely and retype from the very
> beginning, the unique match doesn't come up, and it is the problem that this bug
> reported. 

> And this problem doesn't exist when both matching with PAB and ldap
> server are checked.

I think this is because if you check PAB, there will also be at least an
additional default returned for PAB, i.e. [e-mail]. Thus you
have at minimum 2 matches. 

Comment 11

[Wayne Mery (:wsmwk)]

Rolf, can you reproduce this?

Comment 12

[Rolf Leggewie]

Unfortunately, no, I cannot reproduce this problem, Wayne.  First, I do not have access to an LDAP server. Second, the Japanese characters mentioned in the original report must have been butchered by one of the bugzilla or database upgrades.

Maybe Momoi-san is still around?

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to Rolf Leggewie from comment #12)
> Maybe Momoi-san is still around?

appears not

Comment 14

[Katsuhiko Momoi]

I am still here once in a while. This bug is over 13 years old now. For whatever the merit of the original bug was, I am not sure it is not worth pursuing this at the moment. If this or issue related to this still exists, I am sure that someone will let us know again. So therefore I am going to resolve this as Wontfix.

Comment 15

[Wayne Mery (:wsmwk)]

Thanks for the update. Wontfix has rather special meaning which I think is not appropriate here. Let's stick with incomplete, since we don't have a testcase