Closed Bug 37454 Opened 25 years ago Closed 15 years ago

Delete & add acct back within same session shows old folders

Categories

(SeaMonkey :: MailNews: Account Configuration, defect)

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: laurel, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: privacy)

Using apr27 commercial builds Follow-up issue to bug #31079 When you delete an account then add the same account back within the same session, the deleted folder/group hierarchy displays for the remainder of that session. Once you exit and return, the new account hierarchy is present. The false/old/cached information may fool the user into thinking it's actually usable in that session and when they exit it is replaced by the new folder/group structure. I'm sure there are lots of errors that can occur, but one example is with POP accounts: if the user does a Get Msg while in this "false folder display" state, they will see the status bar display that new messages were retrieved but they never appear in the false inbox they see in the folder pane. Once they exit and return those messages which were retrieved are in the "new" inbox. This and other operations may cause extreme confusion to the user. Steps to reproduce: 1. Add a POP account to a profile. Open the POP account, login and get messages. Create a New Folder within the POP account hierarchy. Exit and return to mail window. 2. Go to Account Settings, select the POP account and Delete it, confirm OK and OK again out of the account settings dialog. Check the folder pane and see that the account has been removed from the pane's display. 3. In that same session, go back to Account Settings and add the same POP account and confirm addition. 4. Go to folder pane and expand the POP account hierarchy. Note the folder you added in step #1 is displayed within the POP account hierarchy. 5. (From another machine/account) send a mail message to the POP account user. 6. Click Get Msg. Note the status bar text shows new message was received, but when you open Inbox it doesn't appear. 7. Exit and return to mail window, open POP inbox. See that the new message appears (and dependent on Leave on Server setting other inbox messages may no longer appear) and the user folder from step #1 is gone. You are now looking at the newer/added POP account folders. Actual result: after adding back the same account as was deleted in same mail session, the cached/older account's folder info appears in folder pane. Expected result: new account folder info should appear. Note: Applies to all account types, when verifying try IMAP, NNTP and POP accounts.
QA Contact: lchiang → laurel
oh man. I think this means we're leaking nsIMsgFolders....
Status: NEW → ASSIGNED
adding putterman, maybe he has some enlightenment for us
This could be a number of things. For example, when we delete an account, do we delete all of the storage for all of the folders? If not then this would occur. Likewise, I've seen this with newsservers. I think this happens because we don't remove the rc file when we delete the server. We need to make sure all files associated with that account are removed if we really want to delete them.
Putterman: no, folders and .rc files are not deleted -- see bug #31079 as I referenced.
scott, no I don't think that's the problem. we currently do not delete the files on disk, but that's ok because I made it so that when creating a local path for a server, it calls MakeUniqueWithSuggestedName(). example: create account for server "foobar", local path is Mail/foobar delete that account. create account for server "foobar", local path is Mail/foobar-1 (since foobar still exists). so, on disk, we are safe. (but we still need to clean up after ourselves.) my theory (which I haven't proved yet), is either we need to "unassert" certain things in the folder datasource, or we are unasserting, and the folder pane isn't getting notified. I may be wrong about some of this, but this is my hunch. we aren't handling deleting an account / server properly yet, as we aren't forcing all the dbs (summary files) closed. (if they are open, we can't delete them, at least on win32, and if we can't delete them, we can't delete the server folder.)
I'll try to look at this today.
it's definitely the case that we are leaking every single folder currently and that that is causing this problem.
It looks like deleting an account leaves around a ref to a server which leaves around a ref to the rootfolder. I don't know if fixing this would make the problem or the leak go away, but it would be a start.
hrm. so incoming servers should own the root folder, and the account manager should own the account, which should own the incoming server. There's a possibility that the account manager is holding multiple refs to the incoming server since there are a couple of datastructures there.. I might have missed one when I . This sounds like a job for the refcount balancer :) one way to check is if the new server gets a fresh serverid, or gets the old one. if the new server gets a fresh serverid, then it's probably the hashtable of servers, which would not be good.
Target Milestone: --- → M17
Target Milestone: M17 → M20
massive reassign of account manager bugs -> sspitzer please feel free to put me back on the CC if you have any questions/comments
Assignee: alecf → sspitzer
Status: ASSIGNED → NEW
*** Bug 58714 has been marked as a duplicate of this bug. ***
more re-assigns to racham.
Assignee: sspitzer → racham
Status: NEW → ASSIGNED
Target Milestone: --- → Future
mass re-assign.
Assignee: racham → sspitzer
Status: ASSIGNED → NEW
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Priority: P3 → --
QA Contact: laurel
Target Milestone: Future → ---
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
Status: NEW → UNCONFIRMED
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
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
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
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
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
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
Depends on: 64800
Assignee: mail → nobody
Keywords: privacy
QA Contact: mailnews-account
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
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
This is WFM by now.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.