Closed Bug 342912 Opened 18 years ago Closed 18 years ago

Filter to Trash causes the trash folder to get opened

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird2.0

People

(Reporter: mscott, Assigned: Bienvenu)

Details

(Keywords: fixed1.8.1)

Attachments

(3 files)

I have a filter which moves messages to my trash folder. When the filter fires, the trash folder ends up getting selected for IMAP.

06/27 branch build.
Target Milestone: --- → Thunderbird2.0
I think my junk mail folder is doing the same thing. I'll try to look it up in the log. 
Attached patch proposed fixSplinter Review
Wanna try this? This should fix it...
Attachment #228199 - Flags: superreview?(mscott)
David, this looked better to me, I didn't see it selecting my trash folder when a filter rule moved a message to my trash.

But then I looked at my imap log and I still see a select firing for the trash folder after the copy.

0[b35c10]: queuing url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: considering playing queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: creating protocol instance to play queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: failed creating protocol instance to play queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: considering playing queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: creating protocol instance to play queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
0[b35c10]: playing queued url:imap://macgrego@mail.scott-macgregor.org:993/onlinemove>UID>.INBOX>2444>.Trash
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:ProcessCurrentURL: entering
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:ProcessCurrentURL:imap://macgrego@mail.scott-macgregor.org:993/onlinemove%3EUID%3E.INBOX%3E2444%3E.Trash:  = currentUrl
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:SendData: 15 uid copy 2444 "INBOX.Trash"

0[b35c10]: WARNING: NS_ENSURE_TRUE(nsDoc) failed: file c:/build/trees/tbirddbg/mozilla/content/xul/content/src/nsXULElement.cpp, line 2042
3880[3f3f140]: ReadNextLine [stream=3f407e0 nb=54 needmore=0]
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:CreateNewLineFromSocket: 15 OK [COPYUID 1152134562 2444 6480] COPY completed.

3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:SendData: 16 uid store 2444 +FLAGS (\Deleted \Seen)

3880[3f3f140]: ReadNextLine [stream=3f407e0 nb=47 needmore=0]
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:CreateNewLineFromSocket: * 399 FETCH (UID 2444 FLAGS (\Seen \Deleted))

3880[3f3f140]: ReadNextLine [stream=3f407e0 nb=24 needmore=0]
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:CreateNewLineFromSocket: 16 OK STORE completed.

1924[54fc2c0]: ImapThreadMainLoop entering [this=54e6d60]
0[b35c10]: 54e6d60:mail.scott-macgregor.org:NA:SetupWithUrl: clearing IMAP_CONNECTION_IS_OPEN
1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:NA:ProcessCurrentURL: entering
1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:NA:ProcessCurrentURL:imap://macgrego@mail.scott-macgregor.org:993/select%3E.Trash:  = currentUrl
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:SendData: 17 IDLE

3880[3f3f140]: ReadNextLine [stream=3f407e0 nb=22 needmore=0]
3880[3f3f140]: 3f37a28:mail.scott-macgregor.org:S-INBOX:CreateNewLineFromSocket: + entering idle mode

1924[54fc2c0]: ReadNextLine [stream=54fd088 nb=242 needmore=0]
1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:NA:CreateNewLineFromSocket: * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc.  See COPYING for distribution information.

1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:NA:SendData: Logging suppressed for this command (it probably contained authentication information)
1924[54fc2c0]: ReadNextLine [stream=54fd088 nb=16 needmore=0]
1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:NA:CreateNewLineFromSocket: 1 OK LOGIN Ok.

1924[54fc2c0]: 54e6d60:mail.scott-macgregor.org:A:SendData: 2 select "INBOX.Trash"
I wonder if I uncovered another bug while looking at this. My filter moved the message to Trash, the new mail alert icon showed up in the system tray, but there's no popup associated with it because when we ask the folders for unseen messages, none of them report having any (which is correct), but the our system tray icon shouldn't have showed up. I'll try to look into that issue more.
weird, I'm not seeing the trash folder getting updated - I set a breakpoint in nsImapMailFolder::UpdateFolder and it's not getting hit for the trash folder. This was on the trunk. Does your filter move to the trash, or delete (should be the same, but...)
(In reply to comment #5)
> weird, I'm not seeing the trash folder getting updated - I set a breakpoint in
> nsImapMailFolder::UpdateFolder and it's not getting hit for the trash folder.
> This was on the trunk. Does your filter move to the trash, or delete (should be
> the same, but...)
> 


it was moving to trash. I'll try it again tonight and will step through the patch to see where the select is coming from.
I looked into this a little more. We aren't calling UpdateFolder in nsImapMailFolder::OnStopRunningUrl for this particular case anymore after your fix.

However, a few lines down we call: 

(void) OnCopyCompleted(m_copyState->m_srcSupport, aExitCode);

which eventually puts us in nsMoveCoalescerCopyListener::OnStopCopy which selects the folder (in this case my trash folder).

http://lxr.mozilla.org/mozilla/source/mailnews/base/util/nsImapMoveCoalescer.cpp#281




 
ah, thx, yeah, I figured there must be a second place when it didn't work for you. Not sure why it didn't trigger for me, but I can fix it.
I'm wondering if we even need that code in nsMoveCoalescerCopyListener::OnStopCopy  - it would seem to be redundant with the code in nsImapMailFolder::OnStopRunningUrl. I'll look into that...
Status: NEW → ASSIGNED
Can you try this, Scott? You use imap mail more regularly ... I'll be on the mac for a few days so I won't get the new mail alerts.

If this works, I can rip out a bunch of code, where the imap move coalescer is a movecopy listener - if we don't need this code, it doesn't need to be a move copy listener.
This new patch fixed the selection of the trash and junk folders that I've been seeing. I'll keep running with it and will let you know if I see any regressions. 
an additional patch...
Attachment #228845 - Flags: superreview?(mscott)
Comment on attachment 228845 [details] [diff] [review]
change to nsImapMoveCoalescer

the first patch and this patch together are behaving correctly for me in my limited testing so far.
Attachment #228845 - Flags: superreview?(mscott) → superreview+
Attachment #228199 - Flags: superreview?(mscott) → superreview+
fixed on trunk - I'll land on the branch as well.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
fixed on 1.8 branch as well.
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: