Attempting to view the Developer Tools to see what the security Developer Tool would should resulted in a crash. Remote Crash ID: 78ec14ce40000000 

I can reproduce this on Mac 61.3115 on StackOverflow as well; I could not reproduce on M60.3104 or Windows 61.3115.

Re #2: That crash appears to be Issue 727230. I was able to reproduce that on Windows with Canary too.

Sometimes this just doesn't happen *at all* no matter how much mashing of forward and back I do. Restarting the browser completely may make the issue reproducible again. Seems about 50/50 to me?

Can also reproduce on any site, not just Stack Overflow.

I can't reproduce on Canary (61.0.3115.0) or ToT (61.0.3116.0). I've tried doing exactly what's in the video (go through the menu, then navigate back+forward), as well as a whole bunch of aimless clicking and multiple back/forward navigations, to no avail. :-(

Canary has the BrowserSideNavigation-Enabled_50 variation in my case.

Uh, in my previous comment I meant to ask: Eric, is there a particular sequence that repros for you?

I've now managed to reproduce this on Windows with 61.3115 as well. 

I used the ALT+Left and ALT+Right hotkeys to rapidly navigate between pages in the repro case. I had a much harder time reproducing, possibly because my Desktop is a 48 thread monster and the MacBook isn't?

Deleted: BadChip.png 19.7 KB

	BadChip.png 19.7 KB View Download

I can't repro yet, but feels like it might be related to  issue 688425 ,  issue 642838 .

estark: assigning to you to move out of the enamel queue, but please feel free to reassign as needed :)

Unable to reproduce the issue on Mac-10.12.4, Windows-7 and Linux Ubuntu-14.04 using chrome canary 61.0.3115.0 with the steps mentioned in comment#0.
Please find the attached screen cast and let us know if anything missed here to reproduce the issue.

Thanks.

I was not able to reproduce in ToT without enabling browser-side-navigation.
After enabling browser side navigation, repro was quick.

chrome.exe --enable-features="browser-side-navigation"

[16144] [16144:28288:0531/102949.368:WARNING:spdy_session.cc(2908)] Received HEADERS for invalid stream 37
[16144] [16144:28484:0531/102949.414:INFO:navigation_controller_impl.cc(892)] NAVIGATION_TYPE_EXISTING_PAGE
[16144] 
[16144] [16144:28484:0531/102949.452:INFO:navigation_controller_impl.cc(892)] NAVIGATION_TYPE_EXISTING_PAGE
[16144] 
[16144] [16144:28484:0531/102950.024:WARNING:render_frame_host_impl.cc(2512)] OnDidStopLoading was called twice.
[16144] [16144:28484:0531/102950.289:INFO:navigation_controller_impl.cc(907)] NAVIGATION_TYPE_AUTO_SUBFRAME
[16144] 

A simple repro page is https://bayden.com/test/nav/1.html
Click through each of the six pages, then use ALT+Left and ALT+Right to flip through the content until you reproduce the error. The error only seems to be hit with browser-side-navigation enabled.

Debugging thus far shows that the ssl_status is set properly inside NavigationResourceHandler::OnResponseStarted, but it's missing by the time NavigationControllerImpl::RendererDidNavigate is hit.

In the repro scenario, RenderFrameHostImpl::OnDidStopLoading() clears navigation_handle_, so when RenderFrameHostImpl::TakeNavigationHandleForCommit gets called by OnDidCommitProvisionalLoad, there's no navigation_handle_ for it to reuse and return. 

TakeNavigationHandleForCommit creates a new navigation handle ("return NavigationHandleImpl::Create" at the function's end), and its ssl_status remains default because the correct ssl_status was set on the old handle (via NavigationHandleImpl::WillProcessResponse) that was cleared previously, not the newly created handle. 

So we lose ssl_status.

The good news is that this fails securely.

Please let us know a bisect is needed based on the repro steps in #14.

Thanks for the repro. For some reason comments 13-16 weren't sent by email to me. Just to check before I file a bug, did you uncheck send email by chance?

I'll try to repro this locally (this bug is my fault).

Re #18: It's entirely possible that I did. 

I see the bug, sorry about that.

Thank a lot Eric for reproducing this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/db06e65dcd8da3f5b8cab60ecb32e9ba89c1598c

commit db06e65dcd8da3f5b8cab60ecb32e9ba89c1598c
Author: John Abd-El-Malek <jam@chromium.org>
Date: Thu Jun 08 00:45:52 2017

Fix SSL indicator missing when doing fast back/forward navigations.

This regressed in r415977, which was fixing the session restore case where a serialized NavigationEntry wouldn't have the SSLStatus. The race in the non-restore case happens because a previous DidStopLoading IPC clears the new NavigationHandle which does have the SSLStatus. In this case, the fix is to only copy the SSLStatus specifically in the restore case.

BUG= 727892 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
R=estark@chromium.org

Review-Url: https://codereview.chromium.org/2926803002 .
Cr-Commit-Position: refs/heads/master@{#477837}

[modify] https://crrev.com/db06e65dcd8da3f5b8cab60ecb32e9ba89c1598c/content/browser/frame_host/navigation_controller_impl.cc

Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c89b46b3ed1f0f084ff3213750c688c8154e62a5

commit c89b46b3ed1f0f084ff3213750c688c8154e62a5
Author: John Abd-El-Malek <jam@chromium.org>
Date: Fri Jun 09 15:50:33 2017

Fix SSL indicator missing when doing fast back/forward navigations.

This regressed in r415977, which was fixing the session restore case where a serialized NavigationEntry wouldn't have the SSLStatus. The race in the non-restore case happens because a previous DidStopLoading IPC clears the new NavigationHandle which does have the SSLStatus. In this case, the fix is to only copy the SSLStatus specifically in the restore case.

BUG= 727892 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation
R=estark@chromium.org

Review-Url: https://codereview.chromium.org/2926803002 .
Cr-Original-Commit-Position: refs/heads/master@{#477837}
Review-Url: https://codereview.chromium.org/2934493002 .
Cr-Commit-Position: refs/branch-heads/3112@{#282}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}

[modify] https://crrev.com/c89b46b3ed1f0f084ff3213750c688c8154e62a5/content/browser/frame_host/navigation_controller_impl.cc

This fix caused another bug on Android: when the offline version of a page is loaded through a reload action, the secure chip remains when it should in fact have been replaced by the offline one. See issue 731233.

Verified the fix on Mac 10.12.5 and Win-10 using Chrome beta version #60.0.3112.32 as per the comment #0.
Attaching screen cast for reference.
Observed that security chip accurately showed that the site has HTTPS as expected.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 727892.mp4 2.7 MB

	727892.mp4 2.7 MB View Download