Assigning to James who recently was looking at emulated touch.

Actually, in the case of remote debugging this occurs for short taps as well.

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

commit 861a8b2697787f4ace52605e053d0388c57b68f7
Author: W. James MacLean <wjmaclean@chromium.org>
Date: Mon Aug 13 20:13:48 2018

CreateGesture should use GetUniqueEventID when possible.

Creating GestureEvents with 0 for unique_touch_event_id_ causes problems
for RenderWidgetHostInputEventRouter. In TouchEmulation, CreateGesture
may be triggered for GestureShowPress and GestureLongPress, and these
events at present get a 0 value even though the correct
unique_touch_event_id is in fact available.

This CL modifies CreateGesture to set this value when it is available.
It also modifies TouchEmulator to ensure synthetic GesturePinch events
are also given appropriate touch event ids.

Bug:  867087 
Change-Id: I86186b9766714bda624581c67a88722d5794d717
Reviewed-on: https://chromium-review.googlesource.com/1169528
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: James MacLean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/master@{#582685}
[modify] https://crrev.com/861a8b2697787f4ace52605e053d0388c57b68f7/content/browser/renderer_host/input/touch_emulator.cc
[modify] https://crrev.com/861a8b2697787f4ace52605e053d0388c57b68f7/content/browser/renderer_host/input/touch_emulator.h
[modify] https://crrev.com/861a8b2697787f4ace52605e053d0388c57b68f7/content/browser/site_per_process_hit_test_browsertest.cc
[modify] https://crrev.com/861a8b2697787f4ace52605e053d0388c57b68f7/ui/events/gesture_detection/gesture_provider.cc

We were seeing the same issue in our downstream fork and it went away after applying this change.

This should now be fixed in ToT.

Starting with 861a8b2697787f4ace52605e053d0388c57b68f7 Chromium on Android devices will exit with a DCHECK
when pressing elements multiple times when the browser is still loading the page.

I am able to reproduce this by searching on 'bing.com', searching 'face' and then pressing the wikipedia article for faces multiple times, I then get the following (with the values at the end changing everytime)

```
Abort message: '[FATAL:touch_disposition_gesture_filter.cc(185)] Check failed: packet.unique_touch_event_id() != Head().front().unique_touch_event_id() (56 vs. 56)
```

This happens in v70, so might be worth triaging soon (not sure the effect it will have on release Android users) Also if anyone can point me in the right direction for fixing this would appreciate it, I am not familiar with this area so digging through it now.

thanks!

seaduboi@ - What do you mean "pressing the wikipedia article for faces multiple times"?

A longpress means that you position the simulated-touch cursor over some target (which might even just be background space on the page), click-down on the mouse button, and then wait. Usually a context menu pops up, or a text selection appears.

When I do this on the Bing results page for 'face', it works fine for me.

It's possible your experiencing a different issue, in which case filing a new bug would make sense.

@wjmaclean I am not able to use v70/master with this commit, Chromium exits pretty quickly on the DCHECK with normal browsing, I am able to get a crash every time with the repro. If I revert the commit I am not able to get the crash, it seems unlikely (but always possible!) that it is something else.

We might be talking about different platforms also. You mention 'simulated-touch cursor' and 'mouse', I am only having an issue on a physical Android device (running ChromePublicApk)

Re C#8 ... right, then the bug you are observing is not related to this issue.

Please open a new bug and provide detailed, and precise, repro steps. (E.g. I still don't know what you mean by "pressing the wikipedia article for faces multiple times").