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.
Ok, I can see this problem too. The result is depending of which is the first visible row.
*** 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
Kevin has reviewed the change.
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)
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)...
I am looking at it...
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.
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