796867 - Cannot delete nor move messages with filters when compact option is on

Status: REOPENED

(Thunderbird :: Filters, defect)

Description

[jarkap]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427



Actual results:

After some waiting and receiving a few messages (POP3) things get stuck: junk isn't automatically moved to junk folder. I can't delete/move any messages manually either. Turning off "Compact all folders when it will save [eg. 5] MB in total" option seems to fix the problem. I can see it in 16.0 beta too. I didn't see it in 13.0.1 (not sure about 14.0), but might have changed the threshold in the meantime.

Comment 1

[:aceman]

Anything in tools->Error console after the stuck state happens?

Comment 2

[jarkap]

(In reply to :aceman from comment #1)
> Anything in tools->Error console after the stuck state happens?

Hmm... I'll be able to check this (box) on Thursday. Thanks for the hint.

Comment 3

[jarkap]

Here are some examples:

Timestamp: 2012-10-04 09:35:14
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://messenger/content/messenger.xul
Line: 0

Timestamp: 2012-10-04 09:35:14
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://messenger/content/messenger.xul
Line: 0

Timestamp: 2012-10-04 09:34:49
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://messenger/content/messenger.xul
Line: 0

Timestamp: 2012-10-04 09:33:51
Warning: XUL box for _moz_generated_content_before element contained an inline #text child, forcing all its children to be wrapped in a block.
Source File: chrome://messenger/content/messenger.xul
Line: 0

Timestamp: 2012-10-04 09:33:43
Warning: Unknown property 'mso-style-parent'.  Declaration dropped.
Source File: mailbox:///C:/Users/info/AppData/Roaming/Thunderbird/Profiles/795ho33b.default/Mail/poczta.internetdsl.pl/Inbox?number=4576598
Line: 207

Timestamp: 2012-10-04 09:33:43
Warning: Unknown property 'mso-style-name'.  Declaration dropped.
Source File: mailbox:///C:/Users/info/AppData/Roaming/Thunderbird/Profiles/795ho33b.default/Mail/poczta.internetdsl.pl/Inbox?number=4576598
Line: 196

Timestamp: 2012-10-04 09:33:43
Warning: Unknown property 'mso-style-name'.  Declaration dropped.
Source File: mailbox:///C:/Users/info/AppData/Roaming/Thunderbird/Profiles/795ho33b.default/Mail/poczta.internetdsl.pl/Inbox?number=4576598
Line: 192

... and much more like the last one

Comment 4

[Ludovic Hirlimann [:Usul]]

Those aren't too releveant :(

Comment 5

[jarkap]

Maybe there where something more relevant but with timestamps before or longer after the lockup. If there is a way to get more complete error log without copying and pasting them one by one (and without leaking any private information) let me know. I could also install some debugging version if available. BTW, probably it's irrelevant too, but I found there is some exception: I cannot delete messages from any folder but the Trash when this bug triggers.

Comment 6

[jarkap]

It looks like the main culprits are message filters (ver. 16.0.1 now). With "Apply filter when: Checkin mail (after classification)" and "Perform these actions: Delete Message" filters present, there seem to be some problem with messages that are both classified (to Junk) and filtered (to Trash).

Comment 7

[Wayne Mery (:wsmwk)]

could we flag the compact logic to skip compacting a folder if a filter delete is in progress?

Comment 8

[:aceman]

Probably yes, but I have no idea how. Is the compacting so asynchronous that we start it before filter execution is finished?

Comment 9

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #8)
> Probably yes, but I have no idea how. Is the compacting so asynchronous that
> we start it before filter execution is finished?

Kent, question for you ^

Comment 10

[:aceman]

Actually I think compact skips locked folders at https://hg.mozilla.org/comm-central/file/9f9a344d0f24/mailnews/base/src/nsMsgFolderCompactor.cpp#l265 . So if filters set (and also check) locking properly, "stuck" folders shouldn't happen.

Reporter, is this a actually still happening in TB31.x?

Comment 11

[Kent James (:rkent)]

(In reply to Wayne Mery (:wsmwk) from comment #9)
> (In reply to :aceman from comment #8)
> > Probably yes, but I have no idea how. Is the compacting so asynchronous that
> > we start it before filter execution is finished?
> 
> Kent, question for you ^

Sorry, I don't know the answer to that without digging into the code. I've actually dealt very little with compacting.

Comment 12

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #10)
> Actually I think compact skips locked folders at
> https://hg.mozilla.org/comm-central/file/9f9a344d0f24/mailnews/base/src/
> nsMsgFolderCompactor.cpp#l265 . So if filters set (and also check) locking
> properly, "stuck" folders shouldn't happen.
> 
> Reporter, is this a actually still happening in TB31.x?

jarkap email address is dead

can anyone else reproduce?
or is this an easy dup of another bug?

Comment 15

[André Weidemann]

Attachment: compact-problem-thunderbird.jpg

The message "The folder xxx cannot be compacted because another operation is in progress. Please try again later." still occurs under TB 78.6.1.

Comment 16

[Wayne Mery (:wsmwk)]

Based on comment 10, I think this should no longer happen.

(In reply to André Weidemann from comment #15)

Created attachment 9199464 [details]
compact-problem-thunderbird.jpg

The message "The folder xxx cannot be compacted because another operation is in progress. Please try again later." still occurs under TB 78.6.1.

Well, that is bug 837620 and caused by what is mentioned in comment 10. So it is the reverse of this bug.

Comment 17

[Wayne Mery (:wsmwk)]

For(In reply to Wayne Mery (:wsmwk) from comment #16)

Based on comment 10, I think this should no longer happen.

Forget that - bad logic.

And comment 10 should induce bug 837620 - another good reason for compact to not be allowed to happen during startup