334053 - In prefs about reply headers, some sequences beginning with % give anomalous results

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[intendentedelleacque]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

If you set the pref, for example, "mailnews.reply_header_authorwrote" equal to "%d", when you reply you'll have in the header a random (?) hexadecimal (?) number, that seems to change everytime. 
I found many sequences that give similar results, surely %d %e %f %g %o, while other sequences have a regoular behaviour (for ex. %a %y).
A particular case is the sequence %S that gives a long series of asian chars.
The same happens with "mailnews.reply_header_ondate".


Reproducible: Always

Steps to Reproduce:
1. set the pref "mailnews.reply_header_authorwrote" equal to "%d"
2. reply a message

Actual Results:  
1. you'll have in the reply header something like 165262100

Expected Results:  
1. you should have "%d"

Tested on TB 1.5, on Linux and win XP

Comment 1

[Mike Cowperthwaite]

This may not be ideal, but it makes sense.  Those two headers normally use %s, which indicates that the %s should be subsitituted by the authorname or date, *as a string* -- this is a standard format in programming.  By the same token, those other sequences also work as substitutions, but as numerical values.

If you really want to see  %d   in the string, set the pref to  %%d   -- double-% is substituted by a single %, always.

Comment 2

[:aceman]

Yes, those % sequences are special for nsTextFormatter::smprintf which processes those strings.
I plan to remove nsTextFormatter::smprintf processing in bug 995797 so %d (etc) should stay untouched.

Please close this as FIXED when bug 995797 is fixed with removal of smprintf.

Comment 3

[:aceman]

Fixed by bug 995797.