bhaumik.mca@ Thanks for the issue.

Tested this issue on Windows 10 using Dell Precision M3800 on the latest Canary 65.0.3291.0 and Stable 63.0.3239.84 and unable to reproduce this issue by following the below steps.

1. Launched Chrome and navigated to www.google.com
2. Did multi-touch, multi-gesture on the chrome window and did not observe any freeze on chrome. Chrome is rendering correctly without any issues.

Request you to update Chrome to the latest Stable and retry the issue on a new profile without any flags/extensions and update the thread with the observations.
Also if there is any crash on chrome, request you to please provide us the Crash ID from chrome://crashes, which will help in further triaging of the issue.

Thanks..

bhaumik.mca@ Thanks for the issue.

Tested this issue on Windows 10 using Dell Precision M3800 on the latest Canary 65.0.3291.0 and Stable 63.0.3239.84 and unable to reproduce this issue by following the below steps.

1. Launched Chrome and navigated to www.google.com
2. Did multi-touch, multi-gesture on the chrome window and did not observe any freeze on chrome. Chrome is rendering correctly without any issues.

Request you to update Chrome to the latest Stable and retry the issue on a new profile without any flags/extensions and update the thread with the observations.
Also if there is any crash on chrome, request you to please provide us the Crash ID from chrome://crashes, which will help in further triaging of the issue.

Thanks..

The issues can be reproduced by excessively multitouching a chrome browser tab for a few minutes. We get the issue to occur faster by touching the browser in bad ways… full palm on screen, rapid 10 finger touches, mixing gestures(swipe while pinch with two hands), 5 finger touch in a figure 8 pattern, etc. We would normally over look such crazy stress testing but this behavior is manifesting itself in production and quickly becoming a hot issue.

 

Normal behavior:

If you add monitorEvents(document) in the chrome dev console you can see the normal events that occur as you touch the screen:

VM60:1 pointerenter PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0.5, …}

VM60:1 pointerdown PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0.5, …}

VM60:1 touchstart TouchEvent {isTrusted: true, touches: TouchList, targetTouches: TouchList, changedTouches: TouchList, altKey: false, …}

VM60:1 gotpointercapture PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0, …}

VM60:1 pointerup PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0, …}

VM60:1 lostpointercapture PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0, …}

VM60:1 pointerout PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0, …}

VM60:1 pointerleave PointerEvent {isTrusted: true, pointerId: 3, width: 12.5, height: 12.5, pressure: 0, …}

VM60:1 touchend TouchEvent {isTrusted: true, touches: TouchList, targetTouches: TouchList, changedTouches: TouchList, altKey: false, …}

VM60:1 mouseover MouseEvent {isTrusted: true, screenX: 804, screenY: 241, clientX: 86, clientY: 75, …}

VM60:1 mousemove MouseEvent {isTrusted: true, screenX: 804, screenY: 241, clientX: 86, clientY: 75, …}

VM60:1 mousedown MouseEvent {isTrusted: true, screenX: 804, screenY: 241, clientX: 86, clientY: 75, …}

VM60:1 mouseup MouseEvent {isTrusted: true, screenX: 804, screenY: 241, clientX: 86, clientY: 75, …}

VM60:1 click MouseEvent {isTrusted: true, screenX: 804, screenY: 241, clientX: 86, clientY: 75, …}

 

 

Level 1:

In any website(google.com, POS webapp, etc) after an excessive amount of multi-touch activity(typical usage on POS device) we lose some of the events. We only get `touchstart` and `touchend`.

VM60:1 touchstart TouchEvent {isTrusted: true, touches: TouchList, targetTouches: TouchList, changedTouches: TouchList, altKey: false, …}

VM60:1 touchend TouchEvent {isTrusted: true, touches: TouchList, targetTouches: TouchList, changedTouches: TouchList, altKey: false, …}

 

Level 2:

Less frequent than Level 1, we lose all events received from excessive amount of multi-touch activity.

 

These issues are happening on any URL so we have eliminated problematic JavaScript in our application(happens on google.com).

The issue is reported to NOT happen on Microsoft Surface Tablet.

The issue IS happening on both our dell AIO models running windows 10.

The issue IS happening on chrome browser versions 61-63.

The issue is not reproducible on Firefox and Edge browsers.

Hi,

In Production in POS System user are using a system using a touch screen
and It is happening a lot.

