16244 - [FEATURE] Empty Trash on Exit for POP3 and IMAP

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P4)

Description

[laurel]

The current Account Setup spec indicates POP mail server panel will have a pref
for Empty Trash on Exit.   Via comments in bug #14087 alecf indicated this will
indeed be implemented at some point in seamonkey. This is a tracking bug.

The pref was in 4.x only for IMAP servers, not available in POP prefs.
The pref is located in the mail server panel, 4.x in prefs dialog and seamonkey
in Account Setup dialog.

Comment 1

[Phil Peterson]

Assign to jefft, cc bienvenu and mscott. Not a B1 feature, so setting M15.

Comment 2

[Ben Bucksch (:BenB)]

Doesn't work for me with IMAP either. Per the alecf's comment, I assume, it

isn't implemented at all. Am I correct? If yes, we should change the summary.

Comment 3

[Ben Bucksch (:BenB)]

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

Comment 4

[jefft]

jglick, do we have a pref design for Empty Trash On Exit for Pop3 accout?

Comment 5

[lchiang]

move to M16.  Not M15 stoppers

Comment 6

[jglick]

http://gooey/client/5.0/specs/mail/accountSetup/accountSetup.html#AccountSetting
s

Section on Account - Server - POP

Comment 7

[jefft]

Empty trash on exit for Imap seems not that easy to do because of the nature of 
the asynchronous operation plus the connection caching. I thought I could empty 
the trash prior the account manager close down all cached connections. However, 
this is not working at the moment. Although I implemented the nsIUrlListner for 
nsImapIncomingserver. OnStartRunningUrl and OnStopRunningUrl never get hit.

Comment 8

[Scott MacGregor]

Hey Jeff, if you aren't seeing the on start and on stop calls for the url
listener you implemented, maybe it isn't getting attached to the url you are
interested in? What url is getting run that you want to be a listener on? I
maybe be able to help you debug this part if you need it.

Comment 9

[jefft]

I am sure that the url listener is getting added correctly to the url listener 
manager. I'll look into more.

Comment 10

[David :Bienvenu]

As I understand it, Jeff is running this url as the app is exiting. Highly 
unlikely that it gets to run.

Comment 11

[Scott MacGregor]

Oh dear. I see. Yes in that case there's a strong chance the url isn't getting
run so we wouldn't see the on stop and on start calls.

Comment 12

[jefft]

Attachment: A partial fix.

Comment 13

[jefft]

I am basically stocked on this one. I need to find a way to ensure that the 
async imap empty trash to finish prior shutting down the app. Low priority for 
the feature now...

Comment 14

[lchiang]

Jeff - P4 priority means that the feature won't be in the product when it ships. 
Will this feature make it?  

Comment 15

[jefft]

I don't know. The workaround is manually doing it. This is sort of an 
architeture issue. I don't have a solution yet.

Comment 16

[Ben Bucksch (:BenB)]

> The workaround is manually doing it.

That's a workaround for beta quality, but not for a final product. Without this
feature, the Trash delete model is useless. (Compare Windows Explorer: I always
delete and immediately empty trashcan - *very* annoying.)

I understand the problem, but we should make sure, it is resolved for final. Who
is the relevant developer, so I can bug him (or dance on his head, if necessary
;-) )? Is there a bug filed on that?

Comment 17

[jefft]

No, there is no bug filed and it's not a final decision yet. dp would be 
the person to start with.

Comment 18

[lchiang]

I can file a bug on DP, but I don't know what it should say.  Then, we can make 
this bug dependent on that one.  Ben - want to file the bug?

Comment 19

[Ben Bucksch (:BenB)]

beta2 nomination (not sure, if [FEATURE] implies that)

Comment 20

[Alec Flett]

I've talked about this issue with bienvenu - I don't think we need anything from 
DP on this - I think we need to be notified when the last mail window goes away, 
which we should know from the mail session, which tracks nsIMsgWindows.

Comment 21

[jefft]

I am afraid this won't work if the user quits from the browser window. It works 
only when we still have the browser window open.

Comment 22

[Alec Flett]

if that's not working them something in our architecture is broken. It should 
not matter what window you quit from.

When the user quits, all windows should all close, and the onunload handlers 
should all fire. Each unload handler in each mail window should unregister the 
associated nsIMsgWindow object. When that list reaches zero, we should have some 
sort of notification system which tells us that everything has shut down.

Comment 23

[jefft]

The problem is really asynchoronous operation. No one waits for us to complete 
unless there is a mechnism in place. See 35704 for some explanation.

Comment 24

[Alec Flett]

oh! I see what you're saying. that's quite a conundrum.

Comment 25

[leger]

Putting on [nsbeta2+][5/16] radar.  This is a feature MUST complete work by 
05/16 or we may pull this feature for PR2.

Comment 26

[jefft]

I have found a way to fix this. Fix checked in.

Comment 27

[Ben Bucksch (:BenB)]

Cool! How did you solve the problem?

Comment 28

[jefft]

It's kind of hack. I guess depends on how you view it. Apparently, as dp and 
waterson pointed out the event queue isn't dead at the moment when xp-shutdown 
notification were sent out. What I did was using PR_CMonitorEnter(), 
PR_CMonitorExit(), PR_CWait() and ProcessPendingEvent() along with 
the nsIUrlListener interface to do the trick.

Comment 29

[Karen Huang]

By using 05-18-08-M16 commercial build.
It seems that the UI "Empty Trash on Exit" for POP3 & IMAP still not implement 
yet from account setup UI.
This bug is logged for backend.
Jeff, would you provide the verification for me to verify this bug?

Comment 30

[jefft]

UI is implemented but have problems with getting/setting the value. Add the 
following pref to your prefs.js

user_pref("mail.server.server1.empty_trash_on_exit", true);
 

Comment 31

[Karen Huang]

Sorry for the delay....I actually already verified on WinNT & Linux 
platforms....but since this bug need to verified on all the platform....(I had 
problem for my Mac 9.0 machine)...

Finally, verified on all the platforms by using:
WinNT 05-19-09-M16 commercial build
Linux 05-19/22-08-M16 commercial build 
Mac 05-22-08-M16 commercial build
Marking as verified.