Closed Bug 224811 Opened 17 years ago Closed 12 years ago
.reply _header _originalmessage pref does not work
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 http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgCompose.cpp#159 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 is: -------- Original Message -------- It seems pretty reasonable to me to assume that's the string that will be inserted.
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 http://lxr.mozilla.org/seamonkey/source/mailnews/mime/resources/mime.properties#270
*** 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: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
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
Status: RESOLVED → UNCONFIRMED
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 composeMsgs.properties at the top of the quote in replies, change mailnews.reply_header_originalmessage to the string "----- Foopy Goats -----" and you get that instead.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago → 12 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.
You need to log in before you can comment on or make changes to this bug.