*** Bug 488796 has been marked as a duplicate of this bug. ***

Some remarks on replication copied from the duplicate #488796 (for the attachment, see that bug)

----

I can't replicate this using the given instructions on current Neon (in a default configuration, new user account), using three different ways of entering Panel Configuration mode - the popup is always shown in front of the Panel Configuration dialog. See the left-hand side of the attached screenshot.

I have, however, found a reproducible way to trigger the popups being placed behind (see the right-hand part of the screenshot). It is somewhat more convoluted though.

(Fresh user account, default settings)

1. Right-click panel, show panel configuration.
2. Move the mouse cursor to a widget where the popup is not in front of the Show Panel Configuration dialog.
3. Press start to open kickoff.
4. Press escape.
5. Move the mouse over a widget where the popup is on the same height as the Show Panel Configuration dialog (e.g. digital clock).

The popup is now behind the dialog. It might be the case that your configuration somehow triggers this code path earlier. Could you try with a new user account to see if you get the popup in front using the exact steps you outlined in your post?

*** Bug 488835 has been marked as a duplicate of this bug. ***

*** Bug 488836 has been marked as a duplicate of this bug. ***

I can reproduce that, CWO. I can't reproduce any of the simpler versions of this bug. I recall this being an issue that got fixed late in the dev cycle. Maybe it only landed in 6.1.1?

I don't quite remember, but I think the older report I found with a similar issue while looking for duplicates was resolved early enough that it shouldn't be in 6.1.

I suspect that there is some other action/configuration setting that triggers something similar to the replication steps I stumbled into. (A modification of the stacking order maybe?) In any case, it seems to affect a substantial amount of users. I have asked some (also on reddit) if they would be willing to start from a new user account to see if it happens with a clean profile on their computers, but so far no takers.

(In reply to cwo from comment #6)
> a clean profile on their computers, but so far no takers.

I created a new user and the issue still happens.

From what I've seen here and on other platforms, everyone who experiences this bug regularly (i.e. not with the convoluted replication steps in comment 2) seems to be on Arch or an Arch derivative. Not everyone listed their distribution, but no one who listed it ran anything else. Is anyone experiencing this on a distribution that is not related to Arch?

(In reply to cwo from comment #8)
> From what I've seen here and on other platforms, everyone who experiences
> this bug regularly (i.e. not with the convoluted replication steps in
> comment 2) seems to be on Arch or an Arch derivative. Not everyone listed
> their distribution, but no one who listed it ran anything else. Is anyone
> experiencing this on a distribution that is not related to Arch?

I am encountering this on Gentoo aswell, with the simple 3 step reproducer from Paulo

KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.2
Graphics Platform: Wayland

I wonder if it's possible the simpler versions of this are caused by distros not yet having rebuilt their Plasma packages against plasma-wayland-protocols 1.13 Arch is one such example, which roughly lines up with all Arch people being able to reproduce it.

Notifications to distros have gone out about this, so they should be rebuilding it soon.

Let's make this bug report about the more complex still reproducible case found in comment 2. I can reproduce it.

(In reply to Nate Graham from comment #10)
> I wonder if it's possible the simpler versions of this are caused by distros
> not yet having rebuilt their Plasma packages against
> plasma-wayland-protocols 1.13 Arch is one such example, which roughly lines
> up with all Arch people being able to reproduce it.

Nope, my plasma stack is built against plasma-wayland-protocols 1.13.0

Hmm, there goes that theory.

Any idea what might be going on here with the disparate ways to reproduce it, Niccolò?

I'll give a look to the code and see if I can figure this out.

(In reply to cwo from comment #8)
> From what I've seen here and on other platforms, everyone who experiences
> this bug regularly (i.e. not with the convoluted replication steps in
> comment 2) seems to be on Arch or an Arch derivative. Not everyone listed
> their distribution, but no one who listed it ran anything else. Is anyone
> experiencing this on a distribution that is not related to Arch?

I'm facing this on Arch, but I can reproduce this on a freshly downloaded KDE neon live image in a virtual machine.
ISO Name neon-user-20240627-0718.iso.

No extra steps needed to cause the issue to happen. Just right-click on the panel -> Show panel configuration -> hover over the clock. The settings popup immediately opens behind the panel.

I'm on neon and i'm permanently facing the issue.

by "permanently", i mean that i don't have to open kickoff everytime in edit mode to have this happening. The Pannel Setting always overlaps the widget options even after reboots.

(i don't know if i ever opened kickoff while in edit mode, but it's possible that that i did it sometime)

Can confirm with current neon user iso, both in VirtualBox and after copying to USB and running it on bare metal.

It does not happen in the actually installed neon dev on the same computer where the iso exhibited the bug. It might be that a recent change solved this, but I doubt it as the installed version never exhibited the bug even before the release of 6.1.1 (and I didn't spot it in the runup to 6.1.0, though I didn't explicitly test it back then).

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2350

*** This bug has been marked as a duplicate of bug 487640 ***