| Summary: | Scrollbar handle size is incorrect until the view is scrolled at all | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Patrick Silva <bugseforuns> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | me, nate, notmart |
| Priority: | NOR | Keywords: | qt6 |
| Version: | Master | ||
| Target Milestone: | Not decided | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=476483 | ||
| Latest Commit: | https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/a004faa08d905615fed5712c650de33378e53ebe | Version Fixed In: | |
| Sentry Crash Report: | |||
| Attachments: | screen recording | ||
Can confirm. Seems like a bug in Kirigami.ScrollablePage.
Trivially reproducible example code:
import QtQuick 2.5
import QtQuick.Layouts 1.1
import org.kde.kirigami 2.13 as Kirigami
Kirigami.ScrollablePage {
width: 500
height: 500
ColumnLayout {
Repeater {
model: 100
Rectangle {
width: 50
height: 50
color: "green"
}
}
}
}
I believe it's a bug in qqc2-desktop-style or QtQuick.Controls, as similar thing occurs in other places as well. I noticed it as early as during ScrollBar rework (that "mega-fix" MR) in January. Basically, some ScrollBar's metrics properties are stalled. They don't notify of their changes, but if you emit them by calling associated signals manually, everything snaps into place. Might be a Qt 6 regression as well. Just look at this comment: > // Note about comma, operator: including visualPosition in this > // expression help it propagate signals when needed; otherwise in > // Qt 6 scrollbar might get stuck being too large, and clip out. > minimum: 0 > maximum: (void controlRoot.visualPosition), > Math.round(length / Math.max(0.001, controlRoot.visualSize) - length) > value: Math.round(length / Math.max(0.001, controlRoot.visualSize) * Math.min(1 - 0.001, controlRoot.visualPosition)) https://invent.kde.org/frameworks/qqc2-desktop-style/-/blob/f3dd8b22c83f896abfbfd0c03443c4f12e93e08c/org.kde.desktop/ScrollBar.qml#L219-225 Whichever component is at fault here, I bet it's not Kirigami. Unless… ListView/Flickable really fails to recalculate its content height with all those bindings and re-assignments during initialization… in which case it would still be QtQuick's fault. Git commit a004faa08d905615fed5712c650de33378e53ebe by ivan tkachenko. Committed on 02/09/2023 at 15:38. Pushed by ratijas into branch 'master'. ScrollBar: Fix size being initially stuck on Qt 6 Due to a bug in Qt, explicit binding to ScrollBar::size is required to help it notify the binding to reevaluate. According to my and Noah's investigation, size can indeed change in a way that affects getter of visualSize, but only signal sizeChanged will be dispatched, thus leaving visualSize hanging in a limbo state when querying it manually would result in a new value but change listeners would never know that. See also: https://codereview.qt-project.org/c/qt/qtdeclarative/+/501319 M +3 -2 org.kde.desktop/ScrollBar.qml https://invent.kde.org/frameworks/qqc2-desktop-style/-/commit/a004faa08d905615fed5712c650de33378e53ebe Upstream patch: https://codereview.qt-project.org/c/qt/qtdeclarative/+/501319 |
Created attachment 160888 [details] screen recording SUMMARY The title says it all. Please watch the attached screen recording. EXPECTED RESULT Scrollbar size should not change after scrolling SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.240.0 Qt Version: 6.6.0 Graphics Platform: Wayland