Sort: Manual Order of windows lost after x11vnc remote connection STEPS TO REPRODUCE 1. Have multiple Firefox sessions, terminals, other programs, etc open. (Typical workspace?) 2. Icons-only Task Manager > Behavior > Sort: Manual 3. Carefully sort the windows into a user-desired manual order. 4. Remote connect with x11vnc 5. Sign back in at the physical terminal. 6. Windows are now no longer in the user specified order. Notably it looks roughly like the order of Firefox session windows is reversed (I have a lot of them), as well as combined together (they're not allowed to be grouped but now they are). A mix of windows that were after (to the right) as well as before (to the left) of Firefox's session windows are now all to the right, with only Dolphin to the left of Firefox's set of windows. Steam's set of windows (2) didn't get reversed, but they might not be a group candidate. Firefox's would be if grouping weren't banned for that program, and those windows appear to now be in reverse order. Overall all of the programs are now in a seemingly random order across the task bar (but still grouped left to right by program). I've had this issue for about a week and at least two different ArchLinux KDE updates have had the issue (I wanted to wait to see if it was fixed since it seemed likely a new update might resolve the issue). This was working 'recently' though I don't know what version of KDE Plasma workspace I was using on Arch Linux prior to the more recent updates. This regression may have been introduced somewhere between 5.26.x and 5.27.x.
Clarifying on the Firefox Grouped. There was at least one new Firefox window that I hadn't sorted in since reloading the session. It was to the right of the ungrouped set of sorted Firefox windows. After this bug triggered again it is now all the way to the left of the still ungrouped but now 'together' (in sequence along the taskbar) Firefox windows.
Before, during, or after step 4, did you sign out? I ask because in step 5, you say "Sign back in at the physical terminal" which implies being signed out.
Only locked the screen. Step 5 is more "unlock the physical terminal rather than use a remotely grabbed tmux session of the same user account that has credentials to grab screenbuffer data via X11 mechanisms."
Updated to KDE 5.27.3-1 (and Icons-only Task Manager 3.0) last night. * Before I went to bed I didn't notice any issues (* it's possible I actually didn't _notice_ any issues then as I wasn't switching windows regularly). * I locked the screen as usual. * When I unlocked with my password this morning, I noticed the windows were similarly shuffled around as previously. No x11vnc was involved, just _locking_ and _unlocking_ the session; shortly after an update about half a day before I unlocked and noticed the issue had happened again. Is there any method by which I can collect the data that I-oTM uses to remember the window order? E.G. some unique identity per window as well as the order it currently thinks the windows should be sorted by? It might be useful to confirm the windows haven't changed identity or some other event. I checked dmesg as well in case some OOM event caused things to reload unexpectedly. Just the usual perf lines... [ 3315.601813] perf: interrupt took too long (2537 > 2500), lowering kernel.perf_event_max_sample_rate to 78600 [ 4547.040053] perf: interrupt took too long (3196 > 3171), lowering kernel.perf_event_max_sample_rate to 62400 [ 6242.574692] perf: interrupt took too long (4003 > 3995), lowering kernel.perf_event_max_sample_rate to 49800 [25918.772770] perf: interrupt took too long (5023 > 5003), lowering kernel.perf_event_max_sample_rate to 39600 The last line occurred at about 7 hours and 12 min after boot, and would have been while I was sleeping. Search results indicate it might be related to either unresponsive storage subsystems or unusually high system load.
I noticed this happened again this morning because my Firefox windows had shuffled a little from where I'd re-arranged some of them. I'm not sure if KDE has internal window IDs that are different but: xwininfo -tree -root | sed -e 's/failure in conversion from UTF8_STRING to ANSI_X3.4-1968/UTF8_only/' Yields a lot of containing box 'windows' for my dual monitor setup. 0x1000610 (has no name): () 1920x1080+0+0 +0+0 1 child: 0x1000611 (has no name): () 1920x1080+0+0 +0+0 1 child: 0x1400023 " (UTF8_only)": ("plasmashell" "plasmashell") 1920x1080+0+0 +0+0 0x100060d (has no name): () 1920x1080+1920+0 +1920+0 1 child: 0x100060e (has no name): () 1920x1080+0+0 +1920+0 1 child: 0x140001d " (UTF8_only)": ("plasmashell" "plasmashell") 1920x1080+0+0 +1920+0 xwininfo -tree -root | sed -e 's/failure in conversion from UTF8_STRING to ANSI_X3.4-1968/UTF8_only/;/has no name/d;/1 child:/d;/2 children:/d' I'll use this to track the window IDs and see if this happens yet again after more use. xwininfo -children -root | sed -e 's/failure in conversion from UTF8_STRING to ANSI_X3.4-1968/UTF8_only/;/has no name/d;/1 child:/d;/2 children:/d' | sort | grep -E '^[[:space:]]+0x' > /tmp/winlist
Does I-oTM use anything other than window ID to remember the sorting order of windows? Based on some windows moving and some staying in place, my suspicion is that only _some_ FFwindows are being closed and reloaded, not all of them. I still think that I saw _not_ Firefox windows shuffle to the other side of that process, but it's plausible that due to the order I had things in Firefox's windows might have just re-opened (and re-group parented) to another area in my taskbar. That was before I was taking steps to collect general data on this issue; and I would still like a method of dumping the I-oTM window-ordering list to a comparable file so that I can better confirm it's not an issue. I've been tracking expected (updated Steam) and unexpected X11 window id changes. Since I noticed an unexpected ID change among Firefox windows I've opened a bug report about this behavior: https://bugzilla.mozilla.org/show_bug.cgi?id=1823488 Here's the bit of shell script I've been using to create a set of window ids, compare them, and then pull the matching ID items back out of the list of current windows. xwininfo -children -root | sed -e 's/failure in conversion from UTF8_STRING to ANSI_X3.4-1968/UTF8_only/;/has no name/d;/1 child:/d;/2 children:/d' > /tmp/xwininfo2 ; xwininfo -children -root | sed -e 's/failure in conversion from UTF8_STRING to ANSI_X3.4-1968/UTF8_only/;/has no name/d;/1 child:/d;/2 children:/d' | cut -d\ -f6 | grep 0x | sort -n > /tmp/wxids2 ; comm -13 /tmp/wxids{1,2} | while read II ; do grep $II /tmp/xwininfo2 ; done | grep -v 200x200
Pretty sure this'll be fixed in Plasma 6.2 or later. Can you retry there?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.