Closed Bug 32119 Opened 24 years ago Closed 24 years ago

Address headers change on send: bcc-->To:, newsgroup-->To:

Categories

(MailNews Core :: Composition, defect, P3)

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: laurel, Assigned: bugzilla)

Details

(Whiteboard: [PDT+])

Using mar15 beta commercial builds

When you send a new message having multiple addressees in different header
types, the address headers will often change types on send.  The most irritating
changes which I've seen are:
    1.  bcc: headers are changed to To: 
        Result: you lose the privacy of having blind copied a user
    2.  newsgroup: headers are changed to To:
        Result: the news message is not posted to the newsgroup as you thought.

Steps to reproduce (many combinations to test, this is a simple scenario):
1.  Launch, open mail window to profile having mail and news accounts, login to
mail account.
2.  Set preferences so that a copy of sent message will be filed to a sent
folder.
3.  Click new message.
    Adddress the message using To: Cc: Bcc: and newsgroup: headers.
    Addresss so that you use each header twice, i.e. 2 To: addressees, 2 cc:
addressees, 2 bcc: addressees and 2 newsgroups.
4.  Send the message.
5.  Check the Sent folder for the message.
    Note some of the headers have changed types. In the few times I tried this I
saw bcc: change to To:, newsgroup: change to To: and Cc: change to To:.  Not all
headers will change, but usually at least one will.  I've seen different results
based on different combinations of headers used.

Result:  some headers change to To: headers.  Will expose bcc: addressees and
will cause newsgroup messages not to be posted to newsgroup.

Expected result:  headers should not change from the way they're composed.
Keywords: beta1
QA Contact: lchiang → laurel
cc: phil
Ok, I can see this problem too. The result is depending of which is the first 
visible row.
Status: NEW → ASSIGNED
Target Milestone: M14
PDT+
Whiteboard: [PDT+]
*** Bug 18685 has been marked as a duplicate of this bug. ***
Rods, for some reason the select element doesn't return me the right value. That 
append sometime depending of the current scroll bar position in the tree. I use 
exactely the same methode to access the value of the input field than for the 
select, therefore I don't think is a tree issue. I will try to write a simple 
test case (tonight or tomorrow). Until then, can you already take a look at it? 
Thanks
cc'ing hyatt just in case he has any idea.
Ok, the patch rods give me fix the problem. sofar I haven't found any 
regression. Good job rods.

Rods, can you seek a code review please. I will then check it in for you in the 
branch
Whiteboard: [PDT+] → [PDT+]Fix in hand
Kevin has reviewed the change.
Whiteboard: [PDT+]Fix in hand → [PDT+]Fix in hand, seeking rickg approval
I checked the fix in on the Tip.
I pass successfuly the to 100 site. Still waitig for Rick's approval
IF we can, we would *REALLY* like to see this landed before Sunday night.  That
would get it into the Monday morning verification build (kicked very early
Monday morning). Please call Rick at home to get the checkin approval.  If you
can't get him, please page me (page-jar) and I'll work to find him, or get approval.
Thanks,
Jim
I left a voice mail to Rick at home.
Fixed and checked in the branch (and the tip)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Using:
2000-03-21-06 nb1b commercial build linux rh6.0, NT 4.0, mac OS 9.0


Good: This bug report's case seems to be fixed in the variations I've tried. 
That is, when using New Message with various headers and multiple recipients the
headers which display in the recieved message are as they were when composed.

Bad:  The case of Reply All on such a message as covered under bug #18685
(marked a duplicate of this) is still as described.  Although #18685 was written
with a simple case where To: headers are changed to Cc:, I'm seeing in some
cases that other headers change to CC: in reply all.  One case got a bcc turned
into a cc, have also seen CC: turn into To:.

Reopening based on reply all case (#18685)...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I am looking at it...

Status: REOPENED → ASSIGNED
Whiteboard: [PDT+]Fix in hand, seeking rickg approval → [PDT+]
Laurel, I did several test and I have not find any problem.

When a reply to the following message:
from: myself
to:name1, name2, name3, myself

I get:
to: myself
cc: name 1, name2, name3

which is normal. First, the only recipient addressed as to is the original 
sender (or if a reply-to header is provided, we use it instead). The the others 
recipients are addressed in cc. Also, we remove any duplicate and we remove 
ourself from the cc list.
Laurel, do you have a specific case where Mozilla doesn't behave like 4.x?
OK, I talked to ducarroz over the phone and we've decided to close this bug (New
Message case 32119) as verified.  We've decided to reopen bug #18685 (Reply All
case) and mark it M15 or so.

Brief explanation:  Although it seems intuitive that a Reply All should not
change header types, 4.x Windows and Mac does so, Linux doesn't.  So based on
the 4.x model we have conflicting base information.  I'm not able to reproduce
(haven't tried extensively) the negative corner case where a bcc: would change
to cc: and so we feel we should move off the PDT + radar.  More discussion in
bug #18685. 

Closing this bug #32119 as verified using 03-21-2000nb1b commercial builds, all
platforms.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → FIXED
.
Status: RESOLVED → VERIFIED
The changes for this bug caused a mailnews regression in the account manager
today because nsHTMLSelectElement.cpp. If a select element has no value, it's
now throwing an error instead of returning NS_OK.

JS callers are now seeing exceptions in the JS!!!

We may need to back this change out or fix it to not return an error.
Jean-Francois, what are the potential implications of backing out rod's fix here?
If you back up rods' change, select element that aren't visible will return a 
wrong value! Sure, you want get an error but I don't think so is better.
The goal would not be to back out the change, but rather to make sure the change
maintains existing semantics (at least on beta 1 branch) and returns what it
used to).  It seemed likely that the semantic change was an incidental
"improvement" that was landed during the significant fix.
IFF this change was a critical element of Rods fix, i.e., IF the semantic change
was crucial to his fix, then it should stay.
If it is not crucial, then it should be backed out on beta.  We would never have
approved a change of semantics this late without a tremendous reason.  I believe
his "real" fix had to do with the order he searched for buttons, and this
semantic was a "free extra improvement" that slid by the reviewers (but would
not have been PDT+, or approved otherwise).

After we are back on the trunk, semantic changes could be considered, but then
we'd have to be careful to note and adjust any/all consumers of the potential
exception.
Checked this problem with mar22 builds, looks OK.
Used:
2000-03-22-06nb1b commercial build NT 4.0
2000-03-22-06nb1b commercial build linux rh6.0
2000-03-22-06nb1b commercial build mac OS 9.0
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.