Status

Preference Panels; default preferences; etc. For bugs that affect the Preferences window's user interface generally like "no scrollbar in category pane" use this component. Do not use this component for bugs in the content of specific preferences panes like "typo in Navigator pref pane" or "radio buttons on Composer pref pane appear uninitialized". Instead, file these sorts of bugs directly to the relevant component: use "Composer" in the last example.

Taking, but nothing has been checked in yet on the Core/PSM side (targeted for Gecko 39). This may need some migration code for people who still have SSL 3.0 enabled on purpose (if we remove the checkbox, no way for the user to uncheck it from the UI).

Thanks, good to know. Indeed, that's more a UI problem as the boxes can get into a state where you can't modify either .min (if its value is less than the allowed minimum) or .max (if its value exceeds the allowed maximum). Thus, I should probably revisit the logic here to ensure that only valid input ranges are considered to initialize the checkboxes, thus to avoid locking up the selections.

On a side note: With the term "SSL" officially retiring soon, I'm wondering if we should rename that prefpane (which I'd file a separate bug for as it would likely require widespread adjustments to labels and Help content beyond the scope of what we are doing here). On the other hand, "SSL" is a reasonably established term, and other browsers/mail programs still use it routinely.
Something like "Transport Layer Security (SSL/TLS)" sounds more clear anyway (what's a "Socket" and why does it have to be "Secure"?), or maybe "Connection Security (SSL/TLS)" would be least ambiguous (with the short panel title in the prefpane tree being "SSL/TLS" or just "Connection Security").

Created attachment 8574761[details][diff][review]
Proposed patch
This removes the allowSSL30 checkbox with respective changes to labels, logic, and Help content. The logic is extended to verify in UpdateSslBoxes() that the min/max values are in the valid range, and assumes valid min/max limits them if not; the preferences themselves aren't modified until the user actually touches any of the boxes.

Created attachment 8574850[details][diff][review]
Use a Map instead (v2)
Yeah, that works nicely and simplifies things.
(From bug 1106470attachment 8569820[details][diff][review])
> // convert min/maxFromPrefs to the internal representation
> minFromPrefs += SSL_LIBRARY_VERSION_3_0;
> maxFromPrefs += SSL_LIBRARY_VERSION_3_0;
> // if min/maxFromPrefs are invalid, use defaults
> if (minFromPrefs > maxFromPrefs ||
>- minFromPrefs < range.min || maxFromPrefs > range.max) {
>+ minFromPrefs < supported.min || maxFromPrefs > supported.max ||
>+ minFromPrefs < SSL_LIBRARY_VERSION_TLS_1_0) {
> return;
> }
I've revisited that based on comment #2. Since indeed the defaults are used when either of the conditions is met, I've modified the minVersion/maxVersion definitions used for the checkbox initialization respectively and take the defaults for both even if just one of them is outside of the valid range (also get them from the default prefbranch as they may not match the minimum/maximum values of the allowed pref settings).

(Quoting to Masatoshi Kimura [:emk] from bug 1141394)
> In bug 1106470, I intentionally left strings and idl constants
> in case we have to backout the change on beta or aurora.
> Once the SSLv3 removal reaches to release, we can cleanup them.
Shall we proceed in the same way "just in case" that the SSL 3.0 strings are needed if and when it should be decided not to let the Core changes proceed down the release train? It sure would be trivial to defer removal of those two entities for 3+ cycles after the changes have hit the releases.

Created attachment 8575034[details][diff][review]
String changes deferred (v4)
Indeed, I think we should proceed in this way given that the core changes may depend on Google timing:
(Quoting David Keeler [:keeler] from bug 1106470 comment #4)
> In general, looks good. I found more things to remove, however. Also, we
> should keep a very close eye on this. If it doesn't look like SSL 3 is going
> to be similarly removed from Chrome 44 or if that release date is not close
> enough to the release date for Firefox 39 (looks like 30 June 2015), we
> should hold this back at least one release.

Comment on attachment 8575034[details][diff][review]
String changes deferred (v4)
Sorry for the delay, my computer has been acting strangely and I just noticed that it has 360 bad sectors. (But S.M.A.R.T. says that that's fine... go figure.)