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
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).
Actually SimpleKCM does it too, and that uses a Kirigami.ScrollablePage as its base component...
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.
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
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