Bug 432194 - Popup covers "+ Add" button
Summary: Popup covers "+ Add" button
Status: RESOLVED FIXED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_autostart (show other bugs)
Version: 5.22.90
Platform: Arch Linux Linux
: NOR minor
Target Milestone: ---
Assignee: Nicolas Fella
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-27 11:33 UTC by Patrick Silva
Modified: 2021-12-29 03:23 UTC (History)
3 users (show)

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


Attachments
screen recording (734.29 KB, video/webm)
2021-01-27 11:33 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Silva 2021-01-27 11:33:49 UTC
Created attachment 135234 [details]
screen recording

STEPS TO REPRODUCE
1. open System Settings > Startup and Shutdown > Autostart
2. click on "+Add" button
3. 

OBSERVED RESULT
A popup opens and covers the clicked button.
If I close the popup by clicking on the empty area and click on the same button again,
the popup opens above the button as expected. Watch the attached screen recording please.

EXPECTED RESULT
the popup should always open above "+ Add" button.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.21.80
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Comment 1 Nate Graham 2021-01-27 17:46:17 UTC
Yeah the button should be checkable and the popup should appear above it, as in the Baloo KCM.
Comment 2 Nate Graham 2021-01-27 17:48:03 UTC
Now that's weird. I see that the code is copied verbatim from the Baloo KCM to provide this behavior. I also see that it works properly on the second time you click the button--but not the first.
Comment 3 Harald Sitter 2021-01-28 11:47:57 UTC
Looks like something is going wrong inside popup placement. That being said the desktop style has the Menu at 0 height until shown once, this may well be why something is going wrong inside the popup placement. i.e. the first time round the menuHeight is always -`Kirigami.Units.gridUnit * 3`, which is wrong one way or the other I guess. The fusion style doesn't have that problem.

From some tinkering I'd say this could be simplified as per the docs [1]. If the menu simply was the child of the menubutton, which I suppose has no downsides since the menu isn't a context menu and thus always attached to the button, the trigger would simply become 
> onPressed: menu.open() 
and the position set as a binding, avoiding the problem altogether as the position would simply update once height is correct.
> Menu { x:0; y: height > 0 ? -height : Kirigami.Units.gridUnit * 3

Anyway. I'm mostly guessing here. Plus, whatever is wrong with our Menu{} style needs debugging, if fusion doesn't have the Menu at height 0 initially it stands to reason desktop shouldn't either.

[1] https://doc.qt.io/qt-5/qml-qtquick-controls2-popup.html#popup-positioning
Comment 4 Nate Graham 2021-12-29 03:23:24 UTC
Fixed by Yerrey Dev with https://invent.kde.org/plasma/plasma-workspace/-/commit/908f92f4809418766f53eb48c35c60817fd1cb89 in Plasma 5.24!