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

Status: RESOLVED DUPLICATE of bug 907098

(Core Graveyard :: Widget: WinRT, defect)

Description

[Jim Mathies [:jimm]]

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.

Comment 1

[Jim Mathies [:jimm]]

Attachment: fix v.1

Comment 2

[Jim Mathies [:jimm]]

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.

Comment 3

[Wesley Johnston (:wesj)]

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.