Set SSL info when an HTTP auth dialog is triggered by direct navigation.

chrome/browser/ui/login/login_prompt.cc

Index: chrome/browser/ui/login/login_prompt.cc
diff --git a/chrome/browser/ui/login/login_prompt.cc b/chrome/browser/ui/login/login_prompt.cc
index 8051d83138dad0e8f008a3f5163e32310c236cce..985f36c9ed1d27d4d587764346c99e67585c551b 100644
--- a/chrome/browser/ui/login/login_prompt.cc
+++ b/chrome/browser/ui/login/login_prompt.cc
@@ -26,16 +26,20 @@
 #include "components/password_manager/core/browser/password_manager.h"
 #include "components/url_formatter/elide_url.h"
 #include "content/public/browser/browser_thread.h"
+#include "content/public/browser/navigation_entry.h"
 #include "content/public/browser/notification_registrar.h"
 #include "content/public/browser/notification_service.h"
 #include "content/public/browser/render_frame_host.h"
 #include "content/public/browser/resource_dispatcher_host.h"
 #include "content/public/browser/resource_request_info.h"
 #include "content/public/browser/web_contents.h"
+#include "content/public/common/ssl_status.h"
+#include "grit/generated_resources.h"
 #include "net/base/auth.h"
 #include "net/base/load_flags.h"
 #include "net/base/net_util.h"
 #include "net/http/http_transaction_factory.h"
+#include "net/ssl/ssl_info.h"
 #include "net/url_request/url_request.h"
 #include "net/url_request/url_request_context.h"
 #include "ui/base/l10n/l10n_util.h"
@@ -581,10 +585,24 @@ void LoginDialogCallback(const GURL& request_url,
                                         request_url,
                                         make_scoped_refptr(auth_info),
                                         make_scoped_refptr(handler));
+    // TODO(palmer, creis, meacer): Explain why this is safe. It is safe if:
+    //
+    // 1) Browser initiated navigations will always start with a pending entry,
+    // but it may get discarded or replaced before the navigation commits. When
+    // does this call happen? (It may be possible for the pending entry to be
+    // gone by now, which might have been why we couldn't use it.)

[Charlie Reis, 2015/09/29 22:52:11]

Following the trail in codesearch, it looks like LoginDialogCallback is a task
posted to the UI thread via a long chain starting in
ResourceLoader::OnAuthRequired.

That means it's definitely possible for the pending entry to have been discarded
or even replaced for a different navigation by the time we get here.  As a
result, I don't think it's safe to use GetPendingEntry below, at least in the
general case.  

(Some examples that come to mind: the user has just clicked Stop, or the
renderer process initiates a new same-process main frame navigation, or the
renderer process initiates a cross-process subframe navigation.)

Suppose we found a way to check whether the pending entry still matched this
particular request (though I'm not sure yet if that's possible).  How should the
code below behave if there is no pending entry or if it doesn't match?

+    //
+    // 2) Renderer initiated navigations in the main frame will have a pending
+    // entry if they make a network request, but it can get discarded as above.
+    //
+    // 3) Renderer initiated navigations in subframes will not have pending
+    // entries. Can they cause an auth dialog?
+    content::NavigationEntry* pending_entry =
+        parent_contents->GetController().GetPendingEntry();
+    const content::SSLStatus& ssl_status = pending_entry->GetSSL();
     // This is owned by the interstitial it creates. It cancels any existing
     // interstitial.
-    new LoginInterstitialDelegate(parent_contents,
-                                  request_url,
+    new LoginInterstitialDelegate(parent_contents, request_url, ssl_status,
                                   callback);
   } else {
     ShowLoginPrompt(request_url,