User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 I have a customer header defined (X-YahooFilteredBulk) that works fine. However, every time I restart Mozilla (I think) it gets duplicated in the prefs.js file. This became apparent when I got an error on mail startup indicating that I have exceeded 50 headers and I should edit rules.dat.. (incorrect as I had only 2 rules in the rules.dat for this server) So, after editing prefs.js to clear out the duplicates, and then restarting Mozilla twice, I see: user_pref("mailnews.customHeaders", "X-YahooFilteredBulk: X-YahooFilteredBulk:: X-YahooFilteredBulk:"); (note an extra colon, too!) Reproducible: Always Steps to Reproduce: 1. Add the custom header in a filter rule 2. Restart Mozilla Actual Results: Duplicate of custom header in the prefs.js entry.
Maybe this is somewhat related to Bug 167944?
please try with latest trunk nightly builds. it should be fixed.
Tested on build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2a) Gecko/20020912 and sure enough its fixed. Although... my existing duplicates in the prefs.js mailnews.customHeaders remain there. This means I still get all the dupes listed when I drop down the header list when building a Message Filter. How about code that "tidies up" - de-duplicates the prefs.js? (An aside - let me know if I should create a new bug report for this: I see the new build does some checking of characters in the customer header, specifically it picked up that I'd used a colon at the end of one of my custom headers. It tells me to edit rules.dat (not very friendly!), and I do so, but the colon remains in the prefs.js section, so if I edit/create a new filter, I get the illegal header with colon from the drop down list. So, I think the message should tell me to edit prefs.js too? Even better if there can be a cleaner way of tidying up that doesnt involve editing any files).
Reporter: Can we resolve this bug then (WORKSFORME)?
Yes, fine by me, thanks.
-->Resolving this to WORKSFORME
marking verified worksforme