Android: Disallow iframes from requesting to auto-log-in.

chrome/browser/ui/auto_login_infobar_delegate.cc

Index: chrome/browser/ui/auto_login_infobar_delegate.cc
diff --git a/chrome/browser/ui/auto_login_infobar_delegate.cc b/chrome/browser/ui/auto_login_infobar_delegate.cc
index 7929b7f925f98d96165be30870047d26c28ecc26..5afcb9d1de7d8b8c8f5068afdcf01c80f5743372 100644
--- a/chrome/browser/ui/auto_login_infobar_delegate.cc
+++ b/chrome/browser/ui/auto_login_infobar_delegate.cc
@@ -140,6 +140,13 @@ void AutoLoginRedirector::RedirectToMergeSession(const std::string& token) {
 // static
 bool AutoLoginInfoBarDelegate::Create(content::WebContents* web_contents,
                                       const Params& params) {
+
+  // Only offer to auto-log-in if the user can see the origin that is

[msw, 2014/02/03 23:37:01]

nit: s/log-in/login/ here and below.

+  // incurring the attempt: that is, if |web_contents| is top-level. iframes

[Charlie Reis, 2014/02/04 01:26:09]

When is a WebContents not top-level?  iframes don't have their own WebContents.

[palmer, 2014/02/20 21:30:33]

I admit I'm no expert, but if a WebContents has an embedder, that would mean it
is not a top-level WebContents. Perhaps its embedder is top-level (i.e.
GetEmbedderWebContents return NULL).

But if iframes don't have their own WebContents, then I don't know what I'm
doing and would appreciate a clue. :)

[Fady Samuel, 2014/02/20 21:35:53]

<webview>: The content of a webview thinks it's a top-level page, but it's
actually embedded by a Chrome App (and perhaps other contexts in the future).

[Charlie Reis, 2014/02/20 22:26:04]

To be clear: iframes never have a WebContents of their own.  WebContents
generally corresponds to a tab and all of its iframes, except in Fady's case of
the <webview> tag.  The whole embedder WebContents notion will go away when
<webview> migrates from BrowserPlugin to using out-of-process iframes
(RenderFrameHosts).

I think you'll need more context than just the WebContents, such as some notion
of which frame the request came from.

[palmer, 2014/10/14 01:09:08]

Any clues on where I can get that context? Sorry, I totally don't know this area
of the code.

[Charlie Reis, 2014/10/14 19:56:41]

I'm not familiar with auto login or the possible call stacks for this function,
but I doubt there's a guarantee that the login attempt is coming from the
currently focused frame.  It might be possible for the event to come from a
different frame than the focused frame in the first place, or the focus may have
changed by the time we get here.

It looks to me like there's not enough context here to tell which frame is
making the request.  Code search isn't cross-linking for me at the moment so
it's tough for me to investigate.  How does this code get called?

[palmer, 2014/10/15 20:54:20]

Weirdly:

~/chromium/src $ search -n '\.cc$' -C AutoLoginInfoBarDelegate::Create -v
./chrome/browser/ui/auto_login_infobar_delegate.cc:132:bool
AutoLoginInfoBarDelegate::Create(content::WebContents* web_contents,
./chrome/browser/ui/auto_login_infobar_delegate.cc
./chrome/browser/ui/android/infobars/auto_login_prompter.cc:110:   
infobar_shown_ = AutoLoginInfoBarDelegate::Create(web_contents(), params_);
./chrome/browser/ui/android/infobars/auto_login_prompter.cc

That's it. I'll look around in the call site after this next meeting.

+  // have no business trying to get people to auto-log-in.
+  if (web_contents->GetEmbedderWebContents())
+    return false;
+
   // If |web_contents| is hosted in a WebDialog, there may be no infobar
   // service.
   InfoBarService* infobar_service =