It is related to many posts:

https://bugs.chromium.org/p/chromium/issues/detail?id=647038

https://productforums.google.com/forum/m/?utm_medium=email&utm_source=footer#!msg/chrome/13heHHOuMYA/455_N7JXAwAJ

I found this in the documentation, we assume that this is happening:

" 
When Javascript calls preventDefault on a touch release, we need to make sure that no gesture events are created, but we also need to ensure that the GestureRecognizer knows that the *associated finger isn’t down any more*. To accomplish this, we turn the touch release into a touch cancel event.
"

It's really hard to tell what's going on from your description.  Any chance you can come up with a way to reproduce the issue from a web page (as opposed to Chrome app in Kiosk mode, or via electronic)?  That would enable the team to debug your issue in detail.

Note that Chrome 53 and 54 are somewhat old at this point, Chrome 56 is the current stable version.   Issue 670039  describes a problem fixed in Chrome 56 which I believe could cause thesymptoms you describe.  So verifying whether you can reproduce the issue in Chrome 56+ is probably the first thing to do.

Other than that, I don't have any ideas for what could be causing the unintended pinch-zoom.  But there are some common mistakes that could lead to scrolling stopping.  Are these components handling touchstart/touchmove events themselves to drive some form of scrolling?  Or is this the browser's built-in scrolling (with draggable scrollbars etc.)?  

My colleague posted this link, chrome 56, single finger pinching:
https://bugs.chromium.org/p/chromium/issues/detail?id=689881

It is hard to reproduce at all, 'luckily' we have one device that can repro in a few minutes. 

I studied the source code and there isn't much tracing in the gesture events. 

What we could do is someone sends us a patched chrome/electron binary with ch54-56 with traces in the gesture/queue/cancel events to confirm that some touchup is lost.

I found this code below, if I am right a trace on this point could help a lot:

void TouchSelectionController::HandleTapEvent(const gfx::PointF& location,
                                                  int tap_count) {
/* PUT A TRACE HERE "HAndleTapEvent tap_count = ", tap_count  */

  if (tap_count > 1) {
    response_pending_input_event_ = REPEATED_TAP;
  } else {
    response_pending_input_event_ = TAP;
  }
}

BTW it would help if the traces would have some id like [688948] to filter them easily in the file.

Our application is using polymer and pouchdb. It it could help we can give git access to the project, but as said you need a touchscreen and 'luck' to reproduce.

I confirm  issue 670039  - when we refresh the page to a page with single scrolling element, the element is not scrolling. Refreshing the page does not help.

To be more clear on my previous post:
- in electron pinch is disabled 
- in chrome we run the application without any option, that is why we discovered the scroll is not stopped, but the screen in fact is pinching.

Hi bovertis@gmail.com:

We need more clarification on affect versions:
-  Issue 689881  on Chrome 56 seems a different one. We will look into it separately.
- You confirmed seeing  issue 670039 , which has been fixed in Chrome 56. Please post you Chrome version (from chrome://version page).

Hi mustaq, 

it happens on electron (c53 and c56), chrome 56 and 57 beta.
We are quite sure a 'finger stays on the screen' in all cases. Both in chrome and electron we are be able to reproduce the same way.

Rene

 Issue 689881  has been merged into this issue.

See attached video in  issue 689881  - shows the problem clearly. Looks like hte gesture recogniser is getting confused. Tim, any idea how this might be happening? Where could we add some tracing/debugging to help determine the cause?

+sahel, lanwei

This is where the code lives.
https://cs.chromium.org/chromium/src/ui/events/gesture_detection/scale_gesture_detector.cc?rcl=6adcf35d6ca7f2c4cfb6536880e996fc877a50d1&l=69

Does this reproduce across multiple devices?
We've seen bugs in the WM_TOUCH APIs, where sometimes windows doesn't release the touch points. See issue 316085.

We're currently working on adopting the WM_POINTER API, which should fix driver issues like this.

Maybe good to know: when we connect a keyboard to the touchscreen and hold the ctrl-key, a single finger pinches. 

Could there a relation with double-tap-hold pinch (Android chrome)?

If someone can send us a patch of table 56 with tracing we could analyze it and reply with log when chrome is pinching instead of scrolling.

We will try to get our app running on public IP and let you know privately.

Suggestion: parameter disable-multi-touch to disable all multi-touch features. In kiosk applications (mode) pinch is mostly disabled anyway. 

Rene

Lan, could you forward your WM_TOUCH test app, so folks can determine whether Windows thinks there are multiple active pointers?

we tested this by opening another Chrome and it was scrolling. But it seems multiple pointers are handled per window, not per monitor. 

Btw I send a private mail with our test IP, but our internet is already down for a few hours.

Yeah, your test IP seemed unresponsive when I tried half an hour ago and now. We need to take a look at the page to dig further.

We are back online, the ip should work.

It's extremely surprising to me that Ctrl-Finger can cause zooming.  Where the heck could that be coming from?  We've got code that turns Ctrl-Wheel events into browser zoom, right?  Is it possible this is a strange touch device that's emulating mouse scrolling by sending wheel events for touch dragging?  What do you get on a test page like http://rbyers.github.io/eventTest.html when you Drag and Ctrl-Drag on the page?

Ctrl-finger is not repro anymore. We see a difference between lenevo and iiyama that iiyama is not accelerating when ctrl is down, so scroll if following you finger but not animating.

Our internet is up you can connect to our application through the link I send by e-mail. 

I will check the eventTest app.

I am not sure how to do a Drag test on the eventTest.html.

I did some other testes, here the events that were returned:

MouseMove:
pointermove
mousemove

FingerMove (with Touch-action: [None} checked:
pointermove
touchmove

FingerMove (with Touch-action: {none] unchecked:
touchmove

For your FingerMoves, did you have "mouse events" enabled through eventTest.html>Config? With this setting, a FingerMove would fire "wheel"/"mousewheel" events if the touch device is emulating mouse scrolling thru wheel events.

Please also check Ctrl-FingerMove.

btw, your app doesn't seem to load the affected part of the page (<blank-page>), fails with "Can't connect so the server".

Hi Mustaq, 

with mouse events enabled (and all other checks disabled) no events are fired on fingermove and ctrl-fingermove.

Bad luck our app was not working, we teted everything and it is up and running. I will send you some direct contact details privately so we can assist and/or teamviewe the screen.

Rene

I think we can rule out the possibility that the device is sending wheel events.

Still can't see a working app. Only the top part of the page load. The bottom part fails to connect then after several minutes brings up a "Welkome bij de" page.

For those testing the app/link, please wait 5 till 10+ minutes first time. Once the data is cached you can start the app in seconds.

This week will will try a different touchscreen (not iiyama) on the same hardware and see if we get any diff. 

Any change we can get a patch chrome.exe that dumps the events to disk?

Unfortunately failed to load after 20+ minutes of wait.

You can build your own builds and make it dump any event you choose. Here is the build instruction:
  https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md
and some debugging tips:
  https://www.chromium.org/developers/how-tos/debugging-on-windows
  https://www.chromium.org/blink/getting-started-with-blink-debugging

---

Given that we haven't get any other bugs around this behavior (which you are seeing even on Chrome 54), I am confident that it is not a Chrome bug. So closing the bug.