| Summary: | Every ScrollablePage implementation sends a binding loop error for its MouseArea | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-kirigami | Reporter: | Nate Graham <nate> |
| Component: | general | Assignee: | kdelibs bugs <kdelibs-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | martin, nathan, nepnep, notmart |
| Priority: | NOR | Keywords: | regression |
| Version First Reported In: | Master | ||
| Target Milestone: | Not decided | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/frameworks/kirigami/-/commit/5062d1d09b91dd87a8cc1894a8a589e834f21a7f | Version Fixed In: | 6.12 |
| Sentry Crash Report: | |||
|
Description
Nate Graham
2022-09-17 14:48:35 UTC
This code looks suspicious:
height: Math.max(root.flickable.height, implicitHeight)
implicitHeight: {
let impl = 0;
for (let i in itemsParent.visibleChildren) {
let child = itemsParent.visibleChildren[i];
if (child.implicitHeight <= 0) {
impl = Math.max(impl, child.height);
} else {
impl = Math.max(impl, child.implicitHeight);
}
}
return impl + itemsParent.anchors.topMargin + itemsParent.anchors.bottomMargin;
}
*** Bug 458651 has been marked as a duplicate of this bug. *** *** Bug 461152 has been marked as a duplicate of this bug. *** propagating implicitheight from child to parent should be ok, I'm not sure why itdoes loops.. however, that code indeed is not pretty, is a bit of a acrobatics to make old code work, I think is one of the things when branching occurs i'm going to change making it better code, by allowing a single child as main content. (and knowingly break some apps in the process, but that is the only moment it can be done at all) A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/819 Git commit b73f7b9d1fb7a08dd905616062ac67820fa8969e by Marco Martin. Committed on 15/11/2022 at 12:51. Pushed by mart into branch 'master'. Fix binding loop accessing implicitheight of a child from the parent causes a binding loop, accessing he height seems to fix it M +1 -5 src/controls/ScrollablePage.qml https://invent.kde.org/frameworks/kirigami/commit/b73f7b9d1fb7a08dd905616062ac67820fa8969e The fix had to be reverted because it broke Info Center; re-opening. *** Bug 467791 has been marked as a duplicate of this bug. *** *** Bug 500233 has been marked as a duplicate of this bug. *** A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kirigami/-/merge_requests/1727 Git commit 5062d1d09b91dd87a8cc1894a8a589e834f21a7f by Nate Graham. Committed on 05/03/2025 at 14:25. Pushed by ngraham into branch 'master'. ScrollablePage: fix width and height binding loops Currently we check to see if the implicit width/height is less than or equal to zero, and if so, we consult the actual width/height value. This isn't necessary; implicit values work just fine alone. Tested every ScrollablePage implementation in System Settings, Info Center, System Monitor, Discover, NeoChat, Elisa, Icon Explorer, DrKonqi's crashlog viewer, and all Plasma widgets. I found no regressions with scrollability or visual display in any of them, and the binding loop warning is now gone. Everything feels a little bit snappier, too. FIXED-IN: 6.12 M +2 -6 src/controls/ScrollablePage.qml https://invent.kde.org/frameworks/kirigami/-/commit/5062d1d09b91dd87a8cc1894a8a589e834f21a7f |