Not sure where to put this...

Able to reproduce the issue on Mac 10.13.5, Windows-10 and Ubuntu 14.04 using chrome reported version #67.0.3396.79, latest stable #67.0.3396.99 and seen on the latest chrome #69.0.3473.0 and latest beta #68.0.3440.33.

Bisect Information:
=====================
Good Build: 67.0.3394.0
Bad Build: 67.0.3395.0

Change Log: 
https://chromium.googlesource.com/chromium/src/+log/fc2d77d50dcc5d418ad1975b9a07826b16d8708a..5bab263e50fc9755106d88cc012d5d78e22d2e96
https://chromium.googlesource.com/chromium/src/+/5bab263e50fc9755106d88cc012d5d78e22d2e96 
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1005318
       
Charlie Harrison@ - Please confirm the issue and help in re-assigning if it is not related to your change.
Adding ReleaseBlock-Stable for M-67 as it seems recent break.Feel free to remove it if not applicable.

Thanks...!!

jacob: Thanks for reporting this issue. Is it breaking major functionality? I just want to evaluate how critical a fix is here.

viswa.karala: I'm not confident this is critical enough to merge all the way up to M67 for a stable respin. I am tentatively removing the Target-67 label for now.

+mustaq, since I confirmed (on MacOS) that this does _not_ reproduce with UAv2. My understanding of what is happening is that:
1. A frame navigates B frame (in a separate tab)
2. The ConsumeGestureOnNavigation code consumes a gesture on B
3. A tries to focus B (A needs a gesture for success)

Without UAv2, A and B share a global gesture (since everything is same-process). This means that (2) prevents (3) from happening. Last we spoke, UAv2 was slated for M69/M70, so this might need a separate fix if it will be merged to M68.

Note this does not repro when the sites are not same-process. For instance, with the following case:
data:text/html,<a target="C" href="https://www.google.com">clickme</a>

The non-UAv2 solution we can do is to just move the consume gesture logic from content --> Blink at the same place in the navigation flow. The only difference is that blink has the information to avoid consuming the gesture if the target frame is not the original frame.

Removing "M-67" per comment #4. 

It's not breaking major functionality, but it is breaking use case expectations and is an irritation for our internal users. Who expects to normally click on a link and not see that link open at all.

I'm not sure what constitutes a page being in a new process so this may not be useful information, but our exact use case involves site A being a subdomain on our site, and site B is a different server on the same subdomain with a different port. I suspect that if google.com had an appropriately targeted link back to the page that had linked to it and you were to click back and forth once or twice, they would reproduce this issue.

Thanks for the prompt response Jacob, that makes perfect sense. I have a fix for this on the way, but unless there is major breakage I'm not sure it warrants RB-Stable.

Note: we tested that Edge (and Firefox on Linux) has this same issue. We might want to standardize behavior here longer term.

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

commit 25d68397fe4e4471239e8581b3b5742ad655305f
Author: Charlie Harrison <csharrison@chromium.org>
Date: Thu Jun 28 22:27:34 2018

Ensure links with targets properly cause focus

In M67 we launched activation consumption at the start of main frame
navigations. This was used to lock down a partial tab-under case:
1. Site begins to navigate itself to unwanted 3p content
2. Site subsequently launches a popup to the user's true destination

This ended up breaking tab focus for navigations with target= that
both navigate a different tab and focus it, since before UAv2
gesture state is process-global.

This change fixes this bug by avoiding gesture consumption on
navigation when the target is in a different page than the initiator.
This behavior aligns with:
 - Behavior when the target is remote
 - Behavior when UAv2 ships (since gesture consumption is per frame tree)

This change also removes the flag controlling gesture consumption as
a feature, and moves some core implementation into blink.

Bug:  856779 
Change-Id: I29e26d5598e32517d025b0f44234e8b9b9a10e59
Reviewed-on: https://chromium-review.googlesource.com/1117028
Commit-Queue: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#571302}
[modify] https://crrev.com/25d68397fe4e4471239e8581b3b5742ad655305f/chrome/browser/chrome_navigation_browsertest.cc
[add] https://crrev.com/25d68397fe4e4471239e8581b3b5742ad655305f/chrome/test/data/link_with_target.html
[modify] https://crrev.com/25d68397fe4e4471239e8581b3b5742ad655305f/content/renderer/render_frame_impl.cc
[modify] https://crrev.com/25d68397fe4e4471239e8581b3b5742ad655305f/content/renderer/render_frame_impl.h
[modify] https://crrev.com/25d68397fe4e4471239e8581b3b5742ad655305f/third_party/blink/renderer/core/loader/frame_loader.cc

Able to reproduce the issue on chrome version 67.0.3396.79
Verified the fix on Windows-10, Ubuntu 14.04, Mac 10.12.6 using Chrome version #69.0.3480.0 as per the comment #0.
Attaching screen cast for reference.
Observed "Previously open tab for page B got refreshed and is in the foreground".
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 856779.ogv 1.4 MB

	856779.ogv 1.4 MB View Download