Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already report this problem, without success.

Ionic Framework Version

v7.x, v8.x

Current Behavior

The onIonInput event behavior isn't consistent with the documentation for the event. This is the current description:

The ionInput event is fired for <ion-range> elements when the value is modified. Unlike ionChange, ionInput is fired continuously while the user is dragging the knob.

The actual behavior is that the event is triggered whenever the knob is moved a single pixel (after an initial "sticky" behavior) instead of it triggering whenever the actual value is modified, causing a lot of events being triggered for absolutely no reason. The second part "is fired continously" is ambivalent and could match either expectation.

Expected Behavior

I would expect the event to trigger only when the value is modified rather than when the knob is moved.

Steps to Reproduce

1. Open the reproduction Stackblitz link.
2. Open the browsers developer console.
3. Drag the slider a short distance until the first ionInput event is triggered, then keep moving the knob a short distance and see how the event continues to be logged even without the value changing.

Code Reproduction URL

https://stackblitz.com/edit/umlmf6?file=src%2Fmain.tsx

Ionic Info

Ionic:

Ionic CLI : 7.2.0.

Utility:

cordova-res : not installed globally
native-run : not installed globally

System:

NodeJS : v20.9.0
npm : 10.1.0
OS : Windows 10 (actual version 11)

Additional Information

As I see it there's 3 possible solutions:

1. Only trigger the event when the value has changed from it's previous value as the documentation says.
2. Same as 1 but only when snaps: true.
3. Update the documentation to not specify when the value is modified but rather something like when the knob is moved.

I believe 1 is the preferable solution, but it might be considered a breaking change and so 2 is a reasonable compromise as there's no practical nor visual updates between value-changes when snaps: true making it a non-breaking change.

3 is by far the least preferable solution in my opinion as this issue is not only a documentation error but the current implementation also carries an unnecessary performance impact (again, at least when snaps: true).