http://liveoverflow.com/poc/popunder4.html

Here is what's going on:

1) Original page A has a link. User presses the mouse button to click the link.
2) On the mousedown event, page A opens a new tab ("B") and writes a mouseup handler into it. This happens very quickly.
3) The user releases the mouse, but page B is now under the mouse.
4) Page B's mouseup handler runs, creating a popup.
5) Page A then activates itself in the usual manner.

On the Mac, the mouseup from a mousedown only gets delivered to the page that got the mousedown. On Windows (but interestingly, not MacViews!) the mousedown can get delivered to a different page than the mousedown.

A, that probably should be fixed.

B, the popunder blocker could be even smarter.

Scott, thoughts about A?

correction:

On the Mac, the mouseup from a mousedown only gets delivered to the page that got the mousedown. On Windows (but interestingly, not MacViews!) the **mouseup** can get delivered to a different page than the mousedown.

I tend to agree with that we should only send the pointer-up to the aura::Window/View that got the pointer-down. At a minimum we could do this for WebView.

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

commit 31c61a8abb57358c5ce00f67e183f351cad04efa
Author: Avi Drissman <avi@chromium.org>
Date: Mon Aug 07 21:10:30 2017

Expand the power of the popunder preventer.

If *any* WebContents in the opener chain of a popup
attempts to bring itself forward in front of the
popup, block that attempt to create a popunder.

BUG= 752824 

Change-Id: I4178f3872eb7af2f10d993bc8b54485b340c8355
Reviewed-on: https://chromium-review.googlesource.com/603149
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#492407}
[modify] https://crrev.com/31c61a8abb57358c5ce00f67e183f351cad04efa/chrome/browser/ui/blocked_content/app_modal_dialog_helper.cc

+ awhalley@ (Security TPM) for merge review.

This bug requires manual review: M61 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), ketakid@(ChromeOS), govind@(Desktop)

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

Not a security bug, but seems reasonable to merge to 61.

Thank you awhalley@.

avi@, could please answer followings before we approve merge to M61?
* Is this M61 regression? Is it critical?
* Is the change well baked/verified in Canary, having enough automation tests coverage and safe to merge to M61?
* Any other important details to justify the merge.

Please note M61 is already in Beta, so merge bar is very high. Thank you.

The popunder is being used in the wild. I don't know what the criteria is for popunder merges, and how they rank in severity. See  bug 752630  and  bug 729495  for examples of popunder merges.

Thank you avi@. How is the change looking in Canary?

It's looking solid in the canary. I have verification that it fixes the popunder implementation.

Approving merge to M61 branch based on comment #14 and #16 and also per https://bugs.chromium.org/p/chromium/issues/detail?id=752630#c18. Please merge ASAP.

This will be second popunder merge for M61 (+abdulsyed@)

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

commit 378d39506d1621b1023a14ff81514ba31024c126
Author: Avi Drissman <avi@chromium.org>
Date: Thu Aug 10 19:52:16 2017

Expand the power of the popunder preventer.

If *any* WebContents in the opener chain of a popup
attempts to bring itself forward in front of the
popup, block that attempt to create a popunder.

BUG= 752824 
TBR=avi@chromium.org

Change-Id: I4178f3872eb7af2f10d993bc8b54485b340c8355
Reviewed-on: https://chromium-review.googlesource.com/603149
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#492407}(cherry picked from commit 31c61a8abb57358c5ce00f67e183f351cad04efa)
Reviewed-on: https://chromium-review.googlesource.com/611026
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#453}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/378d39506d1621b1023a14ff81514ba31024c126/chrome/browser/ui/blocked_content/app_modal_dialog_helper.cc

Published in https://www.youtube.com/watch?v=PPzRcZLNCPY so dropping the view restriction as it's public.

Rechecked this issue on chrome version 61.0.3163.49 on Windows 10 using the Test URL provided:

http://liveoverflow.com/poc/popunder4.html

Followed the below steps:

1) Clicked on the link edge pop-under, observed that a popup window was displayed on clicking the link.
2) Clicked on link Chrome-pop-under, observed that a popup appears but was blocked by a bubble, Clicking the OK button in the bubble brings the focus to the Popup Window.

Is this the expected behavior, Can this be confirmed.

Thanks.!

That is the correct behavior. The page should be allowed to show a popup but when the dialog is closed the popup should be brought back into focus.

for posterity, there's a valid use case of sending the mouse down to one window and the mouse-up to another and that's drag & drop :)

Ok, fair. But a newly-created tab?