Nice find.  What happens in Blink when this check fails?  I'm wondering if it's something the browser process could do instead.

Also, why isn't it working?  All the A frames will be in the same process, so won't they see each other?  (The loop skips RemoteFrames and continues walking up the tree, rather than early returning.)

The check is done at the HTMLFrameElement level. So in B, it never sees the self-referential URLs in its ancestors, since those are live off in A. But then when we swap to A, we don't do the self-referential check anymore, so we happily load it.

I briefly talked to Nasko about this as well, and it sounds like maybe we could do something similar to CSP blocking. Blocked self-referential iframes behave pretty weirdly today, so we should normalize their behavior anyway. There might also be other ways to bypass it

Assigning to Andrew, who will look into fixing this.  It seems there are other cases that aren't handled by the existing check in LocalFrame::isURLAllowed today (such as when the iframe navigates itself via location.href).  We should be able to fix them all by moving that check to happen in the browser process and canceling the load there.

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

commit 04fdd09f342badeb2af3a639d62a4da65d4baaa1
Author: davidsac <davidsac@chromium.org>
Date: Wed Feb 15 17:05:55 2017

Fix infinite loop of frames being created when one or more frames
contain nested IFrames to one another.

To reproduce this issue, run Chrome in site-per-process mode and visit
either http://dudeguy409.github.io/coreferencingframe1 or
https://davidsac.github.io/coreferencingframe2.html.

The current check refuses to load a URL if any two ancestors in the
frame tree have the same URL. It is currently inadequate for two
reasons:

1) This doesn't work for OOPIFs.  If the parent frames are in a
different process, they will be remote frames which don't have URLs,
so the check is simply skipped.

(2) it's only applied in a subset of cases and doesn't handle
redirects, for example.

To fix these issues, this CL moves these checks to the browser
process, where it's applied inside NavigationHandleImpl any time a
request is started or a redirect is received.

BUG= 650332 ,  527367 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/browser/frame_host/navigation_handle_impl.cc
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/browser/frame_host/navigation_handle_impl.h
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/browser/frame_host/render_frame_host_manager_browsertest.cc
[add] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/test/data/coreferencingframe_1.html
[add] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/test/data/coreferencingframe_2.html
[add] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/content/test/data/page_with_meta_refresh_frame.html
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/third_party/WebKit/Source/core/frame/LocalFrame.cpp
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/third_party/WebKit/Source/core/frame/LocalFrame.h
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/third_party/WebKit/Source/core/html/HTMLFrameElementBase.cpp
[modify] https://crrev.com/04fdd09f342badeb2af3a639d62a4da65d4baaa1/third_party/WebKit/Source/core/html/HTMLPlugInElement.cpp