Closed Bug 350314 Opened 18 years ago Closed 15 years ago

STARTTLS is called TLS in user preferences (remaining IMAP/POP3 case)

Categories

(Thunderbird :: Preferences, defect, P2)

defect

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.0b2

People

(Reporter: tokul, Assigned: mkmelin)

References

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20060629 Firefox/1.0.4 (Debian package 1.0.4-2sarge9)
Build Identifier: Thunderbird 1.5.0.5 (20060719)

User preferences can control use of SMTP, IMAP or POP3 STARTTLS extensions, but STARTTLS is called TLS in preferences.

Transport Layer Security (TLS) is cryptographic protocol which provides secure communications on the Internet. It is the successor to SSL v.3.0 protocol.

STARTTLS is a special extension to standard plain text communication protocols. STARTTLS extensions offer a way to upgrade to TLS from a plaintext connection, rather than use a separate port for encrypted communications.


Reproducible: Always
(In reply to comment #0)
SMTP part is apparently DUP of Bug 185662.

Sorry but I don't know spec of "STLS" well. But I think that "Use secure connection: TLS" is not technically incorrect because TLS is used after STLS is issued(if negotiation successfull though), although I absolutely agree with you on that current UI is unclear.
(Q1) What wording in UI is correct when POP3 or IMAP?

Since space in UI is limited, technically correct descrition in UI is impossible, and patch for Bug 185662 propose detailed descrition in Help document for SMTP.
(Q2) Can you propose correct and detailed description for TLS/SSL use on POP3 and IMAP?

By the way, please note that Thunderbird still doesn't contain Help document.
Mail relared help document is available on Mozilla/SeaMonkey only. Then even if help document will be improved, there is no official way to explain it to Thunderbird users...
cc-ing to kaie, because owner of Bug 185662.
IMAP and POP3 STARTTLS extensions are defined in RFC 2595. POP3 uses STLS name instead of STARTTLS, because according to RFC 1939 commands must use 3 or 4 chars. IMAP and POP3 STARTTLS extensions are similar to SMTP STARTTLS. IMAP/POP3 client should issue command that starts TLS negotiations on plain text connection, read possitive reply from server and then client should try starting TLS.

Issue might be dublicate of 185662. But 185662 complains only about SMTP. Same terms are used in IMAP/POP3.

I only ask to stop confusing TLS with STARTTLS. TLS connection is connection that uses TLS on dedicated IMAP, SMTP or POP3 port. Connection is secured when client connects. STARTTLS is used on standard plain text IMAP, SMTP or POP3 port. Connection is secured on after client issue appropriate STARTTLS command and TLS negotiations are successful.

When option says TLS, I expect that program will use separate port and can talk to server secured with TLS or SSLv3.


*** This bug has been marked as a duplicate of 185662 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
(In reply to comment #3)
> Issue might be dublicate of 185662. But 185662 complains only about SMTP. Same
> terms are used in IMAP/POP3.

Reopening to clarify about IMAP/PO3 case.
For SMTP, Bug 185662 fixes problem, and it becomes clear. But when IMAP/POP3, UI is still unclear for me.
Questions: 
What is current meaning of "TLS" and "SSL" in UI for IMAP/POP3?
"TLS" is IMAP and POP3 STARTTLS extensions(STLS) which is defined in RFC 2595?
"SSL" is "IMAP over SSL" and "POP3 over SSL"?


Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
CC-ing to Nelson Bolyard (comment poster of Bug 185662 Comment #7 and Bug 368611 Comment #1).
What is "should be" when IMAP/POP3 UI?  
(In reply to comment #4)
> What is current meaning of "TLS" and "SSL" in UI for IMAP/POP3?
> "TLS" is IMAP and POP3 STARTTLS extensions(STLS) which is defined in RFC 2595?

yes

> "SSL" is "IMAP over SSL" and "POP3 over SSL"?

yes
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: STARTTLS is called TLS in user preferences → STARTTLS is called TLS in user preferences (remaining IMAP/POP3 case)
(In reply to comment #5)
> CC-ing to Nelson Bolyard (comment poster of Bug 185662 Comment #7 and Bug
> 368611 Comment #1).
> What is "should be" when IMAP/POP3 UI?  

Sorry, I don't understand that question.  

The choices we're giving people here concern these things:
a) whether they're going to attempt to use SSL/TLS, or not,  and
b) whether they want to INSIST that SSL/TLS succeed (or alternatively, 
   if it's OK to proceed without encryption if SSL/TLS fails),  and
c) Where in the phases of the relevant IMAP/POP3 protocol they want the 
   SSL/TLS handshake to be performed, and
d) the TCP port number to use for IMAP/POP3.  

Regarding item c ("Where in the phases of the relevant IMAP/POP3 protocol 
they want the SSL/TLS handshake to be performed"), the choices are: 

c1) To use SSL/TLS first, before starting to speak either IMAP or POP3,
on a TCP port that ALWAYS does SSL/TLS before IMAP or POP3.  This choice
is known as IMAP-over-SSL or POP3-over-SSL, more commonly abbreviated as
IMAPS or POP3S.  The successful completion of SSL/TLS handshake is always 
required for this mode.  If the handshake fails, the connection fails; or 

c2) To use the ordinary IMAP or POP3 TCP port, and start by talking the
IMAP or POP3 protocol, and then, in the middle of the IMAP/POP3 protocol,
to ask the server if it will support SSL/TLS, and if so, to begin to use
it at that time, in the middle of the IMAP/POP3 protocol.  This method is
known as "StartTLS".  StartTLS may report that the server does not support 
TLS, in which case the client must decide whether to continue without 
SSL/TLS encryption, or stop and fail at that point.  That is the difference
between the choices "STARTTLS" and "STARTTLS (if available)".  The latter of
those two continues if SSL/TLS is not available.  The former does not.

Note that NONE of these choices is a choice between using SSL or using TLS.
ALL 3 choices (that enable SSL/TLS in some way) enable both SSL and TLS 
equally.  The choices that involve "STARTTLS" are capable of starting 
either SSL or TLS, but the mechanism by which they do so is named "STARTTLS"
whether it starts SSL or starts TLS.  That was the chief problem with the
old choice labels.  They made it appear that we were asking them to choose
between SSL and TLS, which we were not.  

So the choices are:

security setting
---------------------   --------------------------------------------------                      
NONE                    normal port, don't try SSL/TLS at all
STARTTLS                normal port, use STARTTLS to negotiate SSL/TLS in 
                        the IMAP/POP protocol, fail if SSL/TLS not enabled.
STARTTLS (if available) normal port, use STARTTLS to negotiate SSL/TLS in 
                        the IMAP/POP protocol, continue without SSL/TLS if 
                        it's not enabled.
XXXX-over-SSL/TLS       Use special IMAP-over-SSL port or POP3-over-SSL port.
(IMAPS, POP3S)          Use SSL/TLS at the beginning of the connection, 
                        before starting IMAP or POP3.  Fail if SSL/TLS 
                        is not successful.
(In reply to comment #7)
> > What is "should be" when IMAP/POP3 UI?  
> Sorry, I don't understand that question.  

Oh sorry for my unclear question, and thanks for clear/detailed explanation.
I think explanation like your comment #7 is required in Help of Seamonkey and MozillaZine Knowledge Base for Tb users.
Is there any plan?

By the way, another concern arose in my head on POP3 UI.
  Mismatch between "StartTLS" of extension name and "STLS" of command name
If "StartTLS", someone will say "This is wrong. Command is STLS", and if "STLS", someone will say "Different from SMTP and IMAP UI"...
(In reply to comment #8)
> (In reply to comment #7)
> > > What is "should be" when IMAP/POP3 UI?  
> > Sorry, I don't understand that question.  
> 
> Oh sorry for my unclear question, and thanks for clear/detailed explanation.
> I think explanation like your comment #7 is required in Help of Seamonkey and
> MozillaZine Knowledge Base for Tb users.
> Is there any plan?
> 
> By the way, another concern arose in my head on POP3 UI.
>   Mismatch between "StartTLS" of extension name and "STLS" of command name
> If "StartTLS", someone will say "This is wrong. Command is STLS", and if
> "STLS", someone will say "Different from SMTP and IMAP UI"...

If person knows that POP3 StartTLS extension uses STLS command, he or she should know POP3 (rfc 1939) protocol limitations. Keywords use 3 or 4 characters.

So does anything argue against the naming analogue to the one for SMTP? Only thing could be the needed space which suggests XXXXS over XXXX-over-SSL/TLS.
Regarding comments 8 and 9,
RFC 2595 defines the "STARTTLS extension for IMAP, POP3 and ACAP".   
The extension is defined with different "commands" in the different protocols,
but "STARTTLS" is the name of the feature in all cases.

Assignee: mscott → nobody
OS: Linux → All
Hardware: PC → All
Looks like it's still TLS vs. SSL in v2.0.0.12. In all IMAP, POP3 and SMTP settings.

Why not just get rid of all of this confusion and replace it with an easy to use checkbox:

[ ] Require encrypted connection (SSL/TLS).

(with perhaps an Advanced button showing all the possible options if someone really wants them)

I've written more about it in http://imapwiki.org/ClientImplementation/Connect, but the "require SSL/TLS" implementation would be basically:

If this box is checked, the client would initially figure out how to perform the encryption and then cache it for later use. If it ever fails to connect, it could do this check all over again in case server configuration had changed.

1. Connect to port 143. Wait one second (or so) for the connection to establish.
2. If 143 didn't answer soon enough, connect to port 993 (without killing the 143 connection).
3. If connection to port 993 succeeded but port 143 didn't, use 993.
4. If connection to port 143 succeeds (even if 993 connection was already started), look for STARTTLS in CAPABILITY
  - If you see STARTTLS in capabilities, execute it. If it succeeds, use 143.
  - If there is no STARTTLS capability, connect to port 993. If it succeeds, use it.
  - If there is no STARTTLS capability and port 993 doesn't answer, fail.
Having AN ADDITIONAL feature that figures out the best security mode, and then
remembers it going forward seems like a good enhancement, but it's important
that, whether we find that best mode by some automatic means, or whether the 
user enters it manually, it must be clearly and unambiguously identified.

The difference between using a port that always starts with SSL/TLS first
(such as port 993) vs a port that starts with unencrypted IMAP or POP3, and 
then attempts to negotiate the use of SSL3/TLS (which is known as STARTTLS
or STLS) may be an important distinction, especially when STARTTLS can fail
and leave the user with unencrypted connections).  So, it's important that
the configured mode be clear about what it's using.

While finding a secure method automatically by trial-and-error may work 
as a discovery mechanism, it's too inefficient to be a setting that is 
used repeatedly.  So, when trial and error is used, once it figures out
what works, it should switch to use that mode repeatedly thereafter, 
without needing to repeat the trial and error.  This is called being a 
good network citizen.
The broader issue here is that there are 4 different ways to configure 
an IMAP or SMTP or POP3 client to use SSL when talking to the server.
Some pairs of these ways differ in many respects.  
Other pairs have only subtle differences.  
The fact that we present this choice to the user as a set of radio buttons,
all on a single line, means that the labels for those buttons must be very 
short and concise.

The immediate problem is: the present labels are meaningless to most users.

We need a concise way to label the radio buttons so that users can understand
their choices and have a chance of choosing the one they really want.  

The labels used in TB1 were just wrong.  They used terms to distinguish the 
choices that did not correctly identify the choices AT ALL.  They used the 
wrong terms, terms that did not distinguish the choices AT ALL.  They were
so wrong that someone who actually understood the choices could not figure
out which radio button corresponded to which actual choice.  :(

The choices I suggested in comment 7 above are technically accurate and 
descriptive of the real choices.  Someone who actually understands the 
different choices will understand those labels, and will be able to figure 
out which button to use for the choice he has in mind.  But I'll be the 
first to admin that the average mail user will think those labels are 
written in dwarvish.  

Maybe the answer is to get rid of radio buttons, or to put each button on 
a line by itself so that the labels can be longer.  

I think part of the problem is that we're trying to describe the differences
without resorting to port numbers, because the port numbers are configurable
independently of the flavor of SSL/TLS negotiation being used.  We've been
trying to find labels that make sense to the guy whose mail service provider
runs on odd-ball port numbers.  But that's some infinitesimally tiny fraction
of the users.  

For most users, the 4 choices are:

a) don't use SSL/TLS at all.  Use the "normal" port for IMAP or POP3 or SMTP.

b) Use the "normal" port for IMAP or POP3 or SMTP, but try to negotiate the
use of SSL/TLS over it.  This uses the feature of IMAP, POP3 or SMTP, by which
the protocol starts, and THEN tries to negotate the use of SSL/TLS.  That feature is known as "STARTTLS".  If the server doesn't support SSL/TLS via STARTTLS on that port, this option will go ahead and proceed without using SSL/TLS.  (This is evil, IMO, and I'd prefer we drop this option.)

c) This is the same choice as "b" above, except that if the server doesn't 
support SSL/TLS via STARTTLS on that port, stop right there and fail.

d) Use the "special" SSL/TLS port for IMAP or POP3 or SMTP, the port that 
does SSL/TLS *FIRST*, and after the SSL/TLS handshake is done, only then does
it start to speak the IMAP/POP3/SMTP protocol.  If the SSL/TLS protocol fails
then it never starts the IMAP/POP3/SMTP protocol, and the operation fails.  

