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)
Change History (14)
comment:1 Changed 7 years ago by
Owner: | changed from Adam Peller to Evan |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
Changed 7 years ago by
Attachment: | dojoxGestureRemovePreventdefault.patch added |
---|
comment:4 Changed 7 years ago by
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 follow-up: 6 Changed 7 years ago by
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 Changed 7 years ago by
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
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
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
Milestone: | tbd → 1.11 |
---|---|
Owner: | changed from Evan to dylan |
comment:10 Changed 4 years ago by
Priority: | undecided → low |
---|
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
Milestone: | 1.11 → 1.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
Milestone: | 1.12 → 1.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
Milestone: | 1.13 → 1.14 |
---|
Where's the patch?