43992 - Collapse the addr block in msg compose loses recipients...

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[laurel]

Using jun27 m17 commercial build

When you collapse and reopen the addressing toolbar in the message composition
window, any contents/recipients are lost.

1.  From mail window, New Message (either HTML or plain text).
2.  Type some addressees on separate To: lines.
3.  Collapse the addressing block by clicking the little arrow widget at the
left of the address block. Click to expand it again.

Result:  content of address block is wiped out.

Expected:  should retain all information in address block through
collapse/expand.

Comment 1

[laurel]

cc asa since he found this, mentioned in comments of bug #43679.

Comment 2

[Jean-Francois Ducarroz]

This is append with any textfield (like the subject line) but not with menu 
list element. Reassign to editor team.

Comment 3

[lchiang]

nominate for nsbeta2.

Loss of data although it's not a frequently used function.  May need this for 
nsbeta3?

Comment 4

[kinmoz]

Assigning to [e-mail].

The GfxTextControlFrames are getting destroyed and recreated when you collapse 
the toolbar, and no one is saving the current TextField value. Perhaps we need 
to store the current value in the content before the frame goes away?

Comment 5

[kinmoz]

Accepting bug.

Comment 6

[Blake Ross]

recommend beta2, but nominating for beta3

Comment 7

[lchiang]

what happened to my nsbeta2 nomination?  I'll renominate.

reason: loss of recipient list after collapse the addressing area in the compose 
window.

Comment 8

[Jay Patel [:jay]]

Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix 
to make a call on this bug. How often will people actually collapse this list?  
The list never shows more than 3 in the window (since we have a scroll bar for 
long lists).

Comment 9

[Asa Dotzler [:asa]]

I collapse it all the time (or would like to) in order to maximize screen
realestate while composing an email. 

Comment 10

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix. What fix is easier...fixing this bug 
or taking out this collapse feature from the product?  We would happily ship pr2 
without the collapse feature.

Comment 11

[leger]

putterman can we just take out collapsing this and not fix this bug?

Comment 12

[scottputterman]

ducarroz is on this bug so he can comment on how much work this would be. cc'ing
jglick for her comments. For beta2 I think it would be ok to take it out.  But I
don't think we want to ship without the ability to collapse so I'll leave the
nsbeta3.

Comment 13

[kinmoz]

The fix for this may be as simple as saving the current content of ender in the 
value attribute of the content node before the frame goes away.

I can take a look at this as soon as I finish wrapping up the current nsbeta2+ 
bug I'm working on.

Comment 14

[kinmoz]

Assigning to [e-mail] so we can try to get this fixed right away.

Comment 15

[rubydoo123]

setting fix by date

Comment 16

[mjudge]

this will not be fixed in beta2 timeframe with the dependencies we have found.  
The toolbar collapsing is destroying the underlying frames and moving the 
contents out of the document thus bypassing the history code that would have 
preserved state.  After trying different things and discovering what has 
happened I talked to hyatt and he told me that this is completely non-trivial to 
fix until the toolbar is rewritten(possibly ben goodyear).  The toolbar cannot 
be rewritten until hyatt fixes 41145.  He wanted to fix this but it has been 
marked beta2-.  Since that will not be fixed then this will not be fixed.  

If someone wants to escalate rewriting the toolbar code there is a very small 
chance that this work could be done for beta2 thus fixing this bug.

Comment 17

[Phil Peterson]

In that case, let's go back to the leger/pdt suggestion of making the addressing
toolbar not collapsible. I don't see why that's a big deal -- the compose window
is for addressing. Would be interested in putterman's thinking though.

Comment 18

[scottputterman]

It's fine not to collapse it. cc'ing sol.  We talked about this briefly last
week and if for some reason we can't make it uncollapsable we thought that would
be ok for beta2 as well. The user will lose their addresses the first time and
learn not to collapse it ever again.  My guess is that many more people don't
ever attempt to collapse it than those who do.

Comment 19

[Jean-Francois Ducarroz]

Yes, a release note should be enough. Add keyword relnote

Comment 20

[sol]

Clearing nsbeta2+ from Status Whiteboard.

As Scott mentions, we expect most users won't do this, and those that do will 
quickly learn not to do it again. Therefore, "relnote2" seems an OK solution.

Need to fix this before we ship, and this bug is already marked "nsbeta3".

Comment 21

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. 

Comment 22

[mjudge]

*** Bug 41400 has been marked as a duplicate of this bug. ***

Comment 23

[lchiang]

*** Bug 46463 has been marked as a duplicate of this bug. ***

Comment 24

[rubydoo123]

setting to nsbeta3+

Comment 25

[rubydoo123]

adding the brackets in the status

Comment 26

[rubydoo123]

this is going to require help from other folks, but will try and get to this 
before nsbeta3

Comment 27

[mjudge]

i am just going to hand this to ben goodger when he finishes with the rewriting
of the collapsable menus just reassign this to me. (thought i hope that his
rewrite just solves the problem)

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

This was fixed with my toolbar rewrite update a couple of weeks ago...

Comment 29

[Asa Dotzler [:asa]]

I can verify this on 082408 win32 mozilla build and 082409 mac mozilla build.
Collapsing the addressbar does not destroy it's recipients.  SOmeone want to
verify on Linux and wrap this one up.

Comment 30

[laurel]

OK with linux rh6.0 using 2000-08-24-08 commercial build.