It would be good to add a new prefrence to Thunderbird chat, to control whether OTR for chat is enabled or disabled. We can start by having it disabled by default. This preference can help us to add portions from bug 954310 in stages, and allow us to enable it easily in test environments. Once stable, the preference can be used to disable it, if users have any issues with it. So, having the pref should be useful in general.

Comment on attachment 9034720 [details] [diff] [review] chatpref.patch Review of attachment 9034720 [details] [diff] [review]: ----------------------------------------------------------------- Perhaps make it true for #if defined(NIGHTLY_BUILD)

Is this really just a boolean? From what I remember there were 3 states of OTR enabledness: 1. Disabled. 2. Opportunistically enabled (which is a sane default. It adds some whitespace to the first message to detect the presence of OTR on the other side, and then turn on encryption without user action) 3. Require encryption. Or is this pref about hiding the UI rather than about enabling encryption?

This pref is for "enable the code". This pref would allow us to check in JS code (soon), that enables the UI, and hooks up the library processing (route messages through the OTR library for encrypt/decrypt, if compatible with the peer). However, that code won't work on most systems. Because initially, most users wouldn't have the required external libraries yet. That would be separate steps of work. I don't want to set this pref to true in nightly yet, because it wouldn't work without having the libraries. All other behavior choices could get separate prefs, after agreed on. So, this pref is really just something to get us started. It could allow users, who manually prepare their system (download required libraries) to turn on the feature for testing. The "enable for nightly" is a good idea for a later time, until we're sure that nightly builds should work out of the box. So, I thought, having this pref is a simple thing to do. If you're worried that the pref isn't the right thing to do, I'd have to restrict everying to local work, until after thing work in an initial state, on all platforms.

Sure, landing pref'ed off is fine :-).

If you prefer that we have more options for the future, I'm OK to make it an integer pref, 0 = off, 1+ = on, with values >= 2 reserverd for future use.

Please r+ the patch you prefer.

I don't see an issue with this, but it is a little odd to add a pref that doesn't do anything. Did you see Magnus' question in comment 2?

The pref will be used once I check in code for OTR. I want to agree on the name and style of the pref, so I can use it in the new code acoordingly.