(Note that most users don't know what TLS is, which is why the term "TLS" 
was incorrectly used in TB1 to name choices b and c above.

For most users, the choices they care about (as they perceive them) are:
1) Don't use SSL at all, use the normal email port
2) Use SSL on the normal email protocol port
3) Use SSL on the special SSL email protocol port

Somehow, that last, simplest message is what we need to say to users. 
I doubt we can say it with one word labels.
Why was that "use STARTTLS if available" feature added in the first place? Is it actually useful for someone, or was it added just because some other clients had it? So I agree with Nelson, it's an evil option that shouldn't be visible to normal users.

As for those 3 other options, I still think it would be best to use a checkbox that executes automatic detection of how to connect to the server. But a short term label fix could be maybe:

 * Never
 * STARTTLS
 * SSL port
(In reply to comment #14)
> I doubt we can say it with one word labels.
FYI.
AFAIR, UI change work is in progress for this setting, change from "radio button" to "selection box" style. If it'll finish, longer description than current can be used. (but probably some words and still not long enough)
Sorry but I can' recall bug number for the UI change work.
I could reach bug for the UI change work again. It was Bug 326076. String change(explanation in some words) in patch for Bug 326076 can be a quick / short term solution of this bug.
Flags: wanted-thunderbird3?
This bug is not trivial.  It may be trivial to fix, but its impact on the 
community of users who try to use SSL with POP,IMAP,SMTP,etc. and get 
terribly confused by the bad labels, is major.  So, I'll split the difference
and make it "normal".
Severity: trivial → normal
Flags: wanted-thunderbird3?
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Assignee: nobody → mkmelin+mozilla
wanted for b2, since it's a ui change.
Priority: -- → P2
Target Milestone: --- → Thunderbird 3.0b2
Yeah, we should fix this.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
I don't think we're going to get this for b1
Target Milestone: Thunderbird 3.0b1 → Thunderbird 3.0b2
Attached patch proposed fix (obsolete) — Splinter Review
Fix POP/IMAP, make it a dropdown list (otherwise gets a bit wide), and sync SMTP to use the same style.

FWIW, this is similar to what Nokia phones use in their email connection security settings too. Will attach a screenshot in a moment.
Attachment #356421 - Flags: ui-review?(clarkbw)
Attachment #356421 - Flags: superreview?(neil)
Attachment #356421 - Flags: review?(jminta)
Attached image proposed fix screenshot
Status: NEW → ASSIGNED
Is there a separate bug for the removal of the "STARTTLS, if available" option from the UI everyone agreed on, because it allows MITM attacks?

http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/32400c5d823d61dc/40fc9848a6ede163?hl=de&lnk=gst&q=TLS%2C+if+available#40fc9848a6ede163

Or to remove the "Never" option and relabel "STARTTLS, if available" to "Unsecure"?
Nice, this fixes bug 281642 too.
I don't think there's a bug for removing it, but yes we should. Feel free to open one. If we can use the auto-discovery/probing stuff once it lands, allowing us to do a one time move over for users who have it set would be best. If we don't get that in, we could of course just downgrade them to "None"...

Anyway, i'd like to keep this bug fucussed on fixing the labels. Moving/removing can be easier done as a follow up. (The suggested ones work just as well after such a removal.)
FWIW, we didn't agree on removing the options (although I'd be fine with removing the "Never" option), but renaming them to:

