1143518 - Remove the TryCapture codepath for touch events

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

Attachment: Remove TryCapture and friends

TabParent has the notion of an "event capturer" which was added a long time ago. This allows the widget code to dispatch touchmove events (and only touchmove events) directly to a child process and avoid having the events go through the main-process event dispatch flow. This, as far as I know, was done purely for performance reasons, to allow lower-latency scrolling.

Now that the events go through APZ without touching the main thread, we have even better perf characteristics, and the event capturer stuff can be removed. It still provides some small perf benefit, but to balance that out it involves some hacky state management which is error-prone and has led to bugs/assertion failures. Also, this short-circuiting of touchmove events means that any window-level touchmove listeners in the main process do not get triggered when the events are going to a child process. touchstart and touchend listeners window-level listeners in the main process *do* get triggered, which is even worse because the listeners get an inconsistent view of the events. Eliminating the event capturer path will fix that.

I have bug 1116579 on file for reimplementing this direct-dispatch-to-child behaviour in a more APZ-friendly way but I'd like to defer finishing it up and landing it until we can see some measurable benefit from it.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8577810 [details] [diff] [review]
Remove TryCapture and friends

If we can get rid of this horrible hack without significant perf regression, great!

Comment 2

[Kartikaya Gupta (email:[e-mail])]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3d8fb4f958b5

Comment 3

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3d8fb4f958b5