Ojan, do you know if this is a recent regression?

I don't know. Just stumbled across it. I feel like I've seen this before though.

Just repro'd on Chrome 54 on MacOS, so I don't think it's a regression.
I did not repro with UAv2 though, so I'm guessing mustaq has fixed this already :)

Might be a good argument mustaq can use for why the old gesture logic needs to change (i.e. it's hard for developers to get right).

Although, I'm confused why the popup blocker is even involved with ctrl+click of a link...unless maybe the site is capturing the click and dispatching their own window.open?

Two observations:
- On every link the second ctrl-click works.
- First ctrl-click on link1 then second on link2 doesn't work.
- The link in www.example.com doesn't repro this bug.

Btw, seems unrelated to site isolation, repros on my test Surface.

ojan: Yeah usually in these cases the site is intercepting the click and dispatching window.open later.

Not a site problem:
- Works perfectly in Firefox and Edge (hopefully no UA sniffing).
- Ctrl-clicks doesn't go through create_window.cc (unlike window.open() at console).

Enabling UAv2 fixes the popup blocker problem but the new tab still gets focus (unlike Edge/FF).

Charlie, does ctrl-click consume activation?  Or is it supposed to?  I can recall seeing a code that a renderer skips sending focus request to browser if there is no user activation.  This bug could have some link to it.

ctrl-click consumes activation in M67+, so I don't think that's what is happening here.

I think the site is spoofing a ctrl-click, via a simulated mouse event.