-
Bug
-
Resolution: Unresolved
-
P2: Important
-
None
-
6.11.0 FF
-
None
-
Debian testing, Plasma Wayland
Qt-self-compiled from git dev (qtbase as of 96f089dfb39241bdc39f54c9183c2912f2d17f3a, qtdeclarative as of 7ca76d3799b4081f64c4dc2877b52dcc4d03e828)
Currently, the QML ScrollBar implements the QAccessibleValueInterface (via its base classes), but doesn't report the actual scroll position, so the value (always 0.0) is useless/misleading. Instead, the actual scroll position should be reported.
Sample steps to reproduce on Linux (using the AT-SPI2 Value interface):
- build and run the given sample program (based on the one from QTBUG-139833):
import QtQuick import QtQuick.Controls import QtQuick.Layouts ApplicationWindow { visible: true title: qsTr("ScrollView example") ScrollView { anchors.fill: parent contentHeight: columnLayout.implicitHeight contentWidth: columnLayout.implicitWidth ColumnLayout { id: columnLayout Repeater { model: 100 Text { Accessible.name: text Accessible.role: Accessible.StaticText Layout.fillWidth: true text: "Element %1".arg(index) } } } } }
- run Accerciser and select the object for the vertical scroll bar in the application's accessibility tree
- using Accerciser's IPython console, query the current and min/max value:
In [2]: value = acc.queryValue() In [3]: value.get_currentValue() Out[3]: 0.0 In [4]: value.get_maximumValue() Out[4]: 0.0 In [5]: value.get_minimumValue() Out[5]: 0.0
Actual result
0.0 is reported for all values.
Expected result:
Since the scroll bar is not at its maximum position (there are elements out of the range that can be made available by scrolling further down), the maximum value should be greater than the current value, and scrolling should be possible by setting a larger value using the API.
| For Gerrit Dashboard: QTBUG-140673 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 680392,1 | a11y: Report + allow modifying QQuickScrollBar position | dev | qt/qtdeclarative | Status: NEW | +1 | 0 |