Bug 1382359: Treat .onion as a secure context

Websites which collect passwords but don't use HTTPS start showing scary
warnings from Firefox 51 onwards and mixed context blocking has been
available even longer.

.onion sites without HTTPS support are affected as well, although their
traffic is encrypted and authenticated. This patch addresses this
shortcoming by making sure .onion sites are treated as potentially
trustworthy origins.

The secure context specification
(https://w3c.github.io/webappsec-secure-contexts/) is pretty much focused
on tying security and trustworthiness to the protocol over which domains
are accessed. However, it is not obvious why .onion sites should not be
treated as potentially trustworthy given:

"A potentially trustworthy origin is one which a user agent can
generally trust as delivering data securely.

This algorithms [sic] considers certain hosts, scheme, and origins as
potentially trustworthy, even though they might not be authenticated and
encrypted in the traditional sense."
(https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy)

We use step 8 in the algorithm to establish trustworthiness of .onion
sites by whitelisting them given the encrypted and authenticated nature
of their traffic.

dom/html/HTMLFormElement.cpp

@@ -867,6 +867,10 @@ HTMLFormElement::DoSecureToInsecureSubmitCheck(nsIURI* aActionURL,
     return NS_OK;
   }
 
+  if (nsMixedContentBlocker::IsPotentiallyTrustworthyOnion(aActionURL)) {
+    return NS_OK;
+  }
+
   nsCOMPtr<nsPIDOMWindowOuter> window = OwnerDoc()->GetWindow();
   if (!window) {
     return NS_ERROR_FAILURE;