** 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.
is this worthy of nsbranch+, or this something that will hit after 095?
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.
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.
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.
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.
And I can see this problem on 10/05 trunk build when matching with PAB is not checked.
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.
this is not for 094, right?
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.
> 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.
Assignee: mscott → nobody
QA Contact: grylchan → ldap-integration
Product: Core → MailNews Core
Rolf, can you reproduce this?
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)
(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
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.
Resolution: INCOMPLETE → WONTFIX
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.