James, could this be due to the coalesced event issue on Android? Apologies if I ended up reporting a duplicate.

Attaching a video recording of the repro on Android 8.0 Pixel phone.

Deleted: 20180208_013133_edited.mp4 7.2 MB

	20180208_013133_edited.mp4 7.2 MB View Download

Still able to reproduce this on the latest Canary 66.0.3345.0.

I just noticed this bug has existed since at least current stable (64.0.3282.137).

There seems to be a confusing mess of things going on here.

First and foremost: it seems possible to send a touch event sequence to the OOPIF (which is very busy while it loads), and then tap outside the OOPIF ... the later tap gets acked back to the TouchEventDispositionFilter *out of order, since there are still OOPIF events that aren't acked*, and causes the DCHECK at 

https://cs.chromium.org/chromium/src/ui/events/gesture_detection/touch_disposition_gesture_filter.cc?rcl=0f8cefda01ab4f2281e11da181d863a342ebc51d&l=211

to fire.

Unrelated, I'm also seeing the DCHECK at

https://cs.chromium.org/chromium/src/content/browser/renderer_host/render_widget_host_impl.cc?rcl=8739ea65eb80fa7bc1e0fa41d08daee8f1860f67&l=1165

fire, but the GSE that triggers this is *not* coming from the RenderWidgetHostInputEventRouter (nor are any other gesture events it seems), so I'm still not sure what's happening here.

Finally, scroll bubbling is causing DCHECKs to fire if you try to scroll the oopif while it's loading, then tap in the mainframe.

ekaramad@ - Just curious ... have we ever tried to repro this on Linux/ChromeOS?

I can hit the |Head().front().unique_touch_event_id() == unique_touch_event_id| DCHECK on linux by using a slow touch handler in the child, e.g.
document.body.addEventListener('touchmove', function(e) {
  var end = performance.now() + 1000;
  while(performance.now() < end); 
})
and then alternating between scrolling the root and child.

I think that since  Issue 848050  is now resolved, that this issue likely is too. I'm unable to reproduce this issue on Linux. I think we verified the issue mcnee@ raises in C#9 in fixing  Issue 913143 .

mcnee@ and ekaramad@ - can either of you still reproduce this?

Indeed, I can no longer reproduce the issue in c#9 either. I also can't repro with the original steps in the description with android canary.

Just as another data point, I can't repro this on Android canary either.  ekaramad@ - would you mind confirming on your end as well?

For completeness, I tested this both on Chrome Canary and Chrome Stable. I can repro on stable but not Canary so I assume it has been fixed during.

Cool, thanks.  I'll close this based on #c10-13 and assume that James's work on  issue 848050  fixed this.