Bug 439923

Summary: Headerbars containing module names in QML settings are hidden after swipe with touch
Product: [Frameworks and Libraries] frameworks-kirigami Reporter: Thiago Sueto <herzenschein>
Component: generalAssignee: Marco Martin <notmart>
Status: RESOLVED FIXED    
Severity: normal CC: asturm, nate
Priority: NOR    
Version: 5.84.0   
Target Milestone: Not decided   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In: 5.86

Description Thiago Sueto 2021-07-15 23:31:06 UTC
SUMMARY
This is actually a really widespread issue in Plasma, but I don't really know which product/component to report this to, and System Settings is the best example of this bug. My guess is it's something in frameworks.

Swiping upwards in any QML settings module hides the headerbar containing the name of the module.

By swiping upwards I mean a finger motion that begins from below and goes upwards, that is, it scrolls down.

IMO this should not happen:
1. It does not fit the headerbars (containing the names of categories, like Appearance) to its left.
2. This behavior does not occur with the left headerbars when doing the same thing.
3. This is inconsistent with other KCMs that do not do the same thing even though they're also QML based.

These are the KCMs that suffer from this issue:

Global theme, Application Style, Plasma Style, Colors, Fonts, Icons, Cursors, Configure application launch feedback, Splash screen, General behavior, Screen locking, Login screen, Desktop session, File Search, Notifications, Accessibility, Default applications, Virtual keyboard, Display configuration, Night color.

This also occurs in any settings that spawn in a different window, like those of the tray icons for audio and clipboard.

And here are the KCMs that do not suffer from this issue:

Window decorations**, Desktop effects*, Virtual desktops*, Activities*, Shortcuts*, Background services*, Users, Mouse**, Touchpad**, Audio.

*  = these don't seem to be QML or their entire content isn't scrollable(?)
** = these work exactly as expected

STEPS TO REPRODUCE
1. Open any of the aforementioned KCMs:

2. Swipe upwards

OBSERVED RESULT
Headerbar gets hidden

EXPECTED RESULT
Headerbar doesn't change
Comment 1 Nate Graham 2021-08-03 18:46:50 UTC
Now that's a bug report! Thanks for the detailed investigation. It's very helpful. I am investigating.

This seems to be caused by the difference between a Kirigami.ScrollablePage (base component for Mouse and Touchpad KCMs) and the KCMs that inherit from AbstractKCM (which use a Kirigami.Page as the base component, with a semi-custom scrollview that uses the base QtQuick ScrollView).
Comment 2 Nate Graham 2021-08-03 18:56:29 UTC
Actually SimpleKCM does it too, and that uses a Kirigami.ScrollablePage as its base component...
Comment 3 Nate Graham 2021-08-03 19:11:46 UTC
No, that's not it. Making the Mouse KCM be a SimpleKCM doesn't break it, and making the workspace KCM be a Kirigami.ScrollablePage doesn't fix it.
Comment 4 Nate Graham 2021-08-03 20:10:12 UTC
Kirigami folks discoved the issue. The feature was introduced with https://invent.kde.org/frameworks/kirigami/-/merge_requests/173, and enabled by default, which made it inappropriately apply to these KCMs.

A fix is in progress; see the first part at https://invent.kde.org/frameworks/kirigami/-/merge_requests/346
Comment 5 Nate Graham 2021-08-09 16:58:31 UTC
Git commit 3c7c11ee29adda466f042166a6cc741d80377266 by Nate Graham, on behalf of Jan Blackquill.
Committed on 09/08/2021 at 13:47.
Pushed by ngraham into branch 'master'.

controls/AbstractApplicationHeader: disable hiding on touch scrolling behaviour by default

M  +1    -1    src/controls/private/globaltoolbar/PageRowGlobalToolBarStyleGroup.qml
M  +1    -1    src/controls/templates/AbstractApplicationHeader.qml

https://invent.kde.org/frameworks/kirigami/commit/3c7c11ee29adda466f042166a6cc741d80377266