Open Bug 510924 Opened 11 years ago Updated 9 months ago

setCapture for touch events

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows 7
defect
Not set

Tracking

()

People

(Reporter: Felipe, Unassigned)

References

Details

(Keywords: perf)

In Bug 503943 a setCapture/ReleaseCapture API for mouse events is being implemented. We should be able to use that for the touch events too.
Blocks: 548100
On Gaia, there is a lot of use cases where something is moved on the screen accordingly to user touch that does not go through AsyncPanZoom.

In the current version of Gaia, thinkgs like swiping between homescreen panels, flipping the images in the gallery app, showing the notification tray, or even sliding between apps with the edge gestures features.

A number of time I have seen nsLayoutUtils::GetFrameForPoint / nsLayoutUtils::GetFrameForAreas in the profile when doing so. I may be wrong but those calls likely comes from the Fluffing code at http://mxr.mozilla.org/mozilla-central/source/layout/base/PositionedEventTargeting.cpp#363 and mxr.mozilla.org/mozilla-central/source/layout/base/PositionedEventTargeting.cpp#391

Most of the code looking for which element to forward the event too could be avoided if the setCapture/releaseCapture API for touch events will be implemented as we won't go into the branch that calls all those methods (http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#6709)
Blocks: milk-flow
Keywords: perf
OK. Let's forgot my last comment. I spent a bit of time debugging that and it seems like the issue is only on the system app of Gaia and not related to touch events, as any touch move already bypass fluffing once the frame has been selected for touch start. The system app receive touch moves at every moves, I will open a separate issue for that.
FTR the real bug is bug 1005815. Sorry for the noise here.
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.