Hello,

Could you folks help triage this ticket please?  It seems like the omnibox just reverts to showing google.com state (any last successful navigation address), even though the page/interstitial doesn't match that.

Help finding an appropriate owner would be much appreciated.

Emily, I've assigned to you as a proxy for assigning to felt@.  I'm not sure if this is an interstitial problem, or navigation, or omnibox, etc.  Feel free to adjust labels and re-assign.  CC'ing SEA/KIR folks who seem to know what's going on in navigation/spoofing land.

Thanks!

Hmmmm. Looking into it. I'm adding jam@ as well, possibly prematurely, since he's been involved with a few similar bugs recently. (Not sure yet if this is related or not.)

Nope, I prematurely added jam. This reproduces on stable so it's not related to the refactoring he did. I think this is an interstitials-are-weird-and-do-weird-things bug.

Looks like the interstitial page is failing to dismiss.  The same thing happens if you visit an interstitial URL (e.g., wrong.host.badssl.com), put focus in the address bar, and hit Escape.  Same if you type a URL with a 204 response (e.g., https://www.google.com/csi) while an interstitial is showing.  In most of these cases, the "Back to Safety" button does nothing.

I don't think this is a security bug, but it does seem like a functional problem with interstitial pages we should fix.  (It's not clear how this would be exploited to cause harm, especially if user interaction is required.)

I agree with comment 4 that this doesn't really seem like a security bug due to the user interaction, so I'm un-restricting it. Also un-assigning myself because I probably won't be able to work on this anytime soon.

Doesn't seem like a regression, I can repro on even M31.

> Same if you type a URL with a 204 response (e.g., https://www.google.com/csi) while an interstitial is showing.

I get a different behavior with 204 responses. The URL of the 204 site remains in the omnibox, but the interstitial doesn't go away. Based on the log message, this seems to be caused by the evil hack at NavigatorImpl::DidFailProvisionalLoadWithError.

> Looks like the interstitial page is failing to dismiss.

Should the interstitial dismiss? Running javascript: URLs on other pages don't change URL, so I'm not sure why it should be different for the interstitial.

But it looks like NavigationController::DiscardNonCommittedEntries is restoring the last committed URL before the javascript: URL here.

Still an issue.  Adding UI>Browser>Omnibox>SecurityIndicators because this results in a web page showing "Secure: https://www.google.com" in the omnibox while the page content is an error "Your connection is not private: Attackers might be trying to steal your information ..."  In other words, the indicator is not in sync with the page content.

Possibly a similar issue to bug 653963.  (It has similar repro steps.)

creis: Just an observation, but could javascript URLs dropping the pending navigation entry as in  bug 732976  be causing this?

The pending entry is the interstitial URL. When it's dropped, we revert back to the previous entry. 

> creis: Just an observation, but could javascript URLs dropping
> the pending navigation entry as in  bug 732976  be causing this?
If that's the case, then  bug 732976  should probably not be limited to discussing issues with Android Webview.  This bug is on desktop.