Cannot reproduce the issue with two 1080p screens arranged exactly like that, and the left one being primary.

Is this 100% reproducible for you? If so, can you try in a new clean user account and see if it happens there too?

Created attachment 172133 [details]
video of the process

(In reply to Nate Graham from comment #1)
> Cannot reproduce the issue with two 1080p screens arranged exactly like
> that, and the left one being primary.
> 
> Is this 100% reproducible for you? If so, can you try in a new clean user
> account and see if it happens there too?

I have reliably reproduced this on my existing user before writing this bug. see video
As I am writing this, I could not reproduce anymore.

On test account things I've tried/changed to reflect my user account:

- set font size from 10 to 11
- change breeze and context menu to  ~70% transparency
- enable night mode (red tint)
- focus follows mouse and seperate screen focus activated
- set language to german (longer string names?)

But to no avail. I could not reproduce on new user.

Oddities on my user account I've noticed
- context menu on desktop has entry for adding widgets and panel (not exists in new user account)
- almost 3 year old cruft of home dir/plasma config stuff (from Nov 2021 (Plasma 5.23???)
Maybe some old settings/cache broke something?

- problem seems to vanish for a couple minutes when I "plasmashell --replace & disown" and switch users


- deleting ~/.cache/{kwin,*qt*,*qml*,*shadercache*,*mesa*} and logging out doesn't change the behavior


I wanted to hit the "save changes" button but I check again and now it happens all of a sudden. Weird.

As a data point, I am not able to reproduce this with Plasma 6.1.3.  I have a laptop connected to two monitors with identical resolutions

This installation is a few years old, I do recall I deleted cache files quite a few months ago to solve another issue.
I also do not have entries in the Desktop right click menu for adding widgets or a panel 

I enabled focus follows mouse and separate screen focus activated, but still can't reproduce.
It does seem like cruft in the normal user is likely at fault, since the bug can't be reproduced with a new user. Given the age of many systems out there, this is likely to affect more people.

The oldest files in .config I have for plasma data are from July 2021 but these are likely not related
```
❯ ll plasma* |rg 2021
drwxr-xr-x   4 tracey tracey 4.0K Aug 13  2021 ./
drwxr-xr-x   2 tracey tracey 4.0K Jul 12  2021 env/
drwxr-xr-x   2 tracey tracey 4.0K Aug 13  2021 shutdown/
```
.cache
```
❯ ll plasma* |rg 2022
-rw-r--r--  1 tracey tracey  17M Sep  6  2022 plasma_theme_Carl_v1.4.kcache
-rw-r--r--  1 tracey tracey  17M Oct 20  2022 plasma_theme_Sweet_v1.0.0.kcache
drwxr-xr-x   4 tracey tracey 4.0K Apr  7  2022 knewstuff/
```

the config that seems to be causing is ~/.config/plasma-org.kde.plasma.desktop-appletsrc

here is mine: https://0x0.st/XVI4.bak

feel free to test out or whatever

Created attachment 172397 [details]
plasma-org.kde.plasma-desktop-appletsr

is this file unusually long like 2.6k lines?

Yes, it is indeed a pretty long file. Are you saying when you set aside or delete that config file, the issue stops happening?

(In reply to Nate Graham from comment #7)
> Yes, it is indeed a pretty long file. Are you saying when you set aside or
> delete that config file, the issue stops happening?


Yes exactly. Don't know why I didn't say that in the first place.

Deleting/moving/replacing with a default file and plasmashell --replace makes the problem go away.

Is it worth it to painstakingly delete chunks of the file and test if that specific part was responsible for the issue?

Are there any settings I could rule out/are more likely to mess with these kinds of things?

If you can stand it, that would be amazing. If not, I understand.

I think that System Trays somehow survive when you remove a panel, resulting in a config file full of system trays. I believe that if you remove your system tray, and then remove all `[Containments][something]` that claim to be `plugin=org.kde.plasma.private.systemtray`, then you should trim down that file really fast without any risk

Indeed, my file is also full of zillions of org.kde.plasma.private.systemtray instances. Which one is the real one?

(In reply to Nate Graham from comment #11)
> Indeed, my file is also full of zillions of
> org.kde.plasma.private.systemtray instances. Which one is the real one?

You can search for your `org.kde.panel`, then see its applet list underneath, and search for the system tray within that panel. You'll be able to see its ID there.

I could finally reproduce on a fresh user and fresh plasma ssession.
If you add the "add panel" button to the right click context menu and use this newly created button to create any panel the menu is placed wrong for the remainder of the session. If you restart plasma it is (sometimes) fine again.

This does NOT affect a kde neon unstable vm with only one monitor where it doesn't show it at all or something like that.
I will test on bare metal tomorrow

0. reset plasma rm ~/.config/plasma-org.kde.plasma.desktop-appletsrc and systemctl --user restart plasma-plasmashell.service
1. right click desktop
2. desktop and wallpaper
3. mouse actions
4. configure right click actions
5. tick "add panel" and apply the settings
6. right click on desktop (does not matter which monitor)
7. press "add panel" from context menu
8. choose any panel
9. right click panel on any monitor
10. click show panel configuration

I wasn't able to reproduce the exact behavior in the last comment, but I came across very similar behavior on git-master

1. Went through the steps in the last comment, new panel was created on the laptop display
2. Removed the new panel from the laptop display
3. Still in edit mode: on the external monitor clicked "Add panel" at the top - the menu appeared on the laptop display. 
4. Clicking a panel type created a new panel on the laptop display rather than the external