Open Bug 1221775 Opened 9 years ago Updated 2 years ago

Reduce time to touch activation by synthesizing a fake touchmove

Categories

(Core :: Panning and Zooming, defect, P3)

defect

Tracking

()

People

(Reporter: kats, Unassigned)

References

Details

(Keywords: perf, polish, Whiteboard: [gfx-noted])

The basic problem is that the code in ActiveElementManager only applies the activation on an element once it receives the StartTouch notification from APZ, which only happens after the input block has started being processed. Often this means that until the touchmove is dispatched to content and the response processed, the activation won't happen. If the device has less sensitive hardware and doesn't send a touchmove soon after the touchstart (e.g. the case on Flame, if the user isn't moving their finger agressively) then the activation delay can be large. In bug 1037066, Doug attempted to solve this problem by faking a touchmove event right after the touchstart, so that the content response would arrive sooner and the activation would happen sooner. However that was backed out for breaking clicking in cases where content was preventDefault'ing the touchmove in an attempt to prevent panning. This came up again as part of a discussion in bug 1141127, and we realized that the fake touchmove should be ok to do in cases where the target is not pannable. (In the case where the target is pannable, the code in bug 1141127 causes touchmove events to be dropped, so we shouldn't put them back by inserting fake touchmoves).
Keywords: perf, polish
Whiteboard: [gfx-noted]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.