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

RESOLVED INCOMPLETE

Status

RESOLVED INCOMPLETE
17 years ago
5 years ago

People

(Reporter: momoi, Unassigned)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
** 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

17 years ago
is this worthy of nsbranch+, or this something that will hit after 095?
(Reporter)

Comment 2

17 years ago
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

17 years ago
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.
(Reporter)

Comment 4

17 years ago
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

17 years ago
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

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

Comment 7

17 years ago
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

17 years ago
this is not for 094, right?
(Reporter)

Comment 9

17 years ago
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.
(Reporter)

Comment 10

17 years ago
> 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. X@defaultdomain.com. Thus you
have at minimum 2 matches. 

Updated

16 years ago
QA Contact: yulian → gchan
Product: MailNews → Core

Updated

10 years ago
Assignee: mscott → nobody
QA Contact: grylchan → ldap-integration
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core

Comment 11

6 years ago
Rolf, can you reproduce this?
Flags: needinfo?(bugzilla.mozilla.org)

Comment 12

6 years ago
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?
Flags: needinfo?(bugzilla.mozilla.org) → needinfo?(momoi)

Comment 13

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

appears not
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 14

5 years ago
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.
Flags: needinfo?(momoi)
Resolution: INCOMPLETE → WONTFIX

Comment 15

5 years ago
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
Resolution: WONTFIX → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.