Add test case to see if HTTP auth interstitials work nicely with other interstitials

chrome/browser/ui/login/login_prompt.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/ui/login/login_prompt.h"
 
 #include <vector>
 
 #include "base/bind.h"
 #include "base/command_line.h"
@@ skipping 491 matching lines @@
   DCHECK_CURRENTLY_ON(BrowserThread::UI);
   WebContents* parent_contents = handler->GetWebContentsForLogin();
   if (!parent_contents || handler->WasAuthHandled()) {
     // The request may have been cancelled, or it may be for a renderer
     // not hosted by a tab (e.g. an extension). Cancel just in case
     // (cancelling twice is a no-op).
     handler->CancelAuth();
     return;
   }
 
+  // For main frame navigations, show a blank interstitial if this is a cross
+  // origin request or if there is an existing interstitial.

[msw, 2014/08/01 17:09:47]

It sounds like this could clobber or hide the first (potentially important)
interstitial, but the test seems to indicate that it'll show the interstitials
in sequence. Can you clarify this comment and potentially merge it with the
other two comments in the first block?

Can you also expand the CL description and have a second reviewer familiar with
interstitials take a look, since the owners here aren't terribly familiar with
the code and causes for concern? +CC creis, since he reviewed r273358.

Review from someone on the security team would be great too. +CC jschuh, in case
he can take a look or ping someone who ought to take a look.

Bonus points if you post a screencast of the repro steps with and without this
patch on the bug :)

[meacer, 2014/08/01 17:25:56]

Ah, good point. The assumption at the time of writing the CL was that we could
only reach this point when the user proceeds through the first interstitial, and
that it wouldn't be possible to show a login prompt on top of an existing
interstitial. But after recent discussions, it's clear that when a malware
interstitial is displayed, the page still keeps running in the background, so it
might be possible to show an auth prompt on top of the existing interstitial.
That I believe can hide the malware interstitial. I'm going to test that.
I'll give it a shot :)

   if (is_main_frame &&
-      parent_contents->GetVisibleURL().GetOrigin() != request_url.GetOrigin()) {
+      (parent_contents->GetInterstitialPage() ||
+       parent_contents->GetVisibleURL().GetOrigin() != request_url.GetOrigin())
+      ) {
     // Show a blank interstitial for main-frame, cross origin requests
     // so that the correct URL is shown in the omnibox.
     base::Closure callback = base::Bind(&ShowLoginPrompt,
                                         request_url,
                                         make_scoped_refptr(auth_info),
                                         make_scoped_refptr(handler));
-    // This is owned by the interstitial it creates.
+
+    // This is owned by the interstitial it creates. The new interstitial will
+    // replace existing interstitial, if any.
     new LoginInterstitialDelegate(parent_contents,
                                   request_url,
                                   callback);
   } else {
     ShowLoginPrompt(request_url,
                     auth_info,
                     handler);
   }
 }
 
 // ----------------------------------------------------------------------------
 // Public API
 
 LoginHandler* CreateLoginPrompt(net::AuthChallengeInfo* auth_info,
                                 net::URLRequest* request) {
   bool is_main_frame = (request->load_flags() & net::LOAD_MAIN_FRAME) != 0;
   LoginHandler* handler = LoginHandler::Create(auth_info, request);
   BrowserThread::PostTask(
       BrowserThread::UI, FROM_HERE,
       base::Bind(&LoginDialogCallback, request->url(),
                  make_scoped_refptr(auth_info), make_scoped_refptr(handler),
                  is_main_frame));
   return handler;
 }