[patch] [cla] dojox/gesture prevents native scrolling on touch devices

[Thomas Bachem]

Native scrolling (e.g. via -webkit-overflow-scrolling: touch) on an element or any descendant that dojox/gesture listens on gets blocked by e.preventDefault(); in the _process function (line 267). Is that by intention? If not, can't we just get rid of the call to preventDefault()?

[bill]

Where's the patch?

[Thomas Bachem]

Patch attached now.

[bill]

OK, thanks!

PS: presumably when the gesture is being processed we want the preventDefault() call, so it might not be as simple as just removing that line. But it's Evan's code so he should decide.

[Thomas Bachem]

I guess there's a reason for that call of course, but we need a way to prevent the preventDefault() for gestures then, as it's irreversible once called.

[Evan]

Replying to thomasbachem:

I guess there's a reason for that call of course, but we need a way to prevent the preventDefault() for gestures then, as it's irreversible once called.

Thanks, if I remembered correctly, gesture need that line to work, let me take a look to figure out the detail reason and if can address this issue.

[cwgorman]

Hello,

Have there been any updates regarding this? This defect is causing some problems in a project I'm working on.

Thanks, Cory

[psbucky]

Possible workaround??

The use case seems to be that you want swiping in one direction to work "normally," but capture swiping in the other direction (maybe a tab container where you want to swipe left and right to change tabs, but otherwise scroll up and down the page as usual)?

In this case, maybe doing window.scrollBy(0,dy) from the swipe event might be a stopgap. It wouldn't be native, but it might help alleviate the "dead phone" effect trying to swipe through the tab container.

[dylan]

I hope to get to this ticket in time for 1.11 (setting a deadline of end of January). If not, this will get moved to 1.12.

[dylan]

Ok, after massive triage, ended up with about 80 tickets for 1.11 and 400 or so for 1.12. That's a bit unrealistic, so first I changed all 1.12 to 1.13 (with the plan to move some forward to the new 1.12. Now, I'm moving some of the 1.11 tickets that are less likely to get done this month without help to 1.11. Feel free to help out in January if you want to see this ticket land in 1.11.

[dylan]

Ticket planning... move current 1.12 tickets out to 1.13 that likely won't get fixed in 1.12.