[ios] Do not commit invalid URLs during web load.

ios/web/web_state/ui/crw_web_controller.mm

Index: ios/web/web_state/ui/crw_web_controller.mm
diff --git a/ios/web/web_state/ui/crw_web_controller.mm b/ios/web/web_state/ui/crw_web_controller.mm
index 46f58a99d38b930473c906f141c9b23ab8718030..b886c699a6990c67e09ef077fb9b501db18288f4 100644
--- a/ios/web/web_state/ui/crw_web_controller.mm
+++ b/ios/web/web_state/ui/crw_web_controller.mm
@@ -2290,7 +2290,11 @@ const NSTimeInterval kSnapshotOverlayTransition = 0.5;
   [self optOutScrollsToTopForSubviews];
 
   // Ensure the URL is as expected (and already reported to the delegate).
-  DCHECK(currentURL == _lastRegisteredRequestURL)
+  // If |_lastRegisteredRequestURL| is invalid then |currentURL| will be
+  // "about:blank".
+  DCHECK((currentURL == _lastRegisteredRequestURL) ||
+         (!_lastRegisteredRequestURL.is_valid() &&
+          _documentURL.spec() == url::kAboutBlankURL))
       << std::endl
       << "currentURL = [" << currentURL << "]" << std::endl
       << "_lastRegisteredRequestURL = [" << _lastRegisteredRequestURL << "]";
@@ -5095,7 +5099,17 @@ const NSTimeInterval kSnapshotOverlayTransition = 0.5;
   // This is the point where the document's URL has actually changed, and
   // pending navigation information should be applied to state information.
   [self setDocumentURL:net::GURLWithNSURL([_webView URL])];
-  DCHECK(_documentURL == _lastRegisteredRequestURL);
+
+  if (!_lastRegisteredRequestURL.is_valid() &&
+      _documentURL != _lastRegisteredRequestURL) {
+    // if |_lastRegisteredRequestURL| is an invalid URL, then |_documentURL|
+    // will be "about:blank".

[kkhorimoto, 2016/06/22 22:20:54]

Should we add a DCHECK to ensure that it's about:blank?  Would it be possible
for the committed document URL to be something valid (i.e. gmail.com), then some
kind of redirect occurring between this and |-webView:didFinishNavigation:|
where the URL is reset to about:blank?  That would bypass the DCHECK above, but
would have a valid spoofed URL for the committed item.  I'm not sure that could
happen in a way that would bypass other calls to |-updatePendingEntry:| of the
top of my head though.

[Eugene But (OOO till 7-30), 2016/06/22 22:48:25]

1.) DCHECK below covers that case.
2) I don't think that server side redirect can happen after didCommitNavigation:
(which means that server started responding with data). Client side-redirect
should cause a new navigation. Do you think I'm missing something? 

[kkhorimoto, 2016/06/23 23:06:22]

Yeah, I checked it out and it looks like all client redirects have an associated
registerLoadRequest, so this will probably be fine.

+    [[self sessionController] updatePendingEntry:_documentURL];
+  }
+  DCHECK(_documentURL == _lastRegisteredRequestURL ||
+         (!_lastRegisteredRequestURL.is_valid() &&
+          _documentURL.spec() == url::kAboutBlankURL));
+
   self.webStateImpl->OnNavigationCommitted(_documentURL);
   [self commitPendingNavigationInfo];
   if ([self currentBackForwardListItemHolder]->navigation_type() ==