Closed Bug 339600 Opened 18 years ago Closed 15 years ago

Edited options inside TB restored after restart (When mailnews.reply_header_type=3 is NOT set, change of mailnews.reply_header_xxx via Config Editor is reset by restart of Tb)

Categories

(Thunderbird :: Preferences, defect)

x86
Windows 98
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: arkady.belousov, Unassigned)

Details

(Keywords: qawanted, Whiteboard: closeme 2009-08-10)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows 98; ru) Opera 8.54
Build Identifier: http://mozilla.mirrors.tds.net/pub/mozilla.org/thunderbird/releases/1.5.0.2/win32/ru/Thunderbird%20Setup%201.5.0.2.exe

I try to tune answered letters header, but this change works only until TB is restarted.

Reproducible: Always

Steps to Reproduce:
1. Tools / Options / Advanced / General / Options editor.
2. Double click on mailnews.reply_header_authorwrite.
3. Enter new contents (for example, "Hi!\n%s wrote:".
4. Close editor (click on X in window top-right corner)
5. Answer to some letter. Result (with empty lines before and no line break inside - this is wrong, but this is another story):


Hi!\nArkady V.Belousov wrote:
6. Restart TB.
7. Answer some letter. Result: old/standard header.
I think the problem here is: you have to click OK, or else switch to a 
different tab, in order for the changes to take effect.  Clicking the [X] is 
the same as clicking Cancel.
> I think the problem here is: you have to click OK, or else switch to a 
> different tab, in order for the changes to take effect.

     There is neither Ok button (there is no buttons at all) nor other Tabs. And Editor is opened in sepatate Window. Don't know how in English version, but in Russian version this is so (also as in Help / About there is no build/OS information, beside compilation date).

> Clicking the [X] is the same as clicking Cancel.

     Then why change is in effect until TB restarted? The more so, change is seen in prefs.js (but disappear there after TB restarting).
(In reply to comment #2)
> > I think the problem here is: you have to click OK, or else switch to a 
> > different tab, in order for the changes to take effect.
> 
>      There is neither Ok button (there is no buttons at all) nor other Tabs.

Sorry, I misunderstood the problem -- my fault.

Check if you have a file in your profile "user.js" -- changes in the config editor are written out to prefs.js, but on startup user.js is also read, 
*after* prefs.js is.
> Check if you have a file in your profile "user.js" -- changes in the config
> editor are written out to prefs.js, but on startup user.js is also read, 
> *after* prefs.js is.

     There _was_ no user.js. Now it is, because me _need_ proper header, whereas default TB header (which TB can't change from itself) is not suits me.
>      There _was_ no user.js. Now it is, because me _need_ proper header,
> whereas default TB header (which TB can't change from itself) is not suits me.

     More details. See: https://bugzilla.mozilla.org/show_bug.cgi?id=339808 - this bug affect given bug with preferences. Ie., there currently is my user.js with definition for header. Now, if I double click on folder, then opens new TB window. Replying in this new windows uses user.js preferences. BUT REPLYING IN ORIGNAL TB WINDOW FORGETS USER.JS (ie. header returns to its default format).
I'm not seeing the problem of this preference getting reset.  Do you have any extensions installed?  If so, do you get the same behavior if you run TB in 
Safe Mode?  (You'll probably have to run it twice in safe mode, once to set the preference and again to check whether it's getting reset on restart.)
> I'm not seeing the problem of this preference getting reset.  

     This _is_ problem. First at all, I should restart TB to return _my_ preferences. Second, this forgetfulness may indicate serious flow in TB ideology of working with preferences.

> Do you have any extensions installed?

     Yes. Don't know how to export consequent listing from TB / Tools / Themes and Tools / Extensions, so I enumerate manually:

Themes:
Thuderbird (default) 2.0
PitchDark 1.5.6
Littlebird 1.0.28
miniBird 0.3.1 (current theme - unfortunately, default theme is too inefficient)
Walnut 1.0.29

Extensions:
Change Quote and Reply Format 0.4.6 (unfortunately, useless, also as TB possibilities)

> If so, do you get the same behavior if you run TB in Safe Mode?

     How to run in Safe Mode?

> (You'll probably have to run it twice in safe mode, once to set the
> preference and again to check whether it's getting reset on restart.)

     Do you mean, that in safe mode TB doesn't accepts user.js? If so, how to "set the preferences"?
Assignee: mscott → nobody
Reporter, does this 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)
Whiteboard: closeme 2008-09-25
Well, how it happens now. My user.js contains:

user_pref("mailnews.reply_header_authorwrote", "Hi!\n\n%s");

changing this options in options editor works only until TB restart. Because, as explained above, user.js overwrote prefs.js, its fine. Now, I comment this line in user.js - after this changes remains active after TB restart. Restoring user.js, restarting TB, making option - double clicking on folder opens new window, in which changes remains active, as (I) expect. Looks like original report processed...

...But there introduced new bug in options editor. Note: option in user.js contains "\n\n" (literally) four characters. Options editor shows this as control character. Editing option shows there two commas (",,"). I found no way to enter new line characters: typing "\n" (literally) inserts in new letter "\n" (literally), not new line character. Help in TB (in given case, with description of content of edited fields in options editor) is missing - F1 anywhere is ignored.
Correction:
1. secondary window opened not by double click, but Right click/Open.
2. Bug with "\n" handling in options editor is not newly introduced - see step 5 in description.
Keywords: qawanted
Whiteboard: closeme 2008-09-25
sticking to the original problem only ... Do you see the problem when started in safe-mode AND no user.js?
To Arkady Belousov(bug opener):  

Do you set mailnews.reply_header_type=3 which is mandatory setting to use user defined reply header?

See "Change the reply header" section of next web page. 
> http://www.mozilla.org/support/thunderbird/tips
> Change the reply header

AFAIR, Tb's behaviour is as follows. 
(1) If mailnews.reply_header_type is not 3, Tb doesn't save entries for user defined reply header data, in order to remove garbages and to reset to default.
(2) If string for reply header data is entered via Config Editor, it is used by Tb during the session, because entries are commonly used among mailnews.reply_header_type=0/1/2/3.
(3) If data is typed at UI of Config Editor, it's simply a string, although "\" is used as "escaping character for \ etc." at some places of UI.
In contrast to it, user.js setting is JavaScript source. So "\n" is converted to "LF" by JavaScript Engine. It's the trick that "\n" works as Line Feed if specified in user.js.
(The LF was displayed in "." like glyph by Config Editor in my environment)

I think you are experiencing above.
Are you requesting same escaping of special byte code by "\" as JavaScript at Config Editor UI?

Anyway, specify user defined reply header related options properly in user.js first, as instruction says.
FYI. Following Web page looks better explanation about "customizing reply heder". 
> http://www.mozilla.org/support/thunderbird/tips#beh_replyheader
Summary: Edited options inside TB restored after restart → Edited options inside TB restored after restart (If mailnews.reply_header_type=3 is not set, change of mailnews.reply_header_xxx via Config Editor is lost by restart of Tb)
Summary: Edited options inside TB restored after restart (If mailnews.reply_header_type=3 is not set, change of mailnews.reply_header_xxx via Config Editor is lost by restart of Tb) → Edited options inside TB restored after restart (If mailnews.reply_header_type=3 is NOT set, change of mailnews.reply_header_xxx via Config Editor is reset by restart of Tb)
Better explanation was following page. Sorry for my mistake in pasting and spam. 
> http://kb.mozillazine.org/Mailnews.reply_header_*
Summary: Edited options inside TB restored after restart (If mailnews.reply_header_type=3 is NOT set, change of mailnews.reply_header_xxx via Config Editor is reset by restart of Tb) → Edited options inside TB restored after restart (When mailnews.reply_header_type=3 is NOT set, change of mailnews.reply_header_xxx via Config Editor is reset by restart of Tb)
To Arkady Belousov(bug opener):

Phenomena in your all comments is one when mailnews.reply_header_type==3?
Or Phenomena when mailnews.reply_header_type!=3?

If mailnews.reply_header_type!=3, all phenomena can be explaied, except "\n via Config Editor isn't converted to Line Feed(0x0A)", and this bug has to be closed as INVALID.
But if phenomena in your all comments is one when mailnews.reply_header_type==3, further analysis is required.

Arkady Belousov((bug opener), which is your case?

Anyway, issue around "\n via Config Editor" is different from this bug's issue you reported originally. If you think "improvement is needed", open separate bug for it, please(one problem per a bug is rule at bugzilla.mozilla.org).
Reporter can you reply to comment #11 and comment #15, please?
Whiteboard: closeme-2009-08-10
Closing Incomplete for lack of answers.

Feel free to reopen if you can provide more information.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme-2009-08-10 → closeme 2009-08-10
This works fine for me in recent TB. The changed pref string sticks between TB restarts.
You need to log in before you can comment on or make changes to this bug.