We generally don't consider popup blocker bypasses to be security issues. I think this is likely working as intended as it still requires a user gesture, but changing some labels and removing view restrictions so that the right people can take a look.

seems like touchend and click don't share the same user gesture token :-/

given that the repro actually manages to open two popups on one user gesture, I'd consider this a low risk security issue

Yeah getting two pop-ups instead of only one on a tap is known limitation of our current design (considered very low severity).

Still we should track fixing it - it _might_ not be that hard.  We'd have to cache the token in blink and try to re-use it on GestureTap events.  But we'd have to be careful to create a new token if none exists (eg. may not have gotten any touch events) and not to re-use a really old unrelated token (will have timed out).

There's m_lastMouseDownUserGestureToken https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/EventHandler.h?rcl=1477451763&l=368 which is used to connect mousedown/click/mouseup

I think we can just use that for the touch events as well

Technically someone could click with the mouse at the same time as tapping the touch screen and those would be two user gestures, but this is a niche scenario probably not worth worrying about.

The only non-trivial bit I see is knowing when to clear the token.  If we just saved a token on touchend and re-used it for GestureTap, that would break in the cases where the page has no touch listeners so we hit the optimization where touchend events aren't sent to blink at all.  But perhaps we could just clear the saved token after every GestureTap (and LongPres etc.) as well as every touchstart.  Still might be quite simple.

Note that there's also TouchEventManager::m_touchSequenceUserGestureToken which is more directly applicable here, but I was hoping to delete that: https://codereview.chromium.org/2414273003/

Maybe we just need to plumb a flag through that tells the event handler that the mouse events are actually touch events, so they should use the touch flag. that would also solve the real touch + real click at the same time issue

We have that flag, but I don't think we need it.  The UGI is taken in code that's already not shared between the touch and mouse paths.  This isn't a problem about sharing the mouse token and the touch token.  It's about sharing the touch token with the gesture token (https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/GestureManager.cpp?type=cs&sq=package:chromium&l=185)

Rick, is this issue still open? I'm not sure what the state of the gesture interventions currently is..

Yes this is still open.  Gesture events (like GestureTap which generates click) and Touch events (like touchend) are almost completely disconnected in blink.  So sharing a gesture token between them is probably difficult.

I'd call this Pri-3 myself (given my guess at low benefit and non-trivial cost).  But it's up to the input folks (dtapuska, nzolghadr, mustaq).  Perhaps it's simpler to implement correctly than I'm guessing?

Let's block it on our simple user gesture project.