Can confirm on Linux 70.0.3538.77. Trace attached

Deleted: trace_photo-compare.json.gz 8.4 MB

trace_photo-compare.json.gz 8.4 MB Download

Taking a look - I'm not sure I understand what's happening. It looks like the touchmove events are being sent as NonBlocking but the event listener on the DIV containing the image is specified as |passive: false|.

Additionally, it looks like even after the touchmove is dispatched from the compositor thread, it can take ~10 begin main frames until it's processed. Someone more familiar with this should take a deeper look. Marking as untriaged so we remember to take another look.

+dtapuska@: Any idea why the touchmoves over a non-passive event handler are being dispatched as non-blocking? Or why it can take a long time for a touchmove to be handled on a relatively idle main thread?

Ping: Dave, Navid, any thoughts as to what's going on here? I'm not super well versed on the touch event processing pipeline

Since it doesn't seem to be maxing out the CPU I'd look at the scheduler. It might be throttling setTimeout events causing jankiness. I believe that information should be in a trace if it is throttled.

+altimin@. Trace with renderer.scheduler category attached.

Deleted: trace_verge_touch.json.gz 9.1 MB

trace_verge_touch.json.gz 9.1 MB Download

I'm not sure what to look for in the scheduler trace so maybe Alexander can take a look.

But it does seem fishy to me that the photo slider on the page has |passive: false| touch handlers but we're sending the events as non-blocking (and immediately ACKing them as IGNORED). Is that expected? Presumably when we get non-blocking (that does mean passive, right?) touches in the renderer, we forward them to main lazily/throttled?

I believe the back-forward feature on Chrome book is interfering with this. As soon as you add a good touch action to the picture (like I guess pan-y is what they want) it will be smooth. CC Sahel as she is more familiar with that back/forward gesture.

+chaopeng@ since he's implemented gesture based navigation and may have some insight.

Interesting that touch-action does it. They have non-passive listeners registered though, I would expect us to block turning the touches into scrolls until they're ACKd. Perhaps the page isn't preventDefaulting the horizontal touches? Would that cause us to start scrolling and then throttle the |TouchMove|s we send to the page?

>Interesting that touch-action does it. They have non-passive listeners registered though, I would expect us to block turning the touches into scrolls until they're ACKd.

With passive touch event handling if the first touch move in the sequence is not prevented by default, the rest of the touch move events in the sequence are none blocking.

Like Nzolghadr@ mentioned in comment #9 adding touch-action: pan-y; to the slider seems the right approach to me. Similar issue happens if the user tries to touchscreen pinch zoom on the slider, or when the user scrolls vertically on the slider but the touch moves have a very small horizontal delta.

Setting overscroll-behavior-x:contain/none for the slider div also prevents triggering gesture navigation when the user horizontally scrolls on the div.

Thanks for the info. I'd chalk this up to WAI and a site-issue since adding an event listener that preventDefaults the TouchMoves fixes the issue. The even better solution for them would be touch-action. In any case, there's no action for us here.