In QA Environment, We are able to reproduce it using  multi-touch/gesture.


Let me know if you need more info .

Thank you
Bhaumik

Thank you for providing more feedback. Adding requester "susanjuniab@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

As per comment#6 checked the issue on reported version 62.0.3202.94 using Windows surface pro and unable to reproduce this issue with steps mentioned below.

1. Navigated to https://google.com
2. Tested by placing full palm on page, Used 10 fingers rapid touches , did 5 finger touch in figure 8 and no freeze is seen.

Comment#6 states that this issue is not seen on windows surface. As ET team doesn't have Dell laptop could someone from Inhouse team take a look into this issue.

Thanks!

Issue is with Dell Kiosk (Window's 10 OS)

To be more specific, the issue is reproducible on the Dell 9020 All-in-One desktop and Dell 7010 desktop.  These aren't laptops.

Thank you for the detailed info..

@MTV, could you please check the issue..

adding 'TE-NeedsTriageFromMTV' as these devices are not with In-house Dell 9020 All-in-One desktop and Dell 7010 desktop and we are unable to reproduce the issue on Dell Touch laptops (comment#5)

Any update on this issue?

Any updates?

 nyerramilli@
Have you heard any update from @MTV?

Any updates?

nyerramilli@
Sorry for keep asking,
Is there any update that can be shared with the customer?

Any updates?

Girard, can you help triage this?


Removing Enterprise label as this was repro'd as a touch issue.

I'm investigating - trying to tack down a Dell AIO;)

Can we send one to you? Bring one to the Atlanta Google office?

Following up - how can we get you the hardware you need?

Girard, can you share your local office shipping address so they can get you a unit?

Bryan, we will ship it back as quickly as possible. Please include return shipping address in the box and we will cover return shipping.

Thank you for the offer!

Shipping info shared in an offline thread. It seems that shipping might be challenging due to customs;)

I'm trying to get a device directly. Can we confirm that the failure is happening on Dell All in One 9020 and 7010, and also are those devices running a stock configuration?

Today we had a video conference to try to repro on the Dell All-in-One using the test harness: https://rbyers.github.io/eventTest.html

- able to reproduce and get the browser in-state
- able to reproduce on google.com
- it appears the issue is with one of the touch end events not firing, so the browser thinks that one of the touch events is still happening; when the user taps the screen to click a button, it thinks that two touch events are occurring so the click event doesn't fire and the user cannot click the button

Logs from touching screen with 2 fingers (note it's using touch 0 and touch 3 instead of touch 0 and touch 1):

touchstart: target=log touches=0-log(c=1088,398 s=1088,472 fNaN 25x25 0°) changed=0 target=0 cancelable=true 10200ms
touchstart: target=log touches=0-log(c=1088,398 s=1088,472 fNaN 25x25 0°) 3-log(c=930,380 s=930,454 fNaN 25x25 0°) changed=3 target=0 3 cancelable=true 0ms
touchend: target=log touches=3-log(c=930,380 s=930,454 fNaN 25x25 0°) changed=0 target=3 cancelable=true 90ms
touch 0 summary: dist=(0,0) max-dist=0 max-manhattan-dist=0 dur=0.09
touchend: target=log touches= changed=3 target= cancelable=true 5ms
touch 3 summary: dist=(0,0) max-dist=0 max-manhattan-dist=0 dur=0.095

One suggested workaround was to not use the chrome gestures and handle the touch events ourselves (e.g. compare start and stop location to ensure they are within the button).

@girard is going to investigate

The diagnostic logs indicate that chromium's gesture recognizer has lost track of "touch 2". This is most likely caused by windows or the touch driver dropping the touch. This is the same as issue 316085.

Potential solutions include: 
 - cleaning up chromium's gesture recognizer when a touch event disappears from WM_TOUCH* messages by generating a synthetic touchend
 - switching to pointerevents ( issue 763223 )

Async event targeting (written for OOPIF in m64) also broken possible scenarios about not ack'ing events properly. wjmaclean@ is disabling the coalescing behavior to address that issue. It may not be relevant since this issue predates that code.

I'm starting on comment 28 option 1 (cleaning up chromium's gesture recognizer when a touch event disappears from WM_TOUCH* messages by generating a synthetic touchend)

Patch for this fix is at: https://chromium-review.googlesource.com/#/c/chromium/src/+/905270

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

commit 65a5563ae004031e6d1b5868bc8cc2bd1b29c915
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Sat Feb 10 01:54:48 2018

Fix using WM_POINTER instead of WM_TOUCH

- Add runtime setting to disable/enable WM_POINTER for touch. Defaults
  to disabled in this patch. Will be enabled as a followup change.
- Fix min/max/exit buttons for touch. For unhandled events do a hit test
  and check if they are in the client area. If they are mark them as
  handled as we don't want windows to send us compatibility events if
  we've already dispatched them from the pointer events.
- Set the last_touch_or_pen_message_time for touch events via WM_POINTER.

BUG= 792892 , 763223 

Change-Id: I4350c7e84f96271b9ec27119815bf37a9461d489
Reviewed-on: https://chromium-review.googlesource.com/911752
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#535925}
[modify] https://crrev.com/65a5563ae004031e6d1b5868bc8cc2bd1b29c915/content/browser/renderer_host/legacy_render_widget_host_win.cc
[modify] https://crrev.com/65a5563ae004031e6d1b5868bc8cc2bd1b29c915/ui/base/ui_base_features.cc
[modify] https://crrev.com/65a5563ae004031e6d1b5868bc8cc2bd1b29c915/ui/base/ui_base_features.h
[modify] https://crrev.com/65a5563ae004031e6d1b5868bc8cc2bd1b29c915/ui/views/win/hwnd_message_handler.cc
[modify] https://crrev.com/65a5563ae004031e6d1b5868bc8cc2bd1b29c915/ui/views/win/hwnd_message_handler.h

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

commit a6d8dfe11405486dac1603adbd00acfb4f687159
Author: Dave Tapuska <dtapuska@chromium.org>
Date: Mon Feb 12 18:29:16 2018

Enable PointerEventsForTouch by default.

Enable flag to use WM_POINTER instead of WM_TOUCH

BUG= 792892 , 763223 

Change-Id: Icc7c352a114209a737996db618e7156887cc21a7
Reviewed-on: https://chromium-review.googlesource.com/912533
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#536136}
[modify] https://crrev.com/a6d8dfe11405486dac1603adbd00acfb4f687159/ui/base/ui_base_features.cc

As this issue is not reproducible from TE end on reported version as per comment#4, #9 and #12, it will not be possible to verify the fix from our end.

Owner @girard/ Author @dtapuska: Please help in verifying the fix.

Thanks!

Our team attempted to reproduce the issue on the canary build and, after 30 minutes, we were unable to do so.  As a control, we tested again on the stable chrome build and we were able to reproduce.  Reproducing this is somewhat inconsistent, so we cannot definitively say it's resolved, but everything looks good from our side.

We will let you know if we encounter any issues.

Dave's patch fixes this on win8, but won't address this for win7 users. 
Win7 fix is still in review: ttps://chromium-review.googlesource.com/#/c/chromium/src/+/905270

Reopening.

bryan.rosenbaum@ Do you have any Windows 7 devices? Or are they all Win8+

All of our devices are running Windows 10.

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

commit 4f3ac82fd6dfc7338f53b0c7ad356a5eb91fab7c
Author: Eugene Girard <girard@chromium.org>
Date: Mon Feb 26 15:38:36 2018

Purge unreferenced touches

This patch is a work-around for WM_TOUCH vintage drivers that sometimes
drop touchend events, confusing the chromium gesture recognizer. The
work around is to watch for touches that have disappeared from the
current touch list (and inject a simulated touchend).

Bug:  792892 
Change-Id: I7e023fc4f6484e2091746e0000b41018dd8f9cb4
Reviewed-on: https://chromium-review.googlesource.com/905270
Commit-Queue: Eugene Girard <girard@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Ilya Sherman <isherman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#539137}
[modify] https://crrev.com/4f3ac82fd6dfc7338f53b0c7ad356a5eb91fab7c/tools/metrics/histograms/histograms.xml
[modify] https://crrev.com/4f3ac82fd6dfc7338f53b0c7ad356a5eb91fab7c/ui/gfx/sequential_id_generator_unittest.cc
[modify] https://crrev.com/4f3ac82fd6dfc7338f53b0c7ad356a5eb91fab7c/ui/views/win/hwnd_message_handler.cc
[modify] https://crrev.com/4f3ac82fd6dfc7338f53b0c7ad356a5eb91fab7c/ui/views/win/hwnd_message_handler.h