Fix the page's SSL status not being set on restore.

content/browser/frame_host/navigation_controller_impl.cc

Index: content/browser/frame_host/navigation_controller_impl.cc
diff --git a/content/browser/frame_host/navigation_controller_impl.cc b/content/browser/frame_host/navigation_controller_impl.cc
index 55c5fa41d72e6f1f435093482dd176da73f556a6..97020c8164df8e91ff1edac7a2577e00b2e20d2b 100644
--- a/content/browser/frame_host/navigation_controller_impl.cc
+++ b/content/browser/frame_host/navigation_controller_impl.cc
@@ -1186,6 +1186,11 @@ void NavigationControllerImpl::RendererDidNavigateToExistingPage(
   } else if (params.nav_entry_id) {
     // This is a browser-initiated navigation (back/forward/reload).
     entry = GetEntryWithUniqueID(params.nav_entry_id);
+
+    // Needed for the restore case, where the serialized NavigationEntry doesn't
+    // have the SSL state.
+    NavigationHandleImpl* handle = rfh->navigation_handle();
+    entry->GetSSL() = handle->ssl_status();

[nasko, 2016/09/01 01:35:29]

I think we might need this to happen also in RendererDidNavigateToSamePage. It
is called when the user presses enter in the omnibox. However, if the server
does a redirect to different URL, we still will go through there. This happens
in cases where the user session has expired and the server redirects to the
login page.

[jam, 2016/09/01 02:58:56]

I tried pressing enter in the omnibox and it goes through
RendererDidNavigateToSamePage, however the SSL certificate is correct in that
case (since the previous one is used). Do you mean something else?

[nasko, 2016/09/01 06:27:55]

They key part is for the server to do a redirect. Similar test exists in
content/
https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_co...,
though it doesn't test SSL state, maybe we can add those checks there?

In general, is there a good reason not to do this at RendererDidNavigate
generically? Maybe around here -
https://cs.chromium.org/chromium/src/content/browser/frame_host/navigation_co....

[jam, 2016/09/01 15:44:09]

Got it, thanks. Ok I added a test and a fix.
Yep I agree that would be the easiest. However the previous change that added
this code already couldn't do it in all the codepaths of
RendererDidNavigateToNewPage. Then this fix couldn't do it in all codepaths of
RendererDidNavigateToExistingPage either (see patchset 1 which initially tried
this, but there were test failures). 

   } else {
     // This is renderer-initiated. The only kinds of renderer-initated
     // navigations that are EXISTING_PAGE are reloads and location.replace,