Hmm, able to repro on pixelbook @ 70.0.3504.0 and on Linux @ 70.0.3514.0 but not on Linux 68.0.3440.106 so this is a regression. A bisect would be helpful.

Ping QA team - can we get a bisect? Changing labels in case that helps visibility.

Looks like this is the page detects TouchEvents (in raphael.js) and installs a touch handler only if they're available.

It seems this was an intentional change in Chrome to make the TouchEvent API disabled by default on Desktop. See the intent thread for details: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KV6kqDJpYiE

The solution from the thread is to use window.TouchEvent or pointer events.

I'm not sure I agree with this assessment. I went into chrome://flags in enabled "Touch Events API" on ChromeOS 70 and I still see the issue. And while Raphael does use different handlers depending on whether touch is supported or not, it detects touch properly.

This issue is caused by the experimental "overflow history navigation" being set to "simple". If I disable this flag the issue goes away.

The main issue I see is that the touchmove listener is attached to the document, which would as of Chrome 56 force it to {passive: true}, so the event couldn't be cancelled which would prevent the overscroll (hopefully). I pulled the latest version of Raphael and set the listener to {passive: false} explicitly, and the event still can't be cancelled, so you still the the overscroll. That doesn't seem correct.

>  And while Raphael does use different handlers depending on whether touch is supported or not, it detects touch properly.

That's not what I'm seeing. On a fresh profile in Chrome 71.0.3559.6 with everything set to default (Touch Events API: disabled, Overscroll history nav: simple) - the page in the report doesn't register any touchstart handlers anywhere. If I enable Touch Events API and restart the browser (make sure you restart), touchstart handlers are registered on the |path| elements and the page works as expected.

> The main issue I see is that the touchmove listener is attached to the document, which would as of Chrome 56 force it to {passive: true}, so the event couldn't be cancelled which would prevent the overscroll (hopefully). I pulled the latest version of Raphael and set the listener to {passive: false} explicitly, and the event still can't be cancelled, so you still the the overscroll. That doesn't seem correct.

It looks to me like the document-level listeners are only attached after a touch on one of the path elements. If the touchstart isn't registered on those then we'll never register the document-level one.

You're right that if |passive| isn't specified on the document-level one then they can't preventDefault. The library should add passive: false on those listeners and I've confirmed that calling preventDefault() on non-passive touchmoves from the document does prevent history navigation.

However, if I have Touch Events enabled and the touchstarts are registered on the |path| elements, everything works correctly for me. I suspect most of the work actually happens on the |path|-registered listener which is passive by default.

Thanks for the feedback! I did forget one thing, I did change a line in Raphael from this:

  supportsTouch = ('ontouchstart' in g.win) || g.win.DocumentTouch && g.doc instanceof DocumentTouch

to this: 
  
  supportsTouch = (window.TouchEvent) || ('ontouchstart' in g.win) || g.win.DocumentTouch && g.doc instanceof DocumentTouch

And I have one other complicating factor. I was testing on a Samsung Chromebook Plus, which is affected by this issue: 

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

I do have access to a different ChromeBook and was able to verify that making the touch listener "active" and updating the touch detection in Raphael things are working properly and no overscroll navigation happens.

I'll see if I can get these updates into Raphael so others don't run into these same issues.

Thanks again!

Yeah, that device makes passive the default. This is known to break some content but the performance trade-off was deemed worth it. Being explicit about passive/active is best so getting that into the library would be the right solution.

Cheers.

 Issue 896652  has been merged into this issue.