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

RESOLVED EXPIRED

Status

SeaMonkey
MailNews: Message Display
RESOLVED EXPIRED
17 years ago
8 years ago

People

(Reporter: esther, Unassigned)

Tracking

({mlk})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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.
(Reporter)

Comment 1

17 years ago
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.  
Keywords: nsbeta1

Comment 2

17 years ago
marking nsbeta1+
Priority: -- → P2
Whiteboard: [nsbeta1+]

Updated

17 years ago
Target Milestone: --- → mozilla0.9
(Reporter)

Comment 3

17 years ago
*** Bug 71582 has been marked as a duplicate of this bug. ***
*** Bug 75454 has been marked as a duplicate of this bug. ***
This happens for news, too, see bug 75454.
Summary: Headers displayed in a thread window of a removed account should be removed when account is removed. → All account information (headers, servers, groups) should be cleared from the thread pane when account is removed.

Comment 6

17 years ago
moving to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 7

17 years ago
reassigning to naving
Assignee: sspitzer → naving

Comment 8

17 years ago
Created attachment 32240 [details] [diff] [review]
proposed fix

Comment 9

17 years ago
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 
it looks good.  r=sspitzer

make sure to test with all our various account types. (imap, nntp, local 
folders, pop.) 
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)
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.
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!
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.
Status: NEW → ASSIGNED

Comment 15

17 years ago
1st part of the patch checked in. 
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 16

17 years ago
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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 17

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

Comment 18

17 years ago
looks like the rdf resource for the rootfolder of the server is still around
even after the account is removed. 
we should find and fix the leak.

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

Comment 20

17 years ago
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

17 years ago
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.   
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
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

17 years ago
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

17 years ago
forgot to change the target milestone.
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 26

17 years ago
yes, restarting would make the problem go away.
working on other bugs right now.  

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

Comment 28

17 years ago
Help has been updated per comments from Scott and Esther.

Comment 29

17 years ago
reassigning to cavin.
Assignee: naving → cavin
Status: REOPENED → NEW

Comment 30

17 years ago
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
Assignee: cavin → naving

Comment 31

17 years ago
moving to 0.9.3 per PDT.  
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
Keywords: nsBranch

Updated

17 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 32

17 years ago
Mail news triage meeting --> .9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 33

16 years ago
moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Adding 'mlk' keyword, because well, this is a leak.
Keywords: mlk

Updated

16 years ago
Blocks: 104166

Comment 35

16 years ago
moving to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Updated

16 years ago
Keywords: nsbeta1+
Whiteboard: [nsbeta1+]

Updated

16 years ago
QA Contact: esther → nbaca

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Comment 36

16 years ago
I don't think this is as big of a deal now that you can edit the server and user
name.
Status: NEW → ASSIGNED
Priority: P2 → P3
Target Milestone: mozilla0.9.8 → mozilla1.2

Updated

16 years ago
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
mass re-assign.
Assignee: naving → sspitzer
Status: ASSIGNED → NEW
Product: Browser → Seamonkey

Updated

13 years ago
Assignee: sspitzer → mail
Priority: P3 → --
QA Contact: nbaca → search
Target Milestone: mozilla1.2alpha → ---

Comment 38

9 years ago
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

Comment 39

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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
Assignee: mail → nobody
QA Contact: search → message-display

Comment 44

8 years ago
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
Last Resolved: 17 years ago8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.