208813 - Doesn't save custom headers defined for mail (user.js overrides)

Status: NEW

(MailNews Core :: Filters, defect)

Description

[Matthew DiGiorgi]

User-Agent:       Mozilla/Netscape compatible; (U; en-US; NOYFB)
Build Identifier: Mozilla 1.4rc1 release

When I define a custom header for a mail filter rule to process on, Mozilla does
not save that header in prefs.js for subsequent processing.

Reproducible: Always

Steps to Reproduce:
1. Define new mail filter
2. Create new mail header for filter.
3. Exit Mozilla
4. Start up again -- custom header doesn't exist and filter rule fails to activate.



Expected Results:  
Save the new customheader in prefs.js

Workaround is to define customheader in user.js

(Thunderbird (06-03-2003) creates the customheader instruction in prefs.js
correctly.)

Comment 1

[David :Bienvenu]

correcting component. I wouldn't have thought this code had changed recently...

Comment 2

[David :Bienvenu]

this works for me with a trunk mozilla build - don't know why rc1 would have a
problem.

Comment 3

[msgregory]

I think this story might be related:

My computer overheated and rebooted while Mozilla was running.  Something got
corrupted and Mozilla segfaulted every time I tried to open it.  So, I started
to install 1.4, which I downloaded the other day, but forgot to install (I was
running rc3).  I clicked "Next" a couple of times and then decided that maybe I
should uninstall first so I cancelled and uninstalled the old Mozilla before
installing the new.  Well, all my settings were gone so I had to set everything
up again.  It's a pain in the ass not being able to specify the folder you want
to use when creating a new mail account, but that's another issue.  When I
finally did get the folder specified, two of my mail filters couldn't be
enabled.  It said "this filter was created by a future version of Mozilla!"  The
problem was that I had a custom field "Reply-To" (not sure why that's considered
a custom field, but maybe it really is custom).  Anyway, I had to go into a
different filter (because the edit button for the broken filters was disabled)
and add the custom header in there by clicked "More", clicking the drop down,
clicking "custom", added the header, clicking ok, etc.

So, I think that's sufficiently un-user-friendly enough to warrant a bug report.

I don't know if this is the right place.

Comment 4

[Mike Cowperthwaite]

There is an issue here: if the pref statement exists in both user.js and prefs.js when the program is started.  The version in user.js gets read, and overrides the prefs.js version -- and this causes the pref to be "dirty" so it will always be saved, even if no other changes take place.

Any further changes are written out to prefs.js, but on restart, user.js is loaded again.

I don't know if this behavior is unique to this preference or if everything in user.js causes the same overriding of any settings the user tries to save from the UI.

I wonder whether, given about:config's ubiquity, the time might not have arrived for user.js to be axed.

Comment 5

[Mike Cowperthwaite]

Per comment 3: I don't think having a missing header is responsible, any more, for causing that "filter was created by a future version" error message; at least, I can't reproduce it.  I do see that, for a filter dependent on a header that's no longer listed, the displayed header in the filter is the first item from my list of custom headers (bug 104086), but I don't think that listed header is actually for anything.

Comment 6

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> There is an issue here: if the pref statement exists in both user.js and
> prefs.js when the program is started.  The version in user.js gets read, and
> overrides the prefs.js version -- and this causes the pref to be "dirty" so it
> will always be saved, even if no other changes take place.
> 
> Any further changes are written out to prefs.js, but on restart, user.js is
> loaded again.
> 
> I don't know if this behavior is unique to this preference or if everything in
> user.js causes the same overriding of any settings the user tries to save from
> the UI.
> 
> I wonder whether, given about:config's ubiquity, the time might not have
> arrived for user.js to be axed.

Hi Mike. A question since you seem to understand this area well.
a) what would you suggest as an alternative?
b) in your years in bugzilla and with users, can you describe any other situations where users got bit by this issue?

cc: rsx11m or joe in case they have views on this issue

Comment 7

[Mike Cowperthwaite]

For point (a), if the capability of user.js is deemed worth keeping, the best behavior would be:  when a pref value changes, to determine whether that pref exists in user.js and if so, warn the user -- presumably, if someone is running with a user.js, file, they know enough to go in and change it appropriately.  That would be a lot of code for a tiny improvement.

Regarding point (b), I've encountered an instance of late where user.js can be useful.  The pref 
  mailnews.thread_pane_column_unthreads
had its default changed from True to False between TB 2 and TB 3.  I want it set to False.  If I start TB 3, that setting matches the default, and the behavior is to write to prefs.js only those prefs whose settings are not default, so the file is written without the pref.  Then when I go back to TB 2, there is no setting in prefs.js, so it starts with the wrong default, and I have to set it by hand again.  (I would be OK -- not thrilled, but OK -- with running TB 3 all the time, but the problems at bug 459521 and bug 461713 remain unsolved.)

Obviously, this is not a typical scenario, which is why I wondered whether dropping user.js support entirely might be worth it.  Back when I was first getting into Mozilla stuff, it seemed that many people had user.js files that they hadn't explicitly created, and I remember at least one newsgroup discussion trying to figure it out.  None of my TB or Fx profiles have one now.

Comment 8

[:aceman]

Is this still a problem? I think there should be no need to define this in user.js manually.