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



MailNews Core
18 years ago
9 years ago


(Reporter: laurel, Assigned: Jean-Francois Ducarroz)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: [PDT+])



18 years ago
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
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.


18 years ago
Keywords: beta1
QA Contact: lchiang → laurel

Comment 1

18 years ago
cc: phil

Comment 2

18 years ago
Ok, I can see this problem too. The result is depending of which is the first 
visible row.
Target Milestone: M14

Comment 3

18 years ago
Whiteboard: [PDT+]

Comment 4

18 years ago
*** Bug 18685 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
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? 

Comment 6

18 years ago
cc'ing hyatt just in case he has any idea.

Comment 7

18 years ago
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 
Whiteboard: [PDT+] → [PDT+]Fix in hand

Comment 8

18 years ago
Kevin has reviewed the change.


18 years ago
Whiteboard: [PDT+]Fix in hand → [PDT+]Fix in hand, seeking rickg approval

Comment 9

18 years ago
I checked the fix in on the Tip.

Comment 10

18 years ago
I pass successfuly the to 100 site. Still waitig for Rick's approval

Comment 11

18 years ago
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.

Comment 12

18 years ago
I left a voice mail to Rick at home.

Comment 13

18 years ago
Fixed and checked in the branch (and the tip)
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 14

18 years ago
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)...
Resolution: FIXED → ---

Comment 15

18 years ago
I am looking at it...

Whiteboard: [PDT+]Fix in hand, seeking rickg approval → [PDT+]

Comment 16

18 years ago
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.

Comment 17

18 years ago
Laurel, do you have a specific case where Mozilla doesn't behave like 4.x?

Comment 18

18 years ago
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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 19

18 years ago

Comment 20

18 years ago
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?

Comment 21

18 years ago
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.

Comment 22

18 years ago
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

Comment 23

18 years ago
Checked this problem with mar22 builds, looks OK.
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.