New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 812656 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Feature



Sign in to add a comment

Add API to disable 2-finger gestures with overflow: scroll

Reported by tou...@gmail.com, Feb 15 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce the problem:
1. Create a horizontally scrolling anything (like a div with overflow auto, and have content that is wider than the viewport).
2. With a browser history, scroll to one edge.
3. Gesture swipe with two fingers, to trigger back button/forward button behavior (macOS or Chrome OS, maybe others)

What is the expected behavior?
I'd like some way to cancel that within horizontally scrolling content areas. event.preventDefault, or event.stopPropagation doesn't do it (it should).

Alternatively, if the element has overscroll at all, it should just disable swipe, since users will be trying to scroll in that area. It already does this correctly if there is enough scroll left on the edges. Why does it change behavior when you are at the edge? This is a design flaw.

What went wrong?
There doesn't appear to be any way to cancel it.

Did this work before? Yes I'm not sure, but there are some (many) SO answers that suggest there used to be a way to disable this (with a lengthy workaround) - none of the dozens of SO answers work any more.

Does this work in other browsers? N/A

Chrome version: 64.0.3282.140  Channel: n/a
OS Version: OS X 10.13.3
Flash Version: 

There are dozens of posts all over the net of developers trying to find ways to turn this awful behavior off. LIke this one: https://stackoverflow.com/questions/15829172/stop-chrome-back-forward-two-finger-swipe/46439501#46439501

None of the solutions are good enough. On my app, we have a horizontally scrolling toon selector. It's natural for kids to use left/right scrolling behavior with 2 fingers, but when they are at the edge of the content, it causes them to navigate away from the screen. onbeforeunload doesn't even work.

Omitting some way to disable this behavior is an error of design. It means we can't use horizontally scrolling content at all without silly workarounds, like pivoting scroll behavior, and other silly workarounds. It should be a setting - disable swipe in this element (or for this page). The omission of a way to handle this gracefully is a bug.

https://www.makebeliefscomix.com/Comix/
 
Labels: Needs-Bisect Needs-Triage-M64

Comment 2 by tou...@gmail.com, Feb 16 2018

So, I found a way to cancel it. Looks like you can do event.preventDefault() on wheel events, but you have to do it more often than just when the content is precisely at hte edges.

I ended up creating a wheel handler which always calls preventDefault(), and sets the scroll position manually. This seems to prevent the gesture behavior (at least on macOS).

Sorry for the noise.
Cc: sindhu.chelamcherla@chromium.org
Components: Blink>Scroll
Labels: Trigaed-ET Needs-Feedback
As per comment#2 issue seems to be fixed.

@Reporter: Please let us know if we can close this issue as per comment#2. If issue is still reproducible please provide us a sample URL/test file to test this issue.Also if possible please guide us with a video on reproducing this issue. This would help in better triaging of the issue.

Thanks!

Comment 4 by tou...@gmail.com, Feb 16 2018

I found a way - but it's not optimal. In order to prevent the behavior, I have to completely disable the browser scroll handling, and use Javascript to do it. I did just that in the character chooser on this webpage: https://www.makebeliefscomix.com/Comix/

So this would change then from a bug I suppose, to a feature request. There should be a simple declarative, and performant way to disable that gesture within horizontally scrolling regions.

If that's outside of the scope of this report, please close the issue.
Project Member

Comment 5 by sheriffbot@chromium.org, Feb 16 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "sindhu.chelamcherla@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
Labels: -Needs-Bisect -Type-Bug-Regression FoundIn-66 M-66 Type-Feature
Status: Untriaged (was: Unconfirmed)
As per comment#4 considering this issue as Feature Request. Hence marking this issue as Untriaged and removing Needs-Bisect label.

Could someone from Blink>Scroll team please have a look at this issue. 

Thanks!! 
Cc: majidvp@chromium.org
Labels: Needs-Feedback
Have you tried:

https://developers.google.com/web/updates/2017/11/overscroll-behavior
https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior

This API was designed for that purpose.
Cc: dtapu...@chromium.org
Status: WontFix (was: Untriaged)
API for overscroll behavior exists should deal with this situation the reporter identified.

Sign in to add a comment