bug(mat-slider): mobile device scrolling can break slider internal state

[wagnermaciel]

Is this a regression?

• [ ] Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

Scrolling on a mobile device can break the mat-slider's internal state such that the slider still thinks it is in an active dragging state when it is not

The root cause of the issue is that for some reason, the pointerup event never gets triggered when the user stops scrolling

Reproduction

• Visit any webpage that has a mat-slider
• Scroll down with the pointerdown originating from the mat-slider
• Stop scrolling

Expected Behavior

The mat-slider is in an inactive state

Actual Behavior

The mat-slider is still in the active state

Environment

• Angular: 17
• CDK/Material: 17
• Browser(s): chrome
• Operating System (e.g. Windows, macOS, Ubuntu): ios

[wagnermaciel]

Current workaround for teams is to set touch-action: none on the mat-slider.

[wagnermaciel]

Update:

https://github.com/angular/components/pull/28176 does not fix the issue. There is a way to trigger pointercancel but continue dragging the input type="range"

Right now I believe change is the best (only?) event that indicates whether dragging has ended - not pointerup + pointercancel + pointerout + etc.

The problem I'm running into now is: When dragging, arrowing triggers a change event, which is indistinguishable from a change event triggered by pointerup. As far as I can tell, there are only 2 ways to solve for this:

1. Diverge from the native input type="range" behavior and disable arrowing when the user is dragging
2. Listen for pointerup and keydown events and store which one happens before a change event so we can determine whether the change was triggered by an arrow key or drag end.

[wagnermaciel]

Update:

Listening for change events doesn't work because they are not guaranteed to be the last event that fires. If a user drags a slider thumb but then returns it to its original value, the change event will not fire since the value has not changed.

[wagnermaciel]

I discussed this with the team and concluded that the small divergence of setting touch-action: none is ok.