72709 - All account information (headers, servers, groups) should be cleared from the thread pane when account is removed.

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[esther]

This bug may be a scenario of hard to reproduce feedback reports that indidate:
a.) Messages are received as noted in status bar bug do not show up in inbox.
b.) Some of my messages disappeared and are lost.

1. Launch Netscape 6 with new profile not migrated
2. Click on Mail to set up your pop account (DON'T check box to leave msg on
sever) Let's use qatest04 as an example.
3. In 3-pane window select POP account (qatest04), give password to get msgs (in
this case I had 3 msgs on server (msga, msgb, & msgc) which downloaded to my
thread pane.
4. Go back to Mail/News Account Settings and select qatest04 and remove it.
5. Now click on New Account to add qatest04 back in, making sure you check the 
 box to leave msgs on server. 
6. Afer OK'in the Account Settings window, you are back in the 3-pane mail
window.  Note: you still see msga, msgb & msgc in the thread pane window.  Click
Get Msg.

Result: Let's say you have (3) new msgs the status bar reports it received 3
msgs bug the inbox doesn't display them.  The inbox was not refreshed when the
account was removed it's still displaying the previously downloaded and removed
from server msgs (in this case msga, msgb & msgc). 
At this point the user reports problem a.) above.

Expected: When account was removed 3-pane window refreshed to show no accounts,
no msgs in thread and no message dislayed in message pane.

7. Close app and relaunch
8. Launch Mail
9. Select POP account (qatest04) and Get Msgs.

Result: msga, msgb, & msgc are no longer in inbox or elsewhere.  User sees this
as they lost those messages (they actually forget that they downloaded them with
the checkbox for leaving msgs on server unchecked so they are no longer on
server).  I'm still checking to see if the messages are lost to this user at
this point.

Comment 1

[esther]

Nominating per scott putterman, this may be one scenario that reproduces the
feedback reports that messages are downloaded but don't show up in thread pane.

here is a simple case:
User removes a mail account, (probably because he/she made a mistake in the
server name and we don't let them edit the server names)
User adds that same account back in (during the same session)
User does a Get Msg, status says it retrieved [x] msgs but they don't display in
the thread pane.  

Comment 2

[scottputterman]

marking nsbeta1+

Comment 3

[esther]

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

Comment 4

[(not reading, please use [e-mail] instead)]

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

Comment 5

[[e-mail] (gone - use [e-mail] instead)]

This happens for news, too, see bug 75454.

Comment 6

[scottputterman]

moving to mozilla0.9.1

Comment 7

[scottputterman]

reassigning to naving

Comment 8

[Navin Gupta]

Attachment: proposed fix

Comment 9

[Navin Gupta]

We should close the db associated with each folder when we are removing the 
account. This will make the hdrs go away from the thread pane. This fix 
also fixes, what must have been an old bug where we are no able to delete 
the profile on the disk. The reason it was failing was because the db 
was still open. Need review 

Comment 10

[(not reading, please use [e-mail] instead)]

it looks good.  r=sspitzer

make sure to test with all our various account types. (imap, nntp, local 
folders, pop.) 

Comment 11

[(not reading, please use [e-mail] instead)]

by turning on that code to remove files make me a little nervous.

if fact, I'd leave it off.

if the user tweaks the local path (which they can through our ui) and then 
removes the account, we'll recursively delete that directory.

since we don't prompt them about this, or mention it when they confirm the 
removal of the account, I don't think we should turn on that code.

so, please don't turn on that code.  better still, I'll add a comment to the 
code about why it scares me.

just check in the first part. (the force closing of the dbs)

Comment 12

[(not reading, please use [e-mail] instead)]

I forgot, you can't remove local folders but you can remove imported eudora, 
oe, etc.

but if you tested pop, you are safe since it covers the nsLocalMailFolder test.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

Some QA before landing is good too, so I built these 2 files in my tree (before
Seth's last comment).  I tested news.mozilla.org and my IMAP account.  Works great!

Comment 14

[(not reading, please use [e-mail] instead)]

thanks for testing it.  

note, naving tested his code.  privately over aim, he told me what he tested.

bug #77652 covers the issue of when to turn on the code.

Comment 15

[Navin Gupta]

1st part of the patch checked in. 

Comment 16

[esther]

Need to reopen.  I showed Navin the remaining problem.  What happens when adding 
the account back again within the same session the mail boxes are NOT 
really created (as seen in explorer) they appear in the folder pane but you get 
an error 80520012 when selecting them.  Because of this, the user experience is 
that the newly added account doesn't work.  Reopening.

Comment 17

[Navin Gupta]

I just fixed the messages still appearing in the threadpane problem. I will now 
look at why mailboxes weren't created. 

Comment 18

[Navin Gupta]

looks like the rdf resource for the rootfolder of the server is still around
even after the account is removed. 

Comment 19

[(not reading, please use [e-mail] instead)]

we should find and fix the leak.

note:  unregistering the RDF resource for the root folder is not the right 
approach.

Comment 20

[scottputterman]

Navin had mentioned to me that there was a way to fix this and keep the leak. 
Given that 0.9.1 is coming up quickly, is this still possible?  How big is the
leak and besides the leak are there side effects of not fixing the leak?

Comment 21

[Navin Gupta]

I don't think that the leak will be huge because only the server object is 
leaking. The account itself is not leaking. There should not be any 
side-affects because once the rdf resource is unregistered for the 
root folder there will be no way to access it. Unregistering the rdf resource
removes it from the hash table.   

Comment 22

[(not reading, please use [e-mail] instead)]

sorry for the delay.  I keep promising navin that I'll take a look, and i keep
pushing it off.

on my current linux build, I'm seeing the leaking of nsMsgIncomingServers on my
linux box.(one per account I remove).

next step, get some leak trees and try to figure out the leak

Comment 23

[(not reading, please use [e-mail] instead)]

the leak doesn't seem to happen when biff is turned off.  this leads me to 
think that either biff, or the running of the url to check for new messages is 
leaving a reference to the incoming server.

I'm still working on this.

Comment 24

[scottputterman]

moving to 0.9.2. Robin, currently help tells the user to delete the account if
they enter the wrong user name or server.  Can you change help to tell the user
to restart after deleting the account before recreating it? Navin and Esther,
restarting makes this go away, right?

Comment 25

[scottputterman]

forgot to change the target milestone.

Comment 26

[Navin Gupta]

yes, restarting would make the problem go away.

Comment 27

[(not reading, please use [e-mail] instead)]

working on other bugs right now.  

I'll resume the leak detection work when I get some cycles.

Comment 28

[robinf]

Help has been updated per comments from Scott and Esther.

Comment 29

[scottputterman]

reassigning to cavin.

Comment 30

[Navin Gupta]

I have some of the related fix already in my tree and know the cause of the 
problem. I will work with seth to find the root of the problem to get this 
checked in. reassigning back to self

Comment 31

[scottputterman]

moving to 0.9.3 per PDT.  

Comment 32

[Scott MacGregor]

Mail news triage meeting --> .9.5

Comment 33

[scottputterman]

moving to 0.9.6

Comment 34

[[e-mail] (gone - use [e-mail] instead)]

Adding 'mlk' keyword, because well, this is a leak.

Comment 35

[scottputterman]

moving to 0.9.7

Comment 36

[scottputterman]

I don't think this is as big of a deal now that you can edit the server and user
name.

Comment 37

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 38

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 39

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 40

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 41

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 42

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 43

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 44

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420