Closed Bug 134729 Opened 22 years ago Closed 22 years ago

Manipulating recipient fields, you delete them and add new recipient, can't send

Categories

(MailNews Core :: Composition, defect, P1)

All
Windows 2000

Tracking

(Not tracked)

VERIFIED FIXED
mozilla1.0

People

(Reporter: esther, Assigned: bugzilla)

References

Details

(Whiteboard: [ADT1])

Attachments

(1 file, 2 obsolete files)

Using build 20020401 on win (haven't tried other platforms yet) if you have
either Reply To or BCC set up where it autopopulates the Addressing field, if
you remove both of them and try to send you get an error that you have no
recipients.

1. Launch Mail (set up yourself as a bcc and/or set up a Reply To email address)
2. Click New Msg
3. Backspace each of those autopopulated names and put in recipient as To.
4. Add subject and content and Senc

Result: Fail to send no receipents
Expected:  You should be able to send.  

Regression this worked with Friday's build.
Note: after you backspace and add a recipient you can't get to another recipient
line.
-->varada. Seems to be a major regression...
Assignee: ducarroz → varada
nominating 
Keywords: nsbeta1
ccing lchiang, she ran into this and  reported it to me.  
I am using 2002040103 and am not able to reproduce this problem. I am able to
both add more recipient rows as well as send the message - is there any other
step that I am missing?
Varada - are you at work?  I can show you.  

ADT: this is a regression.  This stopped working between 3-26 and 4-1 build.  I
use this daily in my work.
Varada, I can reproduce it with the later 4-1 build.  Here is some additional
information.
When the Compose window comes up, you will see the Reply To: filled in and/or
the BCC: filled in and a To: field thats blank. Remove the contents of the Reply
To and the BCC allowing the To: field to move up to the top.  Type in an address
then try to move to the next line in the addressing pane, you can't or finish
the message and try to send, it fails.
Discussed in Mail News bug meeting.  Decided to ADT1 and plus this bug.
Keywords: nsbeta1nsbeta1+
Whiteboard: [ADT1]
Target Milestone: --- → mozilla1.0
Priority: -- → P1
I think I see this bug (on Win2k build 2002040803, and earlier) on fields
besides BCC and Reply-To.

If I select "reply all" to a message I previously sent (to two "To" recipients),
I start composing a message with my email address as To, and the original
recipients as CC.

At this point, if I select "Address", I see all three addresses in the "Address
Message To" portion of the "Select Addresses" window.

If I cancel that, and completely remove my To address (leaving the two CC), they
still exist in the composition window, but the "Address" window is now empty.

On a new Reply All: instead of completely removing the To field, I just blank
the recipient (so that there's still a To line with a blank field), then
"Address" still shows the CC addresses.  If I cancel that window, going back to
composition and finish removing the To line, "Address" is empty again.

On a new Reply All: instead of editing the To field in composition, I remove it
via the "Address" window, then things appear to work.  "Select Addresses" shows
two CC recipients, and when I OK that window, composition also shows two CC
lines, plus a new To line beneath them.  I can then change the CC folks into To
fields and they still remain. (Removing the blank To line anytime during this
process seems harmless.)
Yes, this does happen outside of BCC and Reply-to.
Summary: If BCC or Reply to autopopulate the addressing field, you delete them and add new recipient, can't send → Manipulating recipient fields, you delete them and add new recipient, can't send
*** Bug 136638 has been marked as a duplicate of this bug. ***
I don't know if this is the same bug, but using the 4/9 build, I did reply all
to a message with 4 recipients.  I deleted the 2nd one and then sent the reply.
 It was only sent to the 1st recipient.  I did this to 4 different messages
before I realized only the 1st recipient was getting the mail.  This is pretty bad.
*** Bug 136907 has been marked as a duplicate of this bug. ***
I know what appends (Thank to the DOM Inspector) and I hope I'll have a fix soon...
reassign to myself as I have the fix
Assignee: varada → ducarroz
Whiteboard: [ADT1] → [ADT1] Have fix
accepting
Status: NEW → ASSIGNED
Attached patch Proposed fix, V1 (obsolete) — — Splinter Review
The problem was that when we delete a row, the sequence number of rows wasn't
regenerated in function awDeleteRow because the argumen cols was undefined!

The fix is to remove all those cols argument which we don't need. Instead I add
a function to retreive the number of columns and use it in the function
awDeleteRow as well as in the function awCreateDummyItem. Also, I fixed the
function awTestRowSequence which wasn't working anymore since addressing widget
use a listbox.
This is a better patch than the one I talked to JF about regarding passing from
the XUL because this way we are not dependant on the XUL file to pass the info
to us.
Attached patch Proposed fix, v2 (obsolete) — — Splinter Review
Same than before but with an optimization in function awDeleteRow and removed
cols attribute in abListOverlay.xul when calling awRecipientKeyDown
Attachment #78766 - Attachment is obsolete: true
Comment on attachment 78786 [details] [diff] [review]
Proposed fix, v2

reviewed and tested on Win2K. srilatha will be making sure this doesnt break
the addrbook cards.r=varada
Attachment #78786 - Flags: review+
Attached patch Proposed fix, v3 — — Splinter Review
We need to force gNmberOfCols to 1 if no cols have been defined like it's the
case with the maiing list.
Attachment #78786 - Attachment is obsolete: true
Comment on attachment 78963 [details] [diff] [review]
Proposed fix, v3

r=varada
Attachment #78963 - Flags: review+
1) please change gNmberOfCols to gNumberOfCols.  (no reason to abbreviate)
2) please get shliang@netscape.com to review this as well.  She made the
changes, and might notice issues.

