Refactor CreateOpenerProxies to support updates to frame openers.
commitce5cab104935d3fedcb3c6af2aec0311be43a812
authoralexmos <alexmos@chromium.org>
Thu, 6 Aug 2015 22:57:24 +0000 (6 15:57 -0700)
committerCommit bot <commit-bot@chromium.org>
Thu, 6 Aug 2015 22:57:57 +0000 (6 22:57 +0000)
tree18d25720bd0045fab82d4a8a259d7f8f1acc949c
parentf7c72173c707f617c568a2c71a5fa5ed1ac10d31
Refactor CreateOpenerProxies to support updates to frame openers.

Currently, CreateOpenerProxies assumes that (1) each opener chain can
be recursively traversed until hitting a node with no opener, and (2)
subframes can't have openers.  Neither (1) nor (2) will hold once we
propagate frame opener updates (that happen via window.open) to the
browser process.

To address (1), this CL changes the recursive traversal in
CreateOpenerProxies to a BFS traversal that is resilient to potential
cycles on the opener chain.  To address (2), openers are examined for
all nodes on a given FrameTree, rather than just for the root node.

If the opener graph contains cycles, some proxies created by
CreateOpenerProxies may not have their opener_routing_id available at
creation time.  In a future CL, once opener update IPCs are
implemented, these proxies will need to set their openers in a second
pass (note that this is expected to be very rare, hence an extra IPC
should be ok).  This CL prepares for this by adding logic to collect
nodes involved in cycles that will need this extra processing.

BUG=225940

Review URL: https://codereview.chromium.org/1268153002

Cr-Commit-Position: refs/heads/master@{#342221}
content/browser/frame_host/render_frame_host_manager.cc
content/browser/frame_host/render_frame_host_manager.h
content/browser/frame_host/render_frame_host_manager_unittest.cc