I don't believe the GestureEventQueue is actually releasing the next gesture event after the gesturetapunconfirmed event is it? I don't see an IPC send after the gesturetapunconfirmed until like 1304ms

You're right.

Paul, can you provide repro steps?

Mmmhmm. See the attached zip. FWIW when I change .list to flex-wrap: nowrap the delay disappears.

Deleted: long-gesture.zip 1.3 MB

long-gesture.zip 1.3 MB Download

Is this just the tap delay https://developers.google.com/web/updates/2013/12/300ms-tap-delay-gone-away ?

Quite possibly. Presumably because the content flows outside the viewport?

If that's the case I wonder if one (or both) of the following would help:

1. A console warning to notify developers that they should expect the tap delay
2. Something in the trace that makes that obvious

What do you think?

The correct solution here is to make sure developers are using a mobile viewport. We already do complain somewhere about that, right? +Paul Irish

Adding something to the trace/timeline to make it clear what's happening does sounds useful. Paul, does adding something to the devtools timeline making this clear sounds useful to you?

Oh, you are using a mobile viewport. Yeah, I suspect that because you flow outside the viewport we treat it as though the mobile viewport tag isn't there.

I wonder if we should change that.

The conditions are set here:

https://cs.chromium.org/chromium/src/content/browser/renderer_host/frame_metadata_util.cc

So it does in fact look like overflowing contents (as long as they're in the root layer - seems like a scroller that's outside the viewport width wouldn't trigger the delay) enables the delay.

The trouble here is that double tap delay happens all the way up in the browser process while we only have access to the viewport meta in Blink. We'd have to plumb it all the way up to be more robust. This is actually a copy of VisualViewport::shouldDisableDesktopWorkarounds: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/VisualViewport.cpp?sq=package:chromium&dr=CSs&rcl=1484223716&l=798

Which uses layout size rather than content size, so that's really what we want. If we do want to do this, plumbing that bool up into the browser is the way to go.

How common is flowing outside of a mobile viewport?

We don't have any numbers, but anecdotally, it's not super rare. I see questions on Stackoverflow every few weeks about why a page is being loaded zoomed out and it's often because there's some image further down the page that flows outside of the layout width. I suspect plenty of pages fix that by setting minimum-scale=1 (or initial-scale=1).

Rick - any thoughts on the correct behavior here? When content flows outside of a mobile viewport, we get the tap delay. Our advice for avoiding the tap delay currently doesn't state that you shouldn't flow outside the viewport.

I'm inclined to say that we should disable the tap delay in this context.

Assigning to bokan@ for triage.

My gut is that if a meta viewport is set then the developers intends the page to not require zooming (and the fact that it does is primarily a bug).  In that case I'd say disabling double-tap is preferable to adding the delay.  It makes the behavior easier to reason about IMHO.  Something as fundamental as "is double tap zoom enabled" should ideally not depend on heuristics or other things that are hard to reason about (like layout of the entire page).

That said, there's might be a little compat risk here (eg. for sites that really aren't mobile-optimized and have a largely-bogus viewport).  But I think the impact is minor - people can still pinch-zoom.  Personally I think I'd just fix the behavior to be more deterministic (plumbing the data from blink instead of trying to infer it from the browser based on viewport size) as a bug fix and keep my eyes open for any user complaints.

bokan@ what's the next step for this bug?

I had a CL for this but it lost momentum. I'll try to take another look sometime soon since this is still an issue though my next few weeks are quite busy.