97530 - Filter disables in this case of rename destination folder - exit after rename.

Status: VERIFIED FIXED

(MailNews Core :: Filters, defect)

Description

[laurel]

Related bug 41720

Using aug29 commercial trunk build: win98, linux rh6.2, mac OS 9.0
Happens for IMAP or POP filters/folders

The fix for bug 41720 made it so that filters would work after renaming a folder
which was involved as a filter destination. That works when the rename takes
place in the same session as getting/filtering a new message.  The scenario
below causes filter to be disabled and therefore the message doesn't get moved
to the intended destination folder.

Steps:
1.   Set up a simple filter on POP or IMAP account with an action to Move To
Folder.  Specify a folder (top level or sub) on that same account as the
destination for the filter action.  
2.   Send yourself a message which will match the filter criteria, get the
message and verify it is indeed moved to the destination folder properly.
3.   Rename the destination folder.
4.   Exit, then launch to mail, login to the account and send yourself a message
which will match the filter criteria.
5.   Get that message and note it is not moved from the inbox. 
6.   Check the filter dialog and note the filter has been disabled.

Comment 1

[Navin Gupta]

This is happening because we are not able to get the filter service during 
shutdown. Looks like we release the service manager and then try to get the 
filterService so we get ns_errror_failure and null. I will work on the fix.  

Comment 2

[Navin Gupta]

Attachment: proposed fix

Comment 3

[Navin Gupta]

The current code tries to save the filter list in the nsMsgIncomingServer 
destructor. Well that is not very safe, if there is leak it will never be
called, there could be other cases besides this bug where filterlist may never
gets saved. 

So, I moved it to account manager code and upon exit we now save
the filter list. This is the correct way of doing it.

cc sspitzer and cavin for review. 

Comment 4

[Cavin Song]

r=cavin.

Comment 5

[Navin Gupta]

cc bienvenu for sr. 

Comment 6

[David :Bienvenu]

if I understand correctly, when you rename the folder, we adjust the filter,
right? If that's the case, you should be saving the filters at that point.
Moving the filter saving code around won't fix the problem if you crash after
renaming the folder.

Comment 7

[Navin Gupta]

we can also save just after renaming, but we will still need this patch to
save any other session changes. We do save on New filter and Edit Filter...
I cannot think of any other situation right away.

Comment 8

[David :Bienvenu]

I think I'm not being really clear - we should always save when something
changes about the filters - the save in the destructor was just a temporary
catch-all because originally the filter editing code did not save the filters at
all.

Comment 9

[Navin Gupta]

Attachment: proposed fix, v2

Comment 10

[David :Bienvenu]

looks good, sr=bienvenu

Comment 11

[Navin Gupta]

fix checked in.

Comment 12

[laurel]

This scenario working OK with sep5 commercial trunk build: mac OS 9.0, linux
rh6.2 and win98. 
Any other scenarios found to be a problem involving renaming and filters will be
logged separately.

Comment 13

[laurel]

Reopening... this fix never made it to the branch and is needed to make fix for
bug 98391 (and bug 41720) work effectively on the branch.

Comment 14

[Scott MacGregor]

Unfortunately it's a bit late in the game to be trying to take this fix. If we
tried last week I'm sure we could have gotten it in. I'll try to take it to PDT
but I'm not hopeful.

Comment 15

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 16

[Navin Gupta]

fixed on branch

Comment 17

[laurel]

OK using sep26 commercial 0.9.4 build: win98, linux rh6.2, mac OS X

Comment 18

[Dawn Endico]

removing link to this fixed bug from mozilla 0.9.6 release notes.