once you get r=shliang, sr=sspitzer


Seth - was there another bug number which caused this regression?  Let us know.
 QA: please also verify that other bug report, if one exists, when this bug is
fixed.
lchiang:  I don't know this for sure, it depends on when it started happening.

But here's some bugs that might be part of it:

bugs 110156, 110155
Removing support for <outliner> tags
Removing <tree> layout code and moving <tree> tags to outliner layout
Convert all usage of <outliner> to tree tags
Convert all usage of <tree> tags to new <tree> syntax or <listbox>

but 45173, AB:Mailing List: Address entry area should look like Mail Compose
Addressing area
what needs to be tested when this lands is the compose window and the mailing
list dialog, so cc nbaca.
bugs 110156, 110155 may be culprits since they were marked fixed around 3-29 and
this bug started happening after 3-29.

bug 45173 was fixed in February so this may not be a regression from it.
bugs 110156 and 110155 are too general to do any targeted verifications on those
bugs.
Is this related to bug 136133 which is seen on Linux too? Note that 
136133 describes also other strange but maybe related behaviour
(adding second reply-to field)
Whiteboard: [ADT1] Have fix → [ADT1] Have fix, need one more review
Note, bug 137549 logged today may be a dup of this.  In that scenario a user can
mistakenly send attachments to the person addressed in the next compose window.
I know this because I did this.  That makes this bug more dangerous. 
Comment on attachment 78963 [details] [diff] [review]
Proposed fix, v3

r=shuehan
I'll change gNmberOfCols to gNumberOfCols before checkin, this is a typo!
Seth, can you put your SR stamp now that I have all the needed review. Thanks
Comment on attachment 78963 [details] [diff] [review]
Proposed fix, v3

sr=sspitzer

