SUMMARY MS Teams seems to be the only app that remembers its previous position in the taskbar. While other apps that can be hidden to systray place themselves at the end of the already open tasks, MS Teams appears at the position it has been the last time, thereby moving taskbar entries. Since MS Teams cannot be made to start hidden, it usually places itself on the first position, forcing all other entries to wander once one has to open that app. Interestingly though, it's the only Electron application that does that -- Mattermost or Slack stand in line as expected. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 Kernel Version: 5.10.0-1-amd64 OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4700MQ CPU @ 2.40GHz Memory: 15,4 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 ADDITIONAL INFORMATION
Sounds rather odd. Any chance you could attack a screen recording that shows the issue? Thanks!
Screen recording is out of the question -- it would show a lot of private data, and I really don't see what a video just showing buttons switches places should help. It's simple: konsole|firefox| open Teams konsole|firefox|teams| hide Teams konsole|firefox| open Tunderbird konsole|firefox|tunderbird| open Teams again konsole|firefox|teams|tunderbird| any other application appears _after_ konsole|firefox|tunderbird| If OTOH you know a way to log the communication between plasma, taskmanager and teams when the position is determined, that seems much more sensible and helpful.
Are any of those apps pinned to the task manager?
Nope, nothing. Just got a new PC and did test before configuring anything else and MS Teams still remembers. I can't say whether it remembers the actual position or just the tasbar entry inf front. I am, however, baffled that this works at all -- after those frequent Plasmashell crashes the order of taskbar entries usually is messed up beyond useful. But if MS Teams somehow remembers where it was the last time, any other app should be able to do that as well, thus easily mitigating the worst of Plasmashell's notorious instability.
Issue persists with a current configuration of: Operating System: Debian GNU/Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.17.0-1-amd64 (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5800H with Radeon Graphics Memory: 31,3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Laptop GPU/PCIe/SSE2
Thanks.
Can reproduce. Looks like Teams does some hack on the task manager.
See https://invent.kde.org/plasma/plasma-workspace/-/blob/7364149af89ba2bd5b9d9a64b911594c8f01bad9/libtaskmanager/tasksmodel.cpp#L202 When closing Teams' window, it doesn't really "close" it, instead, it sets `SkipTaskbar` property to true, so the window is hidden in the taskbar. After opening Teams' window again, it sets `SkipTaskbar` property to false, and it's intended to restore the previous position of the window. I mark the bug as RESOLVED INTENTIONAL as MS developers are really genius.
> I mark the bug as RESOLVED INTENTIONAL as MS developers are really genius. Well, there's a fine line -- and Teams crossed that line a long time ago into plain crappy. The way I see it, Teams developers are unable to figure out how to correctly show and hide their app (e.g. you cannot start Teams hidden to systray), and instead use a dirty hack. Can't say I understand the comment at the comment you're linking too. But is there a way to fix Team's broken behaviour, or even better, can plasma fix that? After all, I already can force Teams to use plasma's window decorations/titlebar.
The task manager does do some mess cleanups for some apps, like GIMP and Chrome. But in my opinion the bug should be easily fixed in Teams's side (if they think it's a bug), because they apparently does that intentionally. > But is there a way to fix Team's broken behaviour, or even better, can plasma fix that? You can use "Do not sort" sort mode or other sort mode except "Manual", so `sortMode == SortManual` is false and `updateManualSortMap()` will not be called.