I was discussing this with Matt today but couldn't craft a test case to exercise this. The question is basically the one in the summary. While working on APZC stuff I didn't see anything that updates input events for animations in the compositor. So I suspect that when a CSS animation is handled by OMTA, input events will only get dispatched to the element being animated at either the start or the end position of the animation. If anybody has examples of transform animations where the element is translated or something this should be easy enough to test. All my test cases ended up not using OMTA though. This has implications both for correctness on its own, and how we will end up handling input events in the multi-APZC world.

As per IRC discussion with dzbarsky I guess the answer to the question is "yes, input events will go to the right place". 16:55:40 kats: dzbarsky: if you click on an element that is in the middle of a OMTA animation, will it trigger listeners attached to that element? 16:55:50 kats: (say the animation is moving a div from (0,0) to (500,500)) 16:55:57 dzbarsky: kats: so the way this works is 16:56:09 dzbarsky: kats: when we have omta, we try to throttle main thread style flushes 16:56:27 dzbarsky: kats: but when we have an input event, we force a flush on the main thread 16:56:39 dzbarsky: which will send a transaction to the compositor 16:57:02 kats: hmm 16:57:26 kats: so if you get an input event, that basically forces an update in gecko such that it knows where the element is in the middle of its animation? 16:57:33 dzbarsky: kats: yes