OK, so here we go.

The "opener" and "initial opener" values on WebContents are not actually stored on WebContents, but are actually FTNs! WebContentsImpl::GetOpener() and WebContentsImpl::GetOriginalOpener() fetch the appropriate value from the FTN and return the WebContents that owns that FTN.

This makes sense for GetOpener, since that corresponds to the JavaScript notion of "opener", which has to be at the frame level. However, for GetOriginalOpener, keeping the opener at the frame granularity is undesirable because 1. we don't need that and 2. it makes it easy to avoid, and that was kinda the point of "original opener".

Here's the evasion.
1. Main page creates a subframe.
2. Subframe creates a popup window.
3. Main page destroys the subframe; the "original opener" field is cleared on the popup.
4. Main page creates a PDF guest WebContents to make an alert.
5. The AppModalDialogHelper sees the popup but sees that the "original opener" field is null.
6. Main page destroys the PDF guest WebContents to dismiss the alert.
7. The AppModalDialogHelper doesn't put the popup back on top.

I think the solution here is to track the original opener as a WebContents, or at least as the top-most frame.

Charlie, any thoughts here?

Tracking frame owners in FTNs rather than as WCs was https://codereview.chromium.org/1086283002.

Approach 1: Using FTNs for "original owner"
+ Stays parallel to the "owner" implementation
+ Simpler
- The original owner isn't actually a FTN, but a WebContents

Approach 2: Using the original approach of keeping a WebContents* in the WebContents
+ More strictly correct
- Two different ways of doing similar things

(BTW, the FT remains constant for the WC life, and the root FTN shares the lifetime of the FT so approach 1 can be made correct.)

CL up at https://codereview.chromium.org/2773403002 .

What is the bar for merging? This probably has been broken for about 1 3/4 years, since the move to FTNs for owner tracking.

Please have alexmos@ review, since he's very familiar with openers and I'm OOO.

Nice analysis, thanks for fixing!  The subframe opener tracking definitely made this possible, though it seems that even before that, there might have been holes here until jochen@ introduced original opener tracking in https://codereview.chromium.org/2661403003 a couple of months ago.  E.g., AFAICT with old WC-based openers, the popup could still set its window.opener to null, which would've caused the old WCI::DidDisownOpener to clear out WebContentsImpl::opener_, which used to be what AppModalDialogHelper looked at.  jochen@'s fix took care of that case, but definitely a d'oh moment for the subframe workaround.

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

commit 8d1aa16d8f9e854e3f099f9fad9866efe072f821
Author: avi <avi@chromium.org>
Date: Mon Mar 27 18:27:37 2017

Fix popunders spawned from a subframe.

BUG= 705316 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

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

[modify] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/chrome/browser/ui/blocked_content/popup_blocker_browsertest.cc
[add] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/chrome/test/data/popup_blocker/popup-subframe.html
[add] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/chrome/test/data/popup_blocker/popup-window-subframe-open.html
[modify] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/content/browser/frame_host/frame_tree_node.cc
[modify] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/content/browser/frame_host/frame_tree_node.h
[modify] https://crrev.com/8d1aa16d8f9e854e3f099f9fad9866efe072f821/content/browser/web_contents/web_contents_impl.cc

Please apply appropriate OS labels. Thank you.

Given that we're three weeks out from branch, dropping the stable merge request.

And geez, it seems like everyone knows how to popunder this way, so removing RVG.

Landed in 59.0.3054.0.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Please ensure to verify the fix, if all looks good merge ASAP so that it will be picked up for next Beta Release, RC cut today (Tuesday-03/28) at 4.00 PM PST.

This is verified. Merging.

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

commit 7b3733eb24574660bc2b4aeb4b3e5147cae06a88
Author: Avi Drissman <avi@chromium.org>
Date: Tue Mar 28 20:02:16 2017

Fix popunders spawned from a subframe.

BUG= 705316 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_site_isolation

Review-Url: https://codereview.chromium.org/2773403002
Cr-Commit-Position: refs/heads/master@{#459835}
(cherry picked from commit 8d1aa16d8f9e854e3f099f9fad9866efe072f821)

Review-Url: https://codereview.chromium.org/2778113003 .
Cr-Commit-Position: refs/branch-heads/3029@{#458}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/chrome/browser/ui/blocked_content/popup_blocker_browsertest.cc
[add] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/chrome/test/data/popup_blocker/popup-subframe.html
[add] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/chrome/test/data/popup_blocker/popup-window-subframe-open.html
[modify] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/content/browser/frame_host/frame_tree_node.cc
[modify] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/content/browser/frame_host/frame_tree_node.h
[modify] https://crrev.com/7b3733eb24574660bc2b4aeb4b3e5147cae06a88/content/browser/web_contents/web_contents_impl.cc