> Use secure connection:
> ( ) Never (o) Insecure ( ) SSL ( ) TLS
> where "Insecure" is the former "TLS if available". 

I think this could be done in this bug.
The bug asks to stop using term TLS for connection which uses STARTTLS. It does not discuss security of "STARTTLS if available" option.
Exactly, this bug is mainly about the TLS term misuse. Our current "SSL" is TLS in many cases (most, even?) I'd assume.
I thought that both should be done in one swoop, given these labels are changed anyways, and both are just about the labels, but whatever Magnus prefers. Update: Magnus just said he prefers a new bug, so I filed bug 473080.

Based on reading the bug, I now recommend:
> Use encrypted connection:
> ( ) Never (o) Insecure ( ) STARTTLS (on normal port) ( ) SSL/TLS (on SSL port)
> where "Insecure" is the former "TLS if available". 

I understand that you are space-restricted, but if you just say "STARTTLS" and "SSL/TLS", almost nobody will know what exactly the difference is.
Code: If you keep the foo-<n>.label entity names, can you please at least make comments in the XUL file to show what they mean? Otherwise, I'd need to open the locale file just to understand the pref meaning.
(In reply to comment #30)
> I understand that you are space-restricted, but if you just say "STARTTLS" and
> "SSL/TLS", almost nobody will know what exactly the difference is.

I'd assume a professional would, and these are not labels *users* need to fully understand - they should just tick whatever their admins tell them, if the don't their setup won't likely work. Having "None" as the first option should make it clear the others are using some security mechanism.
> I'd assume a professional would

No, I think that even most professionals will not precisely understand the difference. Given that the main reason for STARTTLS vs SSL/TLS is the port, I think it's helpful to have that in there.

> they should just tick whatever their admins tell them

That's part of the problem: We change the labels here, so if the admin told them "check TLS" (because that's what STARTTLS is in TB2 and the instructions have not been updated - esp. ISPs are notorious), they'll check the wrong option, namely "SSL/TLS" in the new UI, which is not STARTTLS and will not work.
Since everyone else seems to be, I'll just throw my suggestions in too ;-)

