Bug 473241 - Scrollbar handle size is incorrect until the view is scrolled at all
Summary: Scrollbar handle size is incorrect until the view is scrolled at all
Status: RESOLVED FIXED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: Master
Platform: Neon Linux
: NOR normal
Target Milestone: Not decided
Assignee: kdelibs bugs
URL:
Keywords: qt6
Depends on:
Blocks:
 
Reported: 2023-08-10 11:23 UTC by Patrick Silva
Modified: 2023-11-11 17:10 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screen recording (2.66 MB, video/webm)
2023-08-10 11:23 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2023-08-10 11:23:44 UTC
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
Comment 1 Nate Graham 2023-08-11 18:21:08 UTC
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"
            }
        }
    }
}
Comment 2 ratijas 2023-08-11 20:26:01 UTC
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.
Comment 3 ratijas 2023-09-02 14:07:31 UTC
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
Comment 4 ratijas 2023-09-02 14:17:52 UTC
Upstream patch: https://codereview.qt-project.org/c/qt/qtdeclarative/+/501319