18685 - Reply to All changes the first 2 names in the To: list to CC's

Status: VERIFIED WORKSFORME

(MailNews Core :: Composition, defect, P3)

Description

[esther]

Using builds 1999111117 on win98 and linux build 1999111111 on mac when you
click Reply to all on a message that has more than 3 names addressed as To: the
first 2 names become CC during the Reply to All process.

1. Launch Messenger
2. Send a message to 4 people (including yourself) and use the addressing format
of To: for all of these people.  (name1, name2, name3, yourself)
3. Get that message and click the toolbar button Reply All, add something to the
 body of the message and Send (at this time don't scroll the addressing pane,
names could disappear because of another bug).
4. Get that Re: message and view it.

Result: the name 3 and yourself are listed first with To: as the addressing
format while name 1 and name 2 are listed below with CC: as the addressing
format.

Expected:  All the names should be listed in the same order as the orignial
message and addressed with To: for the addressing format.

Comment 1

[Jean-Francois Ducarroz]

The problem is due by the select element wich doesn't hold the value (cc) set throught JS when it's off the tree view
box. Therefore when I get back the value before sending, I get the first value (to). It's a similar problem than bug
16709.

As for Input field, select element store (I presume) the value in the frame and not in DOM. It's a dup of 16709


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

Comment 2

[esther]

Using win98 build 1999111909m12 and build 1999112108m12 on linux and mac this is
fixed.

Comment 3

[esther]

Using builds 1999121309 on win98, and build 19991211308m12 mac and linux, this
is not fixed and is again broken on all three platforms.

Comment 4

[Jean-Francois Ducarroz]

Therefore, reopen this bug

Comment 5

[Jean-Francois Ducarroz]

ok, the fix for the edit field (bug 16709) didn't fix the problem with combobox which is bug 21945.


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

Comment 6

[esther]

This scenario is different from duplicate bug and should be tested too.
1.) Scrolling in the addressing pane is not necessary in this scenario to see
the names lose order.
2.) The result of the addressing field of  Reply to All is different from what
actually shows up when clicking Reply to All during the composing of the message.

This will stay unverified until the duplicate is fixed and this scenario is
tested to be sure it's a duplicate.

Comment 7

[esther]

Making this bug dependant on duplicate bug

Comment 8

[esther]

re: #2  the order and addressing of the recipients after the message is sent is
different from what is showed during the composition of the Reply to All.

Comment 9

[laurel]

Still the same problem happening in mar15 commercial beta builds.
Reopening this bug, since the symptoms reported in the bug for which this was
marked duplicate is ok. (see bug #21945).

Comment 10

[Jean-Francois Ducarroz]

looks like a dup of bug 32119 which has been marked Beta1

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

Comment 11

[laurel]

QA assigned to me, cc esther.  Since I have the other bug and I know the story
of this one, I'll be QA responsible for it and keep esther in the loop.

Comment 12

[laurel]

Reopening to have Reply All case stand on its own rather than trail as a
duplicate of bug #32119.

Comment 13

[laurel]

setting target milestone to M15 for now.  
This reply all case is being separated from new message case (#32119).

It is not crystal clear what the rules are, but it seems intuitive that a  Reply
All should include all recipients across appropriate header types (not bcc) and
should use those same header types when replying(all). 
When using 4.x communicator to model seamonkey behavior, we find there is a
discrepancy in how the platforms behave in 4.x, using the original scenario as
an example:
    1. In 4.x: Send a new message with four different To: recipients.
    2. In 4.x: Get the message, Reply All and notice the composition window
header list:
            Windows:  one To: and three  cc: headers
            Mac:      same as windows
            Linux:    four To: headers

When doing the same scenario in seamonkey, all platforms will change the four
To: headers to one To: plus three cc: headers.

When trying other multiple recipients over varied header types scenarios in
seamonkey, I see other headers change when Reply All is done:  cc: can change to
To: and in one instance I saw bcc: change to cc:, although I can't reproduce the
bcc case now.

Bottom line:  it seems that we shouldn't be changing header types when doing a
reply all

Comment 14

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 15

[rods (gone)]

I am removing myself from the cc'list because you are now using XBL widgets

Comment 16

[Jean-Francois Ducarroz]

Works for me...

Comment 17

[laurel]

Seems to be ok using dec5 commercial trunk build.
Will reopen new report if seen again, since this one has gotten long and confusing.