If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Don't send touchmove gecko events if the touch point positional data hasn't changed

RESOLVED DUPLICATE of bug 907098

Status

()

Core
Widget: WinRT
RESOLVED DUPLICATE of bug 907098
4 years ago
4 years ago

People

(Reporter: jimm, Assigned: jimm)

Tracking

26 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6749
http://mxr.mozilla.org/mozilla-central/source/content/events/src/Touch.cpp#124

The Equals check here doesn't check message type, so if the positional data in the event of the first touchmove is equal to its corresponding touchstart the event will get dropped by presshell since haveChanged will be false -

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6768

There are a couple options here, update Equals, or set the appropriate flags here - 

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6764

I'm leaning toward updating Equals.
(Assignee)

Comment 1

4 years ago
Created attachment 801226 [details] [diff] [review]
fix v.1
(Assignee)

Comment 2

4 years ago
Looking over the w3c spec I'm thinking we should fix this down in widget instead. From the spec - 

"For the touchstart event this must be a list of the touch points that just became active with the current event. For the touchmove event this must be a list of the touch points that have moved since the last event. For the touchend and touchcancel events this must be a list of the touch points that have just been removed from the surface."

For changedTouches this specifically calls out movement with touchmoves. Since we depend on the result of the first delivered touchmove, looks like we'll have to add filtering down in widget to compensate on top of the filtering already happening in presshell.
(Assignee)

Updated

4 years ago
Component: DOM: Events → Widget: WinRT
Summary: First touchmove event after a touchstart often gets dropped by presshell (and the preventDefault result along with it) → Don't send touchmove gecko events if the touch point positional data hasn't changed
The platform fix might cause some problems with sites like Google Maps, that use touchmove events to decide if something if a tap or a drag (i.e. if they get ANY touchmove events, they switch to dragging). We filter those in widget on Android to fix that problem.
(Assignee)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 907098
You need to log in before you can comment on or make changes to this bug.