52712 - Unable to view attachments after switching to another folder

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P1)

Description

[marina]

**** observed with 2000-09-13 build (happens to day as well)****
Steps to reproduce:
- select a mail with an attachment;
- click on the envelope and make sure you're able to view the attached file 
names;
- now copy or move this message to a different folder;
-select the moved message, click on the envelope icon:
//note: no file names are coming up

Comment 1

[Scott MacGregor]

Wow, that's not good. I just reproduced it myself. The attachment button for ANY
message is effectively dead once you copy or move a message that has an
attachment. I was using a 9/13 commercial release build in the modern skin. 

Comment 2

[selmer (gone)]

nsbeta3+, P1.  This is effectively data loss for non-developers.

Comment 3

[Scott MacGregor]

Turns out, copying the message isn't what causes a problem.

If you view a message in a folder and invoke the attachment popup, everything
looks good. Any other message in that same folder with an attachment button also
works.

Switch folders. Now you are DOA....

cc'ing some xp-toolkit folks as this appears to be related to the fact that when
you switch a folder we collapse the box which encloses the button. uncollapsing
the box, shows the button again, but never the popup.

Comment 4

[Scott MacGregor]

Attachment: proposed fix

Comment 5

[Scott MacGregor]

Turns out there was some mixture between the hidden attribute and the collapsed
attribute. hidden actually tears down the content and re constructs it again
when you remove the hidden attribute.

we had a CSS style in msgHdrViewOverlay which was supposed to map hide to
visiblity: collapse. But apparently that wasn't working.

And it looks like once a popup is destroyed and you unhide it, it never works again.

The short term mail fix is to use the collapsed attribute consistently. that's
what this patch does.

I'll file a toolkit bug and future it for menupopups not working after they have
been hidden and then unhidden.

Comment 6

[Scott MacGregor]

Fix checked in.

Comment 7

[pmock]

Verified as fixed on win32, linux, and macos using the following builds:
 win32 commercial seamonkey build 2000-092111-m18 installed on P500 Win98
 linux commercial seamonkey build 2000-092110-m18 installed on P200 RedHat 6.2
 macos commercial seamonkey build 2000-092120-m18 installed on G3/400 OS 9.04