Closed Bug 224811 Opened 17 years ago Closed 12 years ago

mailnews.reply_header_originalmessage pref does not work


(MailNews Core :: Composition, defect)

Not set


(Not tracked)



(Reporter: wille, Unassigned)



User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030

Changing the value of mailnews.reply_header_originalmessage does not change when
I forward a email

Reproducible: Always

Steps to Reproduce:
1. in about:config, change the value of mailnews.reply_header_originalmessage
2. restart mozilla to changes take efect
3. click in forward to forward an email
4. the first line continues --------- Original Message -----------

Actual Results:  
the first line continues --------- Original Message -----------

Expected Results:  
first line should to be my string defined in the prefs

excuse, but I am brazilian portuguese, then the english is not so good.
The value of this pref is not a string but a URI to a .properties file
containing the string in question.  Setting it to a non-URI string makes us fall
back to a hardcoded value at

What exactly gave you the idea that setting this pref to some string would do
something useful?
Maybe the reason he thought that was that the default value for that preference 
  -------- Original Message --------

It seems pretty reasonable to me to assume that's the string that will be 
That's an about:config bug...  The default value isn't that string.
Hmmm... that's how localized prefs should work...
The value you get for a localized pref when you get the pref (as a localized
pref) should be a string.  But setting a localized pref to a string can't
possibly work...
The localization should only apply when retrieving the default preference.

But in fact forwarding inline doesn't use this preference (in fact nobody uses
it, so why there's code for it is unclear). Forward inline actually uses
Product: MailNews → Core
*** Bug 214351 has been marked as a duplicate of this bug. ***
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Closed: 15 years ago
Resolution: --- → EXPIRED
Duplicate of this bug: 392815
Product: Core → MailNews Core
I know that after three years of RESO EXPI there's little chance of seeing this bug worked on, yet it seems a shame to me that such a pref has no effect. Let's try REOPENING the bug with lowered severity.

I agree with comment #6, that setting a "user set" value ought to override localization.
Assignee: sspitzer → nobody
Severity: normal → trivial
OS: Windows XP → All
QA Contact: esther → composition
Hardware: x86 → All
Resolution: EXPIRED → ---
P.S. In addition to forward-inline, maybe top-posting, when enabled by another, Boolean, pref, should also use this setting. (Or maybe not.)
Basically, I think we should remove code and pref if it's not even used.
And I don't think it's useful to fix it, what we actually should do is wiring composition to customizables templates (there's a bug somewhere on that, I seem to remember).
It's not unused, it's just not obvious what it does just by looking at prefnames in about:config (which isn't exactly a condemnation of the prefnames, since making them completely self-documenting is neither possible nor a design goal).

This bug is reporting that changing the pref doesn't change what's used in inline forwards, which is why I'm resolving it invalid: it doesn't, and doesn't intend to. As Neil said five years ago, there is no pref which does. I doubt that Roberto is the only person to ever want what he really should have filed, "I want to be able to change the '--- Original Message ---' string when I forward inline," so I strongly suspect there's already a bug asking for that; if not, someone who wants it should file a new one, because this bug has been around too many corners to be useful for that anymore.

However, Neil was wrong about mailnews.reply_header_originalmessage being unused; it's just rather obscure. You have five choices for mailnews.reply_header_type: 2, the default in Tb, gives "On date, author wrote:", 3 gives "author wrote, On date:" for camelCase lovers, 1, the default in SM, gives "author wrote:", 4 is an unimplemented user-defined case that may finally be implemented in bug 107884 someday but is currently the same as 1, and 0 is the reason this pref is not unused. Despite mailnews.js claiming that 0=no header, in fact 0=mailnews.reply_header_originalmessage: change mailnews.reply_header_type to 0 and leave mailnews.reply_header_originalmessage at the default value, and you get the localized string from at the top of the quote in replies, change mailnews.reply_header_originalmessage to the string "----- Foopy Goats -----" and you get that instead.
Closed: 15 years ago12 years ago
Resolution: --- → INVALID
(In reply to comment #14)
> However, Neil was wrong about mailnews.reply_header_originalmessage being
> unused; it's just rather obscure. ... Despite mailnews.js claiming that
> 0=no header, in fact 0=mailnews.reply_header_originalmessage [for replies]

I'm wondering if this was actually intended, see discussion in bug 479626.
There is a similar bug 621264 which was resolved with fix.
Duplicate of bug: 621264
You need to log in before you can comment on or make changes to this bug.