* No encryption
* Request STARTTLS (obsolete)
* Require STARTTLS (secure)
* Require SSL (secure)
If we get that bug regarding icons in menulists fixed, we could provide lock icons for the secure connection types :-)
Comment on attachment 356421 [details] [diff] [review]
proposed fix

>   <groupbox hidefor="movemail">
>     <caption label="&securitySettings.label;"/>
>+    <hbox align="center" hidefor="movemail">
Heh, if we're hiding the groupbox we hardly need to hide this too ;-)

>+      this.mBundle.getString("smtpConnectionSecurityType-" + aServer.trySSL);
I think this should probably be smtpServer-ConnectionType- for consistency.

>+              <label id="useSecureConnectionLabel" value="&connectionSecurity.label;"
It's confusing if a label uses entities that don't match its id, although it probably isn't using the id in this case.

>+          <menulist id="smtp.trySSL" oncommand="selectProtocol(false);"
Fix the other caller too perhaps?

>-<!ENTITY neverSecure.label "Never">
>-<!ENTITY neverSecure.accesskey "N">
>-<!ENTITY sometimesSecure.label "TLS, if available">
>-<!ENTITY sometimesSecure.accesskey "a">
>-<!ENTITY alwaysSecure.label "TLS">
>-<!ENTITY alwaysSecure.accesskey "T">
>-<!ENTITY alwaysSSL.label "SSL">
>-<!ENTITY alwaysSSL.accesskey "L">

