estark@, do you particularly want this fixed in M57?

I don't want to oversubscribe myself, and I'm planning to look at misc. Security panel bugs in for Enamel-FinishAllTheThings (Q1).

M58 seems fine to me.

Stealing this one.

In the case where an HTTPS interstitial fires, we never get a SDK.NetworkManager.Events.ResponseReceived event for the HTTPS request. That means we can't store off the LoaderID->Request mapping that we later use when we get the MainFrameNavigated event that we use to record the main origin.

The straightforward fix for this is to do:

    if (request) {
      var origin = Common.ParsedURL.extractOrigin(request.url());
      this._sidebarTree.setMainOrigin(origin);
      this._processRequest(request);
    }
+   else {
+     var origin = Common.ParsedURL.extractOrigin(frame.url);
+     this._sidebarTree.setMainOrigin(origin);
+   }

This works for the common cases. I believe there's still a corner case in the event that the origin only has a single resource request. In that case, we'll never call _processRequest() for the main origin and thus we'll never call _sidebarTree.addOrigin and thus the main origin will still never get added to the list.

Another alternative fix would be to reshow the "Reload to view details" UI text in the case that MainFrameNavigated is called without any prior matching call to ResponseReceived.

The most comprehensive fix would be to go spelunking and figure out why ResponseReceived isn't getting called for the response that led to an interstitial, and fix that. Fixing that would fix this bug and would also fix the bug that the Developer Tools' Network Tab doesn't presently show the request that led to the interstitial either. E.g.

   Open the Network tab.
   Navigate to https://expired.badssl.com
   Click through the Interstitial.
   Observe: The request for the HTML page is never shown.

Lucas-- Any preferences in how I should go about fixing this? I'm inclined to take the first, straightforward fix, but you know this code very well. 

>Another alternative fix would be to reshow the "Reload to view details"
>UI text in the case that MainFrameNavigated is called without any 
>prior matching call to ResponseReceived.

This turns out not to be a good enough fix, because there are cases (observed on the wrong.host.badssl.com page on Mac) where reload doesn't result in any requests getting captured at all, so reloading isn't helpful. 

I've asked allada@ if the ResponseReceived limitation is known, but for now I'm going to put together a CL for the first approach.

https://codereview.chromium.org/2756983002

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

commit b37aaf2370cd187b34d4853e85ed6ed58b3665f9
Author: elawrence <elawrence@chromium.org>
Date: Wed Mar 22 05:23:48 2017

[DevTools] Fallback to MainFrameNavigated event url in Security panel

If a HTTPS connection is blocked for security reasons, an interstitial
is presented and the Network Manager does not raise a ResponseReceived
event. Previously, the lack of a matching ResponseReceived event would
prevent the MainFrameNavigated event from correctly setting the "Main
Origin" for the sidebar.

With this CL, if the main navigation request was not previously
captured by the ResponseReceived event, we will instead compute the
Main Origin by looking at the URL in the MainFrameNavigated event
itself.

BUG= 669309 
TEST=blink_layouttests. Alternatively, open Security Panel. Navigate through https://expired.badssl.com/
interstitial. Verify Main Origin appears in sidebar.

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

[add] https://crrev.com/b37aaf2370cd187b34d4853e85ed6ed58b3665f9/third_party/WebKit/LayoutTests/http/tests/inspector/security/main-origin-assigned-despite-request-missing-expected.txt
[add] https://crrev.com/b37aaf2370cd187b34d4853e85ed6ed58b3665f9/third_party/WebKit/LayoutTests/http/tests/inspector/security/main-origin-assigned-despite-request-missing.html
[modify] https://crrev.com/b37aaf2370cd187b34d4853e85ed6ed58b3665f9/third_party/WebKit/Source/devtools/front_end/security/SecurityPanel.js

With regard to root cause, per allada@:

"I did some digging and it appears we are simply not sending "Network.requestWillBeSent" for these cases, because the request commit is buffered waiting for browser to allow it through. However, I am going to suggest that we do not fix this bug until PlzNavigate gets launched (crbug.com/368813). This bug may be fixed with their work and will keep us from stepping on their toes."