Comment 10 for bug 239360

http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIURI.idl#94

I think you can construct a new URI and the current implementation will convert several types of input strings into a valid URI. See NS_NewUri for how to use io-service to construct a new one.

I think we should not "tell" the user that it's possible to paste a full URL here. I think that causes confusion for protocols other than https. If we agree this dialog shall be used as an universal dialog for any protocol, I'd recommend to talk about "site" and "port".

The port field would not be required when combined with an URL, since the URL can contain a port specification as in https://www.mozilla.org:443/. But the port field is required for any other protocols.

(If you would like to get around this dilemma, you could have a radio button that switches between "web site" and "mail or other server". When the "web site radio button" is selected, we'd have a single "URI/location" field that requires a full https://something, with or without port, with or without https. When the "mail or other server radio button" is select, we'd hide the "URI/location" field and show two separate "server and port" fields. If you go with this solution, you could even hide the "mail or other server" when compiling Firefox, but enable it for Thunderbird and SeaMonkey.)

If you want a single strategy for constructing a full URI from any of the possible input types, you could do this:

- construct URI from input field => myURI
  (will work with both simple-hostname and full-uri)
- as you're going to use xml-http-request for the test (ignoring the actual protocol), explicitly set the scheme to https using an assignment
  myURI.scheme = "https";
- if the user explicitly entered a value into the port field, assign that port number to the URI. Otherwise leave the default the URI-parsing set.
  myURI.port = dialog.port.value;

I'm not sure if "Certificate Location" is the best label. The word "location" seems to suggest we are downloading it from somewhere. With this wording, I'm worried that some people might try to enter an address like http://my-server.com/my-cert.crt (which won't work, as we are binding the exception to the port of the connection attempt).

What would you think about using "Check Certificate" or "Test Certificate" as the label for the button? Would that clarify we are not downloading, but connecting?