>+<!ENTITY connectionSecurity.label "Connection security:">
>+<!ENTITY connectionSecurity.accesskey "N">
"N" conflicts with User Name. ("N"ever was wrong too.)

>+<!ENTITY connectionSecurityType-0.label "None">
>+<!ENTITY connectionSecurityType-1.label "STARTTLS, if available">
>+<!ENTITY connectionSecurityType-2.label "STARTTLS">
>+<!ENTITY connectionSecurityType-3.label "SSL/TLS">
It's bad enough having to rename these days when you do change the wording... as you're not changing the wording here it just seems silly.
(In reply to comment #33)
> > I'd assume a professional would
> 
> No, I think that even most professionals will not precisely understand the
> difference. Given that the main reason for STARTTLS vs SSL/TLS is the port, I
> think it's helpful to have that in there.

There's no requirement for it to be "on the normal port". It's just the default.

> > they should just tick whatever their admins tell them
> 
> That's part of the problem: We change the labels here, so if the admin told
> them "check TLS" (because that's what STARTTLS is in TB2 and the instructions
> have not been updated - esp. ISPs are notorious), they'll check the wrong
> option, namely "SSL/TLS" in the new UI, which is not STARTTLS and will not
> work.

I don't see how stating port numbers would help if users look at an old guide. If you mean support people, they'll just have to know.
Comment on attachment 356421 [details] [diff] [review]
proposed fix

While this isn't an improvement in user experience, it does seem to be an improvement in clarity; which is a clear step forward.  

I hope we can finish the rest of this work before release.
Attachment #356421 - Flags: ui-review?(clarkbw) → ui-review+
(In reply to comment #23)
> proposed fix screenshot

I think reversed order is better(most secure top, most insecure bottom).
> SSL/TLS
> STARTTLS
> STARTTLS, if avail
> None
Magnus, what do you think? (sorry for late question after review) 

By the way, your patch will automatically change Bug 326076 to FIXED status?
I thought about it, but I think there is some slight value in keeping the same order, in case user's have old instructions on how to set up their account.

So, my plan is to update the patch, make the "if available" option show only if the user has it set already. For all other users it would never show up in the UI. Should be a pretty easy way out from a hard UI problem...
Attachment #356421 - Flags: superreview?(neil)
Attachment #356421 - Flags: review?(jminta)
> I thought about it, but I think there is some slight value in keeping the same
> order, in case user's have old instructions on how to set up their account.

Yes, I think at the point of this option dialog users shouldn't really be making their choice by the order of security level.

> So, my plan is to update the patch, make the "if available" option show only if
> the user has it set already. For all other users it would never show up in the
> UI. Should be a pretty easy way out from a hard UI problem...

This sounds good.  A consequence of this design is that a person could see "if available", click ( OK ) and then come back to the same dialog and "if available" would be gone.  An experience I think is acceptable.
Magnus: friendly nudge. do you have an update to the patch?
(In reply to comment #36)
> >+<!ENTITY connectionSecurityType-0.label "None">
> >+<!ENTITY connectionSecurityType-1.label "STARTTLS, if available">
> >+<!ENTITY connectionSecurityType-2.label "STARTTLS">
> >+<!ENTITY connectionSecurityType-3.label "SSL/TLS">
> It's bad enough having to rename these days when you do change the wording...
> as you're not changing the wording here it just seems silly.

I'm changing one, so for consistency...
Attached patch proposed fix, v2Splinter Review
Carrying fwd ui-r=clarkbw (from previous patch and comments)

This hides the "if available" option for accounts that don't have it already. Otherwise it looks like the previous one.

About the impl: I suppose I could also give the option an id and access it directly...
Attachment #356421 - Attachment is obsolete: true
Attachment #358255 - Flags: ui-review+
Attachment #358255 - Flags: superreview?(neil)
Attachment #358255 - Flags: review?(jminta)
Comment on attachment 358255 [details] [diff] [review]
proposed fix, v2

These probably don't need to be their own function, since they're only called once.
Attachment #358255 - Flags: review?(jminta) → review+
Comment on attachment 358255 [details] [diff] [review]
proposed fix, v2

>+  var hidden = (document.getElementById("server.socketType").value !=
>+                Components.interfaces.nsIMsgIncomingServer.tryTLS);
>+  var popup = document.getElementById("server.socketTypePopup");
>+  popup.getElementsByAttribute("value", Components.interfaces.nsIMsgIncomingServer.tryTLS)[0]
>+       .setAttribute("hidden", hidden);
Give the menuitem an id, and then use
document.getElementById("connectionSecurityType-1").hidden = hidden;
(Or possibly inline it all into one line, but maybe that's a bit much.)

>+          <menuitem value="1" label="&connectionSecurityType-1.label;"
>+                    disabled="true" hidefor="nntp"/>
Remove the hidefor="nntp" because you're manually controlling its visibility now. (NNTP servers have never supported a security type of 1 anyway.)

Same goes for SMTP edit, of course. sr=me with these fixed.
Attachment #358255 - Flags: superreview?(neil) → superreview+
Patch for checkin, review comments addressed. I found a minor bug wrt smtp auth type (was changing the value when didn't mean to) which I also fixed.
changeset:   1762:63dbe60ea7df
http://hg.mozilla.org/comm-central/rev/63dbe60ea7df

->FIXED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago15 years ago
Resolution: --- → FIXED
Blocks: 281642
Blocks: 326076
You need to log in before you can comment on or make changes to this bug.