284222 - Address autocompletion broken for the third recipient when BCC to myself

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Olivier Vit (just a reporter)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050228

My account is is configured to BCC every sent message to myself

When creating a new message,
first recipient is myself
second recipient : address completion is working fine
third recipient and above : address completion will not work

Reproducible: Always

Steps to Reproduce:
1. configure with BCC in Copies & Folder preferences
2. create a new message
3. set a first recipient TO
4. start typing an existing recipient name or address for the third recipient
entry (TO) 
Actual Results:  
address completion will not work, no error in Javascript Console


Expected Results:  
To behave the same as the first manual entry

was also broken in a previous nightly build 10-15 days ago

Comment 1

[Mike Cowperthwaite]

Reproduced with TB 1.0+0222, Win2K; moving to Core.
Problem does not appear in TB 1.0, nor in 1.8b-0120.

Comment 2

[Mike Cowperthwaite]

Restoring the dependency I accidentally erased.

Comment 3

[Mike Cowperthwaite]

Verified fixed with TB 1.0+0302, Win2K.

Comment 4

[Wolfgang Preuss]

I remarked this problem too, the first time somewhere between
1.8b2_2005022005 and 1.8b2_2005022504
Today I'm using 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050301
Some experiences from my side:

- Regular problems when replying to existing mails.
  After the last recipient address no auto-completion at all.
  Auto-completion is only possible when I overtype a recipient
  in the existing address list (prepared by reply all).

- Normally no problem with new mails ("compose").
  Only when I go back in the recipient list of a new mail and try to
  overtype a before inserted recipient then I get sometimes address-
  constructions like
  wp >> Wolfgang PREUSS <[e-mail]>
  (wp is a nickname)
  Until now I was not able to find a reproduceable way for this 
  particular problem. 

(When sending this information the first time I got a "mid-air conflict",
 I will test tomorrow with the fixed version ....)

Comment 5

[Olivier Vit (just a reporter)]

can't test for the moment
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-win32-installer.exe
is from feb 28th only

noticed, as in 282645, that it fails for 3rd and 4th recipient, and works again
for the 5°

also, the cursor tends to disappear

Comment 6

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME

Comment 7

[Olivier Vit (just a reporter)]

(In reply to comment #6)
> No specific bug / patch referenced as the fix.
> 
> -> WORKSFORME

I don't get your statement
can't be tested on the reported platform & mozilla application suite : reopening

Comment 8

[Mike Cowperthwaite]

Olivier: when I confirmed this bug, I stated that I'd reproduced it under TB and 
so moved to be a Core bug.  That means: fixed in one implies fixed in the other.
It should not be necessary to re-verify on every single platform.

But, SINCE YOU INSIST, I'll leave this open until you've satisfied yourself that 
it's working.  I see Windows and Linux builds available dated March 3rd at
  http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/
So check it -- and mark it Fixed, again, once you've verified it.

Jason, the bug that was patched that resolved this was the dependency:
bug 282645.  Sorry I didn't specify that explicitly.

Comment 9

[Jason Bassford]

Actually, I'm the one who should apologize for the confusion, and resulting
spam, here.  Although you hadn't explicitly stated that it was fixed by bug
282645 when you closed it, I should have spent more time reading through
everything and figured out the implication.

I'll mark this fixed again (by bug 282645).

Olivier: Please download the latest build of Mozilla (from the 3rd) as
suggested.  Only reopen if you can reproduce under that build.  (Resolution
doesn't need to wait on testing from publicly available builds, only the
verification status.)

Comment 10

[Olivier Vit (just a reporter)]

verified in 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050306
Thanks