+++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] Yet another bug with the new rules KCM: Clicking the Select Properties list scrollbar kills the list! To reproduce: 1. Add a new rule. 2. Hit Add Properties. 3. Assuming the list of properties is long enough to get a scrollbar (it's a long list so that's fairly likely), click it to scroll down. The list of properties vanishes instead of scrolling and staying viewable. Watching closely it does appear that the list scrolls before it disappears. Or at least the scrollbar position, the part I can catch the redraw on before it disappears, does. Using the scrollwheel instead of clicking the scrollbar scrolls as it should.
You don't need to clone bugs; just file new ones. This is a Kirigami bug that was fixed in Frameworks 5.71 IIRC.
It seems to be still happening for me with on master. So I'll reopen it and move it to the kirigami product. Please, correct me if I'm testing it wrong.
Hmm, you're still seeing it? I tested before writing the command and it was working for me. As you using Kirigmai from git master?
(In reply to Nate Graham from comment #3) > Hmm, you're still seeing it? I tested before writing the command and it was > working for me. As you using Kirigmai from git master? Just updated. Still seeing it here, as of kirigami commit 540d05adf60f5bbc5f907b78a51ca276707e063e. Just to be sure you're in the right place to test as sometimes I forget and think its fixed when I'm working with the main window rules list which works fine (and comes first), not the add-properties list, which is where the bug occurs: Window rules, editing a rule, add properties. Ensure the window is short enough that the list of properties has a scrollbar (lots of properties so a scrollbar's likely), and click it to scroll. Here, the add-properties list disappears instead of scrolling down. Using the scrollwheel scrolls (and is the workaround I'm using, except I often forget and have to click add-properties again), but clicking the scrollbar disappears the list. Else maybe it's qt-version-related or something? Now qt 5.15.0 here (upgraded from the rc I was on at the original report).
Ah, I can confirm that clicking on the srollbar closes the sheet. That's not a Kirigami bug AFAIK, as it doesn't happen with a scrollable sheet in Discover.
Created attachment 129303 [details] QML test sample to reproduce the bug I disagree. I can reproduce it on the attached snippet
Moving it back to kirigami, since I think this could fix it :D: Proposed patch: https://invent.kde.org/frameworks/kirigami/-/merge_requests/26
(In reply to Ismael Asensio from comment #7) > Moving it back to kirigami, since I think this could fix it :D: > Proposed patch: > https://invent.kde.org/frameworks/kirigami/-/merge_requests/26 Applying that does fix it here, yes. (Like feeling good after being sick I never appreciated an actually working scrollbar so much! =:^)
Git commit bace64a0965f3769b21953d398b639443c4708af by Nate Graham, on behalf of Ismael Asensio. Committed on 15/06/2020 at 15:15. Pushed by ngraham into branch 'master'. Fix OverlaySheet closing when clicking inside layout The `OverlaySheet` would close when clicking outside `scrollview.contentIem`. This area doesn't include the scrollbar area, nor header or footer items, so clicking on those items, if they do not catch the click event first, would result in an undesired closure of the sheet. Setting the condition to check for `contentLayout` instead respect the limits of the visible card. Clicking outside of this area still closes the sheet as expected. FIXED-IN: 5.72 M +5 -5 src/controls/templates/OverlaySheet.qml https://invent.kde.org/frameworks/kirigami/commit/bace64a0965f3769b21953d398b639443c4708af