310574 - customheaders not stored in user.prefs (if present) and error is misleading

Status: RESOLVED INCOMPLETE

(Thunderbird :: Preferences, defect)

Description

[wkearney99]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Shouldn't things like customheaders be stored in the user.prefs file if it
exists?    

That and if a set of rules are copied from one profile to another without also
copying the user_prefs(mailnews.customHeaders,) line the error message is
misleading.  Right now it says the filter was created by a newer version of
thunderbird and that it can't be used (or edited).  

Reproducible: Always

Steps to Reproduce:
1. Create two profiles. 
2. Create mail filter rules in 1st profile
3. Make a rule based on a Custom Header
4. Copy msgfilter.dat from the 1st profile to the 2nd profile
5. Open thunderbird in the new profile and attempt to edit or edit the rule

Actual Results:  
After step 5 you'll see that any rules with custom headers created in the 1st
profile cannot be used in the 2nd profile.  That and the error message is
misleading about the cause.

Expected Results:  
Given a more insightful error message about the customHeader not being present.
 That and when it quits it seems like it ought to save this preference value in
user.js if it's present.

Comment 1

[Mike Cowperthwaite]

I don't understand.  Custom headers are in fact stored in prefs.js (not 
"user.prefs"), but you say that you copy over   msgFilters.dat   from one 
profile to the other.  Did you update the preference in the second profile, or 
not?

xref bug 104086.  The error message is also mentioned in bug 208813.

Comment 2

[wkearney99]

Two errors here.  One is that when you edit a custom header Tbird writes it only
to prefs.js.  If the value is being set in user.js it's not the one that gets
updated.  But it's the one that'll get used the next time Tbird is started.  I
suppose I should report this in another bug.

The actual bug to be considered in this report is the error message Tbird shows
when it comes across a rule that has a custom header required that's not present
in the prefs.js.  The online docs aren't clear in stating that you need to move
BOTH the msgfilterrules.dat AND the customHeader value.  Without having the
customHeader value Tbird errorneously states it can't use the rule because it
was created by a newer version.  If anything the error message ought to at least
tell you it ran across a missing custom header.

Comment 3

[Mike Cowperthwaite]

Returning to this after a long while:

You're correct that any changes made form the UI are not saved in user.js, and user.js always overrides prefs.js.  I think this is intentional, but I can't say for sure; at any rate, I don't use user.js any longer.  Bug 208813 may have originally been about this problem.

I'm not able to reproduce the "from a future version" error message with current builds, but the filters defined to use custom headers that aren't in the list don't work correctly and don't display correctly.  Bug 104086 was opened a long time ago about this basic problem, but that bug was really nothing more than a note-to-self by one of the developers, long since gone.

> If anything the error message ought to at least
> tell you it ran across a missing custom header.

A better error would be good, but may require re-implementation of the code that causes the error message in the first place.  I took a quick look at the code, and the condition linked to that error -- an "unparseable filter" -- can occur for other reasons than an unrecognized header.


> The online docs aren't clear in stating that you need to move
> BOTH the msgfilterrules.dat AND the customHeader value.

Uh... *what* online docs?  I don't think there's any supported documentation recommending that you copy msgFilterRules from profile to profile.

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)

Comment 5

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Reporter, does the issue still occur in the latest supported 2.0.0.x / Shredder trunk nightlies?

(1.5.0.x is now end-of-life and the latest supported 2.0.0.x is 2.0.0.16)

Comment 6

[Joshua Cranmer [:jcranmer]]

RESO INCO per lack of response to the last question(s). If you feel this change was made in error, please respond to this bug with your reasons why.