Steps to reproduce 1/ Within mailnews.js change the mailnews.html_domains to "foo.bar.com" ( 2/ Make sure Send Format preference is set to ask user. 3/ Compose and send an email to someone@foo.bar.com Expected result 1/ Email gets sent in HTML format Actual result 1/ User gets prompted what format to send it in.

As suggested by NeilAway on IRC, setting mailnews.html_domains to something like: chrome://messenger/locale/messenger/messenger.properties and then adding the following line to messenger.properties: mailnews.html_domains=foo.bar.com does work (also shows in preferences and about:config as foo.bar.com) Whereas setting pref("mailnews.html_domains", "data:text/plain,mailnews.html_domains=foo.bar.com"); fails and does not appear correctly in either preferences or about:config

(In reply to Ian Neal from comment #1) > As suggested by NeilAway on IRC, setting mailnews.html_domains to something > like: > chrome://messenger/locale/messenger/messenger.properties > and then adding the following line to messenger.properties: > mailnews.html_domains=foo.bar.com > does work (also shows in preferences and about:config as foo.bar.com) Actually it only shows in about:config correctly, in preferences it shows: chrome://messenger/locale/messenger/messenger.properties

(In reply to Ian Neal from comment #2) > (In reply to Ian Neal from comment #1) > > As suggested by NeilAway on IRC, setting mailnews.html_domains to something > > like: > > chrome://messenger/locale/messenger/messenger.properties > > and then adding the following line to messenger.properties: > > mailnews.html_domains=foo.bar.com > > does work (also shows in preferences and about:config as foo.bar.com) > Actually it only shows in about:config correctly, in preferences it shows: > chrome://messenger/locale/messenger/messenger.properties That would be fixed by setting the preference type in pref-formatting.xul to wstring rather than string.

(In reply to Ian Neal from comment #3) > That would be fixed by setting the preference type in pref-formatting.xul to > wstring rather than string. As far as I can tell it's been a string with an empty default value since the dawn of time, so perhaps the bug lies in nsMsgCompose where we're getting the preference as a localised string when it isn't.

This patch fixes nsMsgCompose.cpp so that mailnews.plaintext_domains and mailnews.html_domains, which are not localised prefs, are retrieved as standard strings.

Comment on attachment 785951 [details] [diff] [review] Fix nsMsgCompose.cpp to get non-localised strings for certain prefs [Checked in: Comment 9] (In reply to neil@parkwaycc.co.uk from comment #4) > As far as I can tell it's been a string with an empty default value since > the dawn of time, so perhaps the bug lies in nsMsgCompose where we're > getting the preference as a localised string when it isn't. Netscape 6 used to set pref("mail.htmldomains", "netscape.com,mcom.com"); and Netscape 7.2 had pref("mailnews.global_html_domains", "netscape.net,netscape.com,aol.com,cs.com,yahoo.com,hotmail.com,msn.com"); But I don't think we're going to become our own mail service provider anytime soon. ;-)

Comment on attachment 785951 [details] [diff] [review] Fix nsMsgCompose.cpp to get non-localised strings for certain prefs [Checked in: Comment 9] So, in theory, I agree. But I need to do a clean recompile first, because right now it doesn't work for me …

Comment on attachment 785951 [details] [diff] [review] Fix nsMsgCompose.cpp to get non-localised strings for certain prefs [Checked in: Comment 9] Okay, I kept running into bug 401014. :-/

Comment on attachment 785951 [details] [diff] [review] Fix nsMsgCompose.cpp to get non-localised strings for certain prefs [Checked in: Comment 9] http://hg.mozilla.org/comm-central/rev/2aa267dcfe36