User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:188.8.131.52) Gecko/20101027 SeaMonkey/2.0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:184.108.40.206) Gecko/20101027 SeaMonkey/2.0.10 Using the email address copy feature to capture and paste the address you desire to block almost always requires 2-5 tries to get the address accepted and then it will take up to 5 minutes to save the updated mail filter after a new/updated rule has been added/modified Reproducible: Always Steps to Reproduce: 1.Open Message Filters 2.Add/Modify rule(s) 3.Try to save updated filter Actual Results: After making changes, click okay on rule windows to close and return to Message filter windows. Expected Results: In all prior versions 1.x and earlier, updated filter rules were saved almost instantly. With Version 2.x of Seamonkey, the saving of updated message rules is excruciatingly slow, even when there are only a few rules in total in the message filter area. Should work like version 1.x and earlier version of message filters and save the rules almost instantly.
One or more of your filters may have some invalid search term. Try deleting them all and then adding them back one by one.
WFM with new + modified filters Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:220.127.116.11) Gecko/20101027 Mnenhy/0.8.3 SeaMonkey/2.0.10 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101205 Firefox/4.0b8pre SeaMonkey/2.1b2pre
Using these exact same rules in Seamonkey 1.19, the rules are immediately created and control on the computer is immediately returned so I can work on something else. When the rules are being created in 2.0.x, my computer basically goes into a locked mode for the time it takes to create the rule. Also, if I am able to switch to another program while the rules are being created, the paste function in the other program is non-functional. Don't know if this helps to identify the problem, but it is very annoying.
Tom, is your profile on a network drive?
Wayne, all my profiles are stored on local drives so the i/o is not dependant on a network connection. My filter rules are either move to an existing folder or deleting the incoming message. They all key off the sender or subject contact and are either abbreviated email addresses or single word searches for subject content. These exact same rules work just fine in Seamonkey 1.19 and prior versions but when transferred into a 2.x.x version, immediately slow down to a crawl. I have switched back to version 1.19 because it is impossible for me to take 15-60 minutes trying to save 3-4 new filter rules in a typical day when I need to create new filters.
Is this still reproducible with latest build?
Whiteboard: [Halloween2011Bug][CLOSEME 2012-01-01 WFM]
Version: unspecified → SeaMonkey 2.0 Branch
Tom, will you be able to test?
Component: MailNews: Backend → Filters
Product: SeaMonkey → MailNews Core
QA Contact: mailnews-backend → filters
Version: SeaMonkey 2.0 Branch → unspecified
Tom, would it be possible to share the filter file with us? If it does contain private email addresses, you could censor them somehow. That shouldn't probably affect the bug.
Version: unspecified → 1.8 Branch
I have finally had an opportunity to test the latest version [2.4.1] using my transferred filters from Seamonkey 1.1.19 [The last version under which the filters worked properly]. So far, the filters seems to be working exactly the same as they had under the 1.x.x and prior versions. I'll need to test it a little bit more to feel reasonably comfortable that the problem has been resolved. Since it is looking promising, I don't see any point in trying to submit my filter file for further analysis. If it turns out there is still an issue, I will submit the filter file for review and testing by you. I will let you know either way by November 11, 2011. Thank you for keeping me apprised of changes to Seamonkey that might have addressed my issues with the mail filters, albeit indirectly [I don't really care if it was a direct or indirect fix that resulted in fixing my issue as long as it has been fixed!!]
Awesome. Tom. Thanks for testing.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.