thanks for waiting until shuehan got a chance to review.
Attachment #78963 - Flags: superreview+
Whiteboard: [ADT1] Have fix, need one more review → [ADT1] Have fix, need approval
Please check this onto the trunk and when it's been tested, update the bug. 
Adding adt1.0.0 nomination.
Keywords: adt1.0.0
*** Bug 137549 has been marked as a duplicate of this bug. ***
Fix checked in the trunk.
*** Bug 136133 has been marked as a duplicate of this bug. ***
*** Bug 137625 has been marked as a duplicate of this bug. ***
Fixed (trunk only)
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Using trunk builds 2002-04-16-03 win98 and 2002-04-16-09 linux rh6.2:
OK on trunk. 
Tested various scenarios presented in this and its 5 duplicates.
All messages sent OK with the various modifications to recipients.
All messages sent to proper/edited recipients.
Had no problem entering in fields of subsequent new or reply compose windows.

One scenario I noticed, will document separately: if deleting a recipient line
then scrolling the addressee block down and back up to the deleted/empty line,
you can't get focus on the empty line to place other addressee text there until
you focus on a different addressee line and come back.
*** Bug 137813 has been marked as a duplicate of this bug. ***
QA Contact: esther → laurel
The scroll scenario I noticed, which was mentioned in comment #38, has been
logged as new bug 137818.
adt1.0.0+ (on ADT's behalf) for checkin into the branch. Pls check this one in
today. Once this has landed on the 1.0 branch, pls mark as fixed1.0.0.
Keywords: adt1.0.0adt1.0.0+
marking verified -- verified on trunk
Status: RESOLVED → VERIFIED
*** Bug 138032 has been marked as a duplicate of this bug. ***
JF - will you land this in the branch soon?
yes, once I get drivers approval, still waiting...
*** Bug 137962 has been marked as a duplicate of this bug. ***
*** Bug 138171 has been marked as a duplicate of this bug. ***
Comment on attachment 78963 [details] [diff] [review]
Proposed fix, v3

a=rjesup@wgate.com for branch checkin after RC1
Attachment #78963 - Flags: approval+
Fix checked in the branch
Keywords: fixed1.0.0
Whiteboard: [ADT1] Have fix, need approval → [ADT1]
*** Bug 139268 has been marked as a duplicate of this bug. ***
*** Bug 139450 has been marked as a duplicate of this bug. ***
*** Bug 139560 has been marked as a duplicate of this bug. ***
OK on branch.
apr23 commercial branch 1.0.0 builds: win98, mac OS 10.1, linux rh6.2

Tested scenarios in this and duplicates: 137813,137549, 136133, 137625, 139268.
*** Bug 139582 has been marked as a duplicate of this bug. ***
*** Bug 139707 has been marked as a duplicate of this bug. ***
*** Bug 139650 has been marked as a duplicate of this bug. ***
*** Bug 139672 has been marked as a duplicate of this bug. ***
*** Bug 139909 has been marked as a duplicate of this bug. ***
*** Bug 139897 has been marked as a duplicate of this bug. ***
*** Bug 139850 has been marked as a duplicate of this bug. ***
*** Bug 140024 has been marked as a duplicate of this bug. ***
*** Bug 140208 has been marked as a duplicate of this bug. ***
*** Bug 140571 has been marked as a duplicate of this bug. ***
*** Bug 140991 has been marked as a duplicate of this bug. ***
*** Bug 141045 has been marked as a duplicate of this bug. ***
*** Bug 141123 has been marked as a duplicate of this bug. ***
*** Bug 141460 has been marked as a duplicate of this bug. ***
*** Bug 141505 has been marked as a duplicate of this bug. ***
*** Bug 141502 has been marked as a duplicate of this bug. ***
*** Bug 134705 has been marked as a duplicate of this bug. ***
*** Bug 141932 has been marked as a duplicate of this bug. ***
*** Bug 142000 has been marked as a duplicate of this bug. ***
*** Bug 142639 has been marked as a duplicate of this bug. ***
*** Bug 142716 has been marked as a duplicate of this bug. ***
*** Bug 142715 has been marked as a duplicate of this bug. ***
*** Bug 143211 has been marked as a duplicate of this bug. ***
*** Bug 143437 has been marked as a duplicate of this bug. ***
*** Bug 144685 has been marked as a duplicate of this bug. ***
*** Bug 148339 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: