Refactor range widgets to use a new Jetpack Compose slider

[grzesiek2010]

Work toward #7013
Closes: #6424

Why is this the best possible solution? Were any other approaches considered?

With the classic View-based UI, building a range widget using the built-in slider has been challenging. We support a no-value state, which the slider itself does not allow, so we had to work around it by hiding the thumb and adjusting styles and colors. Issue #7013 requires even more customization, so the best approach is to first switch to Jetpack Compose, which gives us much greater flexibility in customizing the layout.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

There may be some visual differences between the old and new implementations, but the behavior should remain unchanged. Please test both integer and decimal range questions carefully. Below is a list of issues we’ve encountered with these questions so far, which may be helpful:

• Vertical range widget in RTL shows incorrect lowest and highest values #5298
• Answers in range widget disappear after going to the hierarchy view or swiping when parameters start with a higher value  #5407
• Left side of the axis is cut off in range widgets #6974
• Impossible to tap the first point on the axis in the range widget #6504
• Values in range widgets a in field list are changed after minimizing the app if "don’t keep activities” is enabled #5530

Do we need any specific form for testing your changes? If so, please attach one.

Any form with range integer and decimal questions. You can find some of them linked in the issues mentioned above.

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

Managed to have a read through the Compose code and so just leaving thoughts on that for now!

[seadowg]

@grzesiek2010 as we discussed, this should now target v2026.2.x instead of master

[seadowg]

#7077 (comment)

[seadowg]

Is the main motivation for giving the individual slider items content descriptions for tests? I'm wondering whether that's the right approach. Looking at the accessibility guide for Sliders (https://m3.material.io/components/sliders/accessibility), it seems like the labelling (content description) should usually be related to the value being changed (which would be the question text in our widget case). Do you think we should switch to using other Semantics like Role for testing instead?

[dbemke]

The issue #6424 changed a bit in the PR. Now step 0.5 in a range widget shows unexpected values (the 0.5 issue doesn't occur in the store version 2026.1.0).
The issue doesn't occur with vertical appearances,

Step to reproduce:

1. Download the form.
   range.xml.txt
2. Go to "Range 11 default" or "range 12 no-ticks".

 <range ref="/stats/range11" start="1" end="10" step="0.5">
            <label>Range11 default</label>
        </range>
        <range ref="/stats/range12" start="1" end="10" step="0.5" appearance="no-ticks">
            <label>Range12 no-ticks</label>

3. Try to find 9.5 on the axis.

[WKobus]

First and last point on axis is closer to the edge than before, is it expected?

Range widget on PR version

Range widget on latest store version

[grzesiek2010]

The issue #6424 changed a bit in the PR. Now step 0.5 in a range widget shows unexpected values (the 0.5 issue doesn't occur in the store version 2026.1.0).
The issue doesn't occur with vertical appearances,

This should be fixed along with #6424.

[grzesiek2010]

First and last point on axis is closer to the edge than before, is it expected?

Yes, there is a difference between sliders in Android MDC and Jetpack Compose. In Android MDC, the thumb had some margin and was not positioned exactly at the start or end of the slider. In Jetpack Compose, this behavior has changed, and the ticks should now be placed directly at the edges, without any padding.

[dbemke]

This should be fixed along with #6424.

It seems it still occurs in some numbers.
rangeDecimalStep.xlsx.txt