41686 - Changes made in recipient fields are lost

Status: VERIFIED DUPLICATE of bug 41143

(MailNews Core :: Composition, defect, P1)

Description

[Akkana Peck]

Reply-all to a message, to get a compose window with several recipient lines.
Delete all but one of them: sweep out the text in the line, and hit delete.
Everything looks fine, there's only one recipient showing.  Now send the message
-- and find out that it really went to all the original recipients.

This is really scary for a lot of people, since you can end up sending mail to
people you didn't think you were sending to.

Comment 1

[Akkana Peck]

This ought to be nsbeta2 for sure, if not dogfood.

Comment 2

[lchiang]

Would this be possibly related (same bug cause) to any of the following 
addresses type bugs?

http://bugzilla.mozilla.org/show_bug.cgi?id=32123
http://bugzilla.mozilla.org/show_bug.cgi?id=41143

cc: putterman since ducarroz is out.

Comment 3

[scottputterman]

I don't know if these are related.  Marking M17.

Comment 4

[Jean-Francois Ducarroz]

Accepting

Comment 5

[Phil Peterson]

[dogfood+][nsbeta2+] Need to trust the recipient list

Comment 6

[scottputterman]

reassigning to sspitzer.  thanks Seth.

Comment 7

[(not reading, please use [e-mail] instead)]

accepting.  my spider senses tell me that lisa is right about it being related
to #41143.

I'll investigate first thing tomorrow.

accepting since ducarroz is still on vacation until monday.

Comment 8

[(not reading, please use [e-mail] instead)]

I'm going to start investigating now.

Comment 9

[(not reading, please use [e-mail] instead)]

this bug smells like #41143

after we create the input elements, we later ask for each one by calling 
getElementById.

we seem to get the input elements in there original state (with the original 
.value) even though we are making changes to the value.

mscott suggested I look into the XBL brutual sharing checkins, and see what 
happens when I back them out. 

Comment 10

[Brendan Eich [:brendan]]

Before you back out painfully large numbers of files, try the patch in 
http://bugzilla.mozilla.org/show_bug.cgi?id=41126 -- it's to one file, jsapi.c. 
If it fixes these bugs, dup them against 41126 and I'll notice.

/be

Comment 11

[(not reading, please use [e-mail] instead)]

there is some serious disconnect between the inputelement and what you see on 
the addressing textfield.

if I set the value (inputElement.value = "cheese") that will not show up the the 
addressing textfield.

Comment 12

[(not reading, please use [e-mail] instead)]

be: testing your patch now.

Comment 13

[(not reading, please use [e-mail] instead)]

the js patch doesn't fix the problem.

Comment 14

[(not reading, please use [e-mail] instead)]

updating status whiteboard.

Comment 15

[(not reading, please use [e-mail] instead)]

workaround checked in for #41143.

this is fixed (on the tip, not the m16 branch.)

this bug is really a duplicate.

*** This bug has been marked as a duplicate of 41143 ***

Comment 16

[Asa Dotzler [:asa]]

this wasn't fixed in teh m16 branch?  is it fixed in teh branch by the fixes for
41143?

Comment 17

[laurel]

this is OK using:
2000-06-13-08 m17 commercial build linux rh6.0
2000-06-13-20 m17 commercial build NT 4.0

I think there is still a problem using jun14 m17 mac build... will investigate
further.

Comment 18

[laurel]

later jun14 m17 build for linux had problem like the Mac where you couldn't even
get to the address lines if more than 4... so I'm going to wait to re-verify
this scenario until bug #42674 is fixed.

Comment 19

[laurel]

Looks OK using 2000-06-20-08 m17 commercial build. All platforms