Opened 7 years ago

Last modified 2 years ago

#16499 assigned defect

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

Reported by: Thomas Bachem Owned by: dylan
Priority: low Milestone: 1.14
Component: Dojox Version: 1.8.2
Keywords: Cc:
Blocked By: Blocking:

Description

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()?

Attachments (1)

dojoxGestureRemovePreventdefault.patch (352 bytes) - added by Thomas Bachem 7 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 7 years ago by bill

Owner: changed from Adam Peller to Evan
Status: newassigned

comment:2 Changed 7 years ago by bill

Where's the patch?

Changed 7 years ago by Thomas Bachem

comment:3 Changed 7 years ago by Thomas Bachem

Patch attached now.

comment:4 Changed 7 years ago by bill

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

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.

comment:5 Changed 7 years ago by 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.

comment:6 in reply to:  5 Changed 7 years ago by 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.

comment:7 Changed 6 years ago by cwgorman

Hello,

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

Thanks, Cory

comment:8 Changed 5 years ago by 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.

comment:9 Changed 4 years ago by dylan

Milestone: tbd1.11
Owner: changed from Evan to dylan

comment:10 Changed 4 years ago by dylan

Priority: undecidedlow

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.

comment:11 Changed 4 years ago by dylan

Milestone: 1.111.12

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.

comment:12 Changed 3 years ago by dylan

Milestone: 1.121.13

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

comment:13 Changed 2 years ago by dylan

Milestone: 1.131.14
Note: See TracTickets for help on using tickets.