WICG
Ignore layout shifts due to user-initiated content dragging
Many web applications make content resizable/draggable in a way that's triggered by the mousemove event, which at the moment Chrome implementation of the LayoutInstability API ignores w.r.t the hasRecentInput flag.
Could we spec this in a way such that mouse/pointer move events aren't ignored from being included in layout shift attribution if they're in between mouse/point down and up events?
Here's an example of a site that exhibits this problem: https://philipwalton.github.io/responsive-components/ (and a video of it happening).
This seems like a good idea. It isn't currently spec'ed that way but it shouldn't be too difficult to fix.
I am working on adding the events generated from mouse/touch dragging and resizing to be excluding inputs, I have a draft PR, https://github.com/WICG/layout-instability/pull/103. @npm1 suggested that mouse dragging and resizing may not have many user cases. I have looked at your testing page, it does have bad layout shift score when we are resizing the content window and sidebar. Do you think this layout is fairly common and it's worth adding (mouse) dragging events? Also, for touch dragging, our current approach is to keep the pointermove events in a queue and store their layout shift score, and when we see the pointerup event, we set the pointerup event to be excluding input, not accumulate the shift score. We are not able to report each pointermove to be an excluding input, because we cannot tell the if the pointermove is from touch dragging/resizing or touch scrolling. The touch scrolling is sending a pointercancel event after a few pointermove events, touch dragging does not, it is sending a sequence of pointermoves and pointerup, but we do not know when the pointercancel event is sent during touch scrolling, so we decide not to submit any PerformanceObserver entry for any pointermove events. What do you think?
