X11 or Wayland? If it's on X11, can you check if it happens on Wayland?

X11

(In reply to Nate Graham from comment #1)
> X11 or Wayland? If it's on X11, can you check if it happens on Wayland?

Unfortunately, Wayland do not work on my laptop.
I upgraded and restarted the system (there were no updates of KDE/Plasma) and observe the behavior on monitor disconnect/connect.

I have two monitors connected at work (setup with 3 screens, two external HD screens placed over laptop screen 2560x1440). When I dissconnected external monitors, the windows moved more or less correctly to the laptop screen. When I reconnect monitors, the windows which were placed on laptop screen before disconnection were placed correctly on the laptop screen. The windows which were on external monitors were resized to height of ~190px. They stayed on the laptop monitor. This time not on the bottom of the screen. Maximized windows from external monitor stayed maximized but on the laptop screen.

This looks like something complicated behavior to reproduce. Maybe there is some way to clear the files where Plasma stores last sizes of different windows and their positions? Maybe there is some problem?

Since it affects non-KDE windows, I think it's not a weird interaction having to do with the built-in code to remember window positions, since that only affects KDE app windows. Seems to be related instead to KWin's own window positioning behavior when going from a multi-screen setup to a single-screen setup.

I upgraded KDE Plasma to Version: 5.24.
The problem still exists.
Maybe somebody could tell me where does kwin (or Plasma) stores window positions?
It would be good to clear it and check if the problem still exists. Maybe there is some error in these files making kwin to behave incorrectly.

Can you re-check whether it works on Wayland, now that you are on 5.24?

Wayland still do not work on my laptop (segfault: kwin_wayland[2785]: segfault at 8 ip 00007fd18cc15b34 sp 00007fffa33075f0 error 4 in KWinWaylandDrmBackend.so[7fd18cbd7000+40000]).

I also have this exact problem, but on Intel graphics.  The windows are shrunk not only if the external monitor is disconnected, but also if it goes to sleep.

Kubuntu 22.04 
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.3
Kernel: 5.18.2-051802-generic (64-bit)

X11.  I have not tried Wayland.  I will update if I manage to test Wayland.

Graphics: Mesa Intel Xe Graphics.   Intel Corporation TigerLake-LP GT2

(In reply to Michael Ehrlichman from comment #8)
> I also have this exact problem, but on Intel graphics.  The windows are
> shrunk not only if the external monitor is disconnected, but also if it goes
> to sleep.
> 
> Kubuntu 22.04 
> KDE Plasma Version: 5.24.4
> KDE Frameworks Version: 5.90.0
> Qt Version: 5.15.3
> Kernel: 5.18.2-051802-generic (64-bit)
> 
> X11.  I have not tried Wayland.  I will update if I manage to test Wayland.
> 
> Graphics: Mesa Intel Xe Graphics.   Intel Corporation TigerLake-LP GT2

I just installed plasma-workspace-wayland, rebooted, and logged into a Plasma (Wayland) session.  The problem does not occur in Wayland.

I am also experiencing this issue on plasma 5.25.5 with X11 with intel graphics.  When connecting a new monitor, existing windows on all workspaces are resized to a very small height

Operating System: Arch Linux
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Kernel Version: 5.19.7-arch1-1 (64-bit)
Graphics Platform: X11
Graphics Processor: Mesa Intel® HD Graphics 620

same here

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

I transfer some information from the https://bugs.kde.org/show_bug.cgi?id=454425.

Now, this is happening on Fedora 36, kf5-plasma-5.98.0, plasma-workspace-5.25.5, X11.
(I will update the Wayland later).
This is happening to all the windows, not just Non-KDE apps. I had this problem with Kate, Konsole, Ark, Dolphin (my current open KDE apps) as well as Firefox and Chrome.

In my setup I have the following layout:

 _____________  ______________
|         A         ||       B           |
|1920x1080 ||1920x1080 |
|____________||____________|
                         ______________
                        |       P           |
                        |    QHD        |
                        |____________|

Tests:
* Screen A the primary screen, no logout, unplugged the laptop from the dock: All windows moved to laptop's screen, no resize. Plug the laptop to dock, ALL windows resized.
* Screen A the primary screen, logout, login, unplug the laptop from the dock: All windows moved to laptop's screen, no resize. Plug the laptop to the dock, ALL windows resized.
* Screen B the primary screen, no logout, unplugged the laptop from the dock: SOME windows resized. Plug the laptop again, all the windows resized.
* Screen A/B/P is the primary screen. All windows in one screen (either of them): Unplug the laptop, no resize. Plug the laptop to the dock, ALL windows resized.
* All windows minimized: Unplug the laptop, restore windows: Size is the correct one. Minimize the windows, plug the laptop, restore windows, size is the correct one but all windows are in the primary screen, not in their correct position. 

Also, I found another "workaround" AND a new bug:
OTHER BUG: 
Use the "Show desktop" widget. Unplug the laptop: No resize. How the windows again: All are OK. Use the "Show desktop" widget, plug the laptop, press the "Show desktop" widget button again and the windows are restored to the primary screen, but at least not resized. 
The issue I faced is that screens A/B settings are swapped.  Settings (widgets, backgrounds etc) of screen B appear on Screen A and vice versa. 

Some notes: When I unplug the laptop, I noticed that all the windows ARE resized immediately. Then, screen is getting black and then we have the results (either resized or not). 

So, it seems that the issue happening less often than in the previous versions of plasma (unplug does not *always* results to a resize), but when I plug the laptop (aka increase the number of screens) is does happens.

Please note that if I disable any of the screens, I have no issues, windows are moved to other screens without problem.

I checked in Wayland also. 

As I was suspecting, in Wayland the problem isn't present. Although I have other issues, like for example the windows are not moved back to the screen I had them prior to unplug/plug, the resize doesn't happen. 

So, we can say that it's X11 specific. 

PS: Of course changing to Wayland and then back to X11 messed up my desktops so badly that I will definitely start a Wayland session only when I would be forced to do so.

I just wanted to add that if I remove "kscreen", this problem goes away.  Of course, KDE display configuration also goes away, but that's an acceptable trade-off for me since I'm fine with using xrandr and scripts.

I see the product here is marked as "KWin", but this may in fact be more "kscreen" related.

I previously reported this occurs on Intel graphics, but this also occurs on my desktop with an AMD GPU (and open source drivers).  This problem seems to occur every time the monitors awake from sleep as well.

Thanks, that's helpful information.

As additional information to comment #13 (https://bugs.kde.org/show_bug.cgi?id=452118#c13) by Peter Tselios.

I can reproduce the unwanted resizing when my  screen layout is like this:
 _____________ 
|       Ext        |
|3840x1600 |
|____________|
                    ______________
                   |      Laptop  |
                   |     FHD        |
                   |____________|

Closing laptop lid switches to Ext screen only and messes up window sizes.

When I arrange screens like this:
In my setup I have the following layout:

 _____________  ______________
|     Ext          ||       Lap       |
|3840x1600 ||1920x1080 |
|                    ||____________|
|___________|

side by side with laptop NOT below external screen the closing lid does NOT resize all windows to a very small height.

Hope this helps. I haven't found this information in this or other bug reports yet.

Are you using Plasma 5.27 for this? Or an earlier version?

Betriebssystem: EndeavourOS 
KDE-Plasma-Version: 5.27.3
KDE-Frameworks-Version: 5.104.0
Qt-Version: 5.15.8
Kernel-Version: 6.2.8-arch1-1 (64-bit)
Grafik-Plattform: X11
Prozessoren: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics
Speicher: 30,6 GiB Arbeitsspeicher
Grafikprozessor: AMD Radeon Graphics
Hersteller: LENOVO
Systemversion: ThinkPad T14 Gen 1

--

I played around a bit right now. It got 99% better, no matter if my Laptop screen has been arranged partly or fully below the external screen (external is always the main screen with the panel).

I now only have a one remainder of misbehaviour: the google-chrome browser window on the external big screen with a height > 1080 (more than the laptop y-height) gets resized a little bit when I close the lid - although it has been positioned on the external screen. But I cannot reproduce this reliably.

So good enough for me. I'll post some updates whenever I find sth. to reproduce for you devs. One of the latest updates in 5.27 seems to have fixed a lot in this case. Thanks!

Short update 
I today worked with some more windows opened. Windows do NOT get resized when closing the lid - but the are moved up to the top of the big external screen without any need. Opening the lid moves them back to the former position.

I'd have expected that only from windows that were on laptop's screen. They of courde need to be moved to the other screen and surely can be moved to the top. But also moving windows that ARE already on the external screen DO NOT NEED to be moved at all.

I was getting something like this as well when my external displays remove/reset, occasionally will take most windows, move them all to one window (somewhat randomly, sometimes primary), and squish them to be something like 3px wide, yet retain whatever height they had.  This is particularly annoying when using 4x displays, 3x as large 50" TV's, and 1x 15" laptop driving them, especially when they land on the tiny laptop to the far side where it was genuinely hard to find/move/resize.  Talk about some Where's Waldo.

At the direction of Mr. Graham on another issue, I removed and let plasma rebuild my screen settings across a few places, and in the past week or so from doing so, not seen the odd change of window geometry during screen transitions that would previously happen quite commonly.  I think I'd accumulated some conflicting data, or just some bunk defaults somehow along the way, but not positive as I've not researched what each bit of the config files were doing diffing before and after, but a few got my attention as odd among them no longer present after the clearing.

Try clearing these, resetting your displays/plasma settings, and see if yours behaves any better as well.  As Nate warned me, this will reset your plasma desktop and widgets, but so far well worth the 20 minutes putting things back in the right places.

~/.local/share/kscreen/*
~/.config/plasma-org.kde.plasma.desktop-appletsrc
~/.config/plasmashellrc

HTH!

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

So weirdly a few days ago, my application windows started moving and resizing bonkers for me again, moving into weird places, resizing windows horizontally to as thin as only 5px wide, and like this report, moving some of them almost entirely off the bottom window of the screen (ending up sometimes hidden by my latte dock) when my external monitors are disconnected.  It had been working after clearing out my kscreen and plasma config files, but now randomly as of a few days ago again it's getting extreme (and extremely annoying).

I've been looking into where this window placement location state data might be kept, but saw nothing in various kwin or kscreen files across .config or .local configs or resources.

After my kscreen wipe, window placements were not restoring after screen changes at all, and added back a kwin script restoreToScreen which I have used prior, and worked well at first, but a few days ago suddenly madness ensued, so I disabled restoreToScreen.  Now with it disabled for days, some windows stay in the right places, some get moved but remain proper geometry, other windows will get squished to like 5px wide, hiding them in my desktop somewhere to be found.  What's worse is every time I do it, randomly more things move, and to different places, including off the screen, so something is oddly 

Finding the github for restoreToScreen, an issue reported by kwin's Zamundaaa that the windows placement to screen restoration functionality was now included in 5.26, but certainly doesn't seem to work or work as intended with multiple displays now since 5.27, so maybe something haywire with the multi-screen changes?  I presume the script and native kwin might have conflicted, but disabling the script, or before even using it after the wipe removing it did not or works unpredictably.  

If I could find where these states are saved, I'd love to flush them, but I can't find the mole to whack.  I did file another bug report separately as well, might be a dupe of this, but unsure if both are entirely related as I've had this issue across a few laptops for years now and would like to see this working properly all the time, as I know it's possible if/when it does.  https://bugs.kde.org/show_bug.cgi?id=468184

I also have an issue along similar lines on Wayland (so also posted there bug 468184)

When unpluging my external screen from my laptop, many windows (e.g. firefox and gnucash) are not (or not appropriately) resized when moved to the laptop screen. Specifically they are too heigh with the title bar being out of the screen, meaning I cannot move/minmize/maximize/close them, I have to use the shortcut Ctrl + F5 to move them and then resize manually.

External screen is a 34" 3440x1440 whereas laptop screen is 14" 1920x1080 (no scaling applied to either).

Operating System: KDE neon 5.27
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
Kernel Version: 6.1.22-060122-generic (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics 620

I have no idea how Kwin handles this currently (and so I don't want to tell dev how to do things) but just in case it's useful, it sounds like a systematic approach when it comes to window size and placement could be:

To define window size on any given screen:
====================================
width ratio = (window width in px / screen width in px)
height ratio = (window height in px/ screen height in px)
>> those width/height ratios can then be applied to different size screens' height / width in plug / unplug events which would conserve the same relative window size across any screen (independently of absolute screen size or aspect ration).

To define windows placement:
=========================
horizontal ratio: distance between screen left edge and window horizontal centre / distance between screen left edge and screen horizontal centre (i.e. half screen width)
vertical ratio: distance between screen top edge and window vertical centre / distance between screen top edge and screen vertical centre (i.e. half screen height)
>> Those ratio can then be applied to the window (horizontal / vertical) centre in plug / unplug events so the relative placement is conserved across any screens (independently of absolute screen size or aspect ration).

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

Can you check whether the issue is reproducible after making the panel autohide?

(In reply to Vlad Zahorodnii from comment #26)
> Can you check whether the issue is reproducible after making the panel
> autohide?

I am using auto-hide panels and have window sizing issues.

I should say that this is getting worst. I now regularly get windows opening in the size that's bigger than the screen when opening or restoring an application. I have to use Ctrl + F5 a lot these to move and resize those windows.

So this is not only about plugging / unplugging events but also just about open applications (that may have had a large size last time it was opened on a bigger screen). So I reckon plasma has an issue altogether in the way it deals with remembering window sizing and it might be time to think of a new, more consistent, approach.

(In reply to Gauthier from comment #24)
> I also have an issue along similar lines on Wayland (so also posted there
> bug 468184)
> 
> When unpluging my external screen from my laptop, many windows (e.g. firefox
> and gnucash) are not (or not appropriately) resized when moved to the laptop
> screen. Specifically they are too heigh with the title bar being out of the
> screen, meaning I cannot move/minmize/maximize/close them, I have to use the
> shortcut Ctrl + F5 to move them and then resize manually.
> 
> External screen is a 34" 3440x1440 whereas laptop screen is 14" 1920x1080
> (no scaling applied to either).
> 
> Operating System: KDE neon 5.27
> KDE Plasma Version: 5.27.4
> KDE Frameworks Version: 5.105.0
> Qt Version: 5.15.9
> Kernel Version: 6.1.22-060122-generic (64-bit)
> Graphics Platform: Wayland
> Processors: 8 × Intel® Core™ i5-8350U CPU @ 1.70GHz
> Memory: 15.3 GiB of RAM
> Graphics Processor: Mesa Intel® UHD Graphics 620
> 
> I have no idea how Kwin handles this currently (and so I don't want to tell
> dev how to do things) but just in case it's useful, it sounds like a
> systematic approach when it comes to window size and placement could be:
> 
> To define window size on any given screen:
> ====================================
> width ratio = (window width in px / screen width in px)
> height ratio = (window height in px/ screen height in px)
> >> those width/height ratios can then be applied to different size screens' height / width in plug / unplug events which would conserve the same relative window size across any screen (independently of absolute screen size or aspect ration).
> 
> To define windows placement:
> =========================
> horizontal ratio: distance between screen left edge and window horizontal
> centre / distance between screen left edge and screen horizontal centre
> (i.e. half screen width)
> vertical ratio: distance between screen top edge and window vertical centre
> / distance between screen top edge and screen vertical centre (i.e. half
> screen height)
> >> Those ratio can then be applied to the window (horizontal / vertical) centre in plug / unplug events so the relative placement is conserved across any screens (independently of absolute screen size or aspect ration).

The case that this does not cover is if a window is spread across several screens. In this case (only) then the size / placement ratio should be worked out taken the full width / height of all screens the window is spread across. Then in plug / unplug events those ratio can be applied just fine to the new screen config.

I wrote the duplicate bug  #468177, and I haven't had this problem in a while. Testing again, it works!

kwin 5.27.7-1.2
OpensuseTumbleweed 20230823

I am still experiencing these issues periodically with KDE 5.27.5 on Debian bookworm, with a display setup as shown:
 _____________  ______________
|         A         ||       B           |
|1920x1200 ||3840x2160 |
|____________||____________|

I see this quite often with Firefox, but also the Slack desktop app. I haven't figured out how to consistently trigger the behavior. Sometimes it only happens on one virtual desktop, sometimes both. I usually leave windows "vertically maximized"; perhaps that's related (when a window from the 3840x2160 display winds up on the smaller 1920x1200 display but was vertically maximized.

I see both behaviors: windows are shrunk down to a small vertical space, and windows are left scattered across the previous desktop area (do not stay on either screen when reconnected.) e.g. when I am packing up to go to work and unplug my external display, windows are scattered across the laptop display, typically left somewhat off screen. When I reconnect, they stay in this scattered state, and some windows are vertically shrunk.

I've mostly learned to live with this but it is a bit of an annoyance. I tried Wayland at one point but had numerous other issues, so I don't see that as a good option at this time.

I'm still experiencing this issue on Plasma 5.27.9 on KDE Neon (on Intel graphics) and on a fresh install of Kubuntu 23.10 (On AMD graphics). On my end it does affect any kind of windows, including native KDE apps like Dolphin (in fact I notice it often with Dolphin).

My set-up is:
 _____________  
|         A         |
|3440x1440 |
|____________|
 _____________
|        B          |
|1920x1080 |
|____________|

To reproduce (first way):
1. open a window (say Dolphin) in screen A and stretch it over most of the height of that screen (i.e. a height that's higher than the height of screen A)
2. unplug that screen

To reproduce (another way):
1. open a window (say Dolphin) in screen A and stretch it over most of the height of that screen (i.e. a height that's higher than the height of screen A)
2. close the window
3. unplug that screen
4. relaunch that same application (again say Dolphin) that will now open on screen B but it remembers its previous size

Result:
both the title bar AND the bottom of the window are outside of screen B so I have to use Ctrl+F5 to move and resize so the window fit within the screen again.

It does feel there need to be a systemic logic (of the kind I proposed - though of course not necessarily that one, I trust dev to think of something much better) to remember and applied window size and placement when changing monitor set-ups (both for plugging / unplugging events and when for opening a new window to the correct size after a change in monitor set-up). 

@KDEdevs, Is this lined up for Plasma 6?

Actually very odd, it's now working all working fine on the Kubuntu laptop. I cannot reproduce (the bug was there only a few days ago).

The problem still appears from time to time on my laptop but it is less frequent. Last time I noticed other version of probably the same issue – some windows are scaled to 1px width and ~50px height. It is difficult to find such window. It is possible to resize it. Now all LibreOffice windows are of such size when I start a new document.

X11; Debian GNU/Linux 12; KDE Plasma: 5.27.5; KDE Frameworks: 5.103.0; Qt: 5.15.8; Kernel: 6.1.0-13-amd64 (64-bit); NVIDIA GeForce RTX 3060 Laptop

(In reply to Maciej Kotliński from comment #34)
> The problem still appears from time to time on my laptop but it is less
> frequent. Last time I noticed other version of probably the same issue –
> some windows are scaled to 1px width and ~50px height. It is difficult to
> find such window. It is possible to resize it. Now all LibreOffice windows
> are of such size when I start a new document.
> 
> X11; Debian GNU/Linux 12; KDE Plasma: 5.27.5; KDE Frameworks: 5.103.0; Qt:
> 5.15.8; Kernel: 6.1.0-13-amd64 (64-bit); NVIDIA GeForce RTX 3060 Laptop

Yours is almost exactly my problem too.  Nate's prior advice helped me with windows moving around for a while at least by clearing out the mountain of different display geometry "profiles" that accumulate as kde gyrates during display changes, which in my case is exacerbated by my thunderbolt dock weirdness.  My windows were moving about and moving to the 1px width same as you mentioned with every geometry hotplug change, also moving off my 50" display to a 15" laptop 4k display, which became infuriating to find and resize _each_ window when it happened.

Clearing the geometry profiles in kde as mentioned helped, where I found 40+ profiles had accumulated.  My hypothesis is KDE reels every time there is a change, and creates a profile for _every_ iteration it sees.  The problem with my TB dock is it'll periodically glitch, reset my displays, and everything starts bouncing around for a minute or so until it settles.  It's an oddity only someone with a TB dock would see, plus like you with the nvidia gpu it makes things even more interesting.  I think ultimately it is driving KDE insane in doing so, or at least with so many profiles to choose from, it ends up saving geometry to each, better or worse, and it becomes a role of a dice which it lands on.

I've been using Wayland now for some time, and it's even worse than xorg in using the TB docks as every hotplug, the displays all land on different port ID's each time, and with 4x displays (3x on the tb dock) doing that, it becomes a problem for KDE to manage.  Literally every glitch changes my displays from (dp-4, dp-5.1, dp-1, dp-5) to (dp-4, dp-5, dp-3, dp-1) and then variably from there.  With xorg it would do it occasionally too, but far less prone, and far more deterministic.  Wayland is far more variable meaning I have 5 different latte-dock profiles for each display tuple that occurs I have to manually switch between every time my displays rearrange themselves by port-id.  

This probably needs fixed at the thunderbolt/gpu driver levels that the displayport ports so randomly jumble like that.  Certainly anyone else using a usb/thunderbolt adapter devices like that would have similar issues with multiple displays.  I've tried with multiple TB docs, they both do the same things.

Nate also said this should improve with newer handling to not create the static profiles anymore, so hopefully that helps.

These corner cases are all hard to describe, and I'm sure harder for folks to emulate with fairly exotic hardware, but hopefully these reports help the devs understand the nature of the problems to consider when writing these features if they don't have a like hardware configuration to experiment with themselves.

(In reply to Michael Butash from comment #35)

I experienced 1px windows after buying USB 3.1 docking station (one HDMI port connected to external display). Once it starts to resize lets say Libre Office windows it continues also with other setups without docking station.

I also noticed that Plasma often freezes when I click on the icon of group of 1px windows on the task bar. This could be connected with our problem. The strange think is that I can not move anything in opened windows during that freeze (few seconds) but the mouse cursor moves normally.

FWIW I can't reproduce this issue as described in Plasma 6 Wayland with 2 screens, one 4k@200% intenral and the other 1080p@100%, connected by HDMI through an HDMI-DisplayPort dongle

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

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

I'm not able to reproduce this in Plasma 6 on Wayland, FWIW.

Is anyone else who could previously reproduce the issue able to test with the Plasma 6 beta release? That would be super helpful.

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

I was able to trigger this issue in the past, but in Plasma 6, I'm regularly using an external monitor in the setup that can trigger this issue, and now it works perfectly for me. It makes sense given the plethora of multi-monitor improvements that are landing in Plasma 6. So let's call it fixed in Plasma 6 until and unless anyone can still reproduce the issue there!

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

(In reply to Nate Graham from comment #42)
> I was able to trigger this issue in the past, but in Plasma 6, I'm regularly
> using an external monitor in the setup that can trigger this issue, and now
> it works perfectly for me. It makes sense given the plethora of
> multi-monitor improvements that are landing in Plasma 6. So let's call it
> fixed in Plasma 6 until and unless anyone can still reproduce the issue
> there!

479694 reports the same issue. Should this be reopened?

Maybe... the specific thing reported in there might be something else, or a recent regressions unrelated to the original work. Let's do a bit more triage there first.

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

Sadly I'm still experiencing this issue regularly on plasma 6

Every time I disconnect my external monitor, all the windows that were there are unreachable, there no way to see them or even move them to the current desktop using shortcuts.. I usually kill the process (if the unreachable window) and restart it

 @eifr, if you have any unreachable windows, you can right-click them in your task manager -> more -> move, and they will be glued to your mouse cursor. Note that this doesn't work for grouped windows (you'll need to ungroup them first)

(In reply to Naxdy from comment #49)
>  @eifr, if you have any unreachable windows, you can right-click them in
> your task manager -> more -> move, and they will be glued to your mouse
> cursor. Note that this doesn't work for grouped windows (you'll need to
> ungroup them first)

Thx for the tip, I just wonder if the issue I described is the same as this bug, as what's happening to me is that the windows are supposed to move to the main desktop but they're just staying when disconnecting an external monitor

Honestly, I'm not sure. The issue I've had disappeared with 6.0.0. We'd need more people that can reproduce it to say for sure.

Does it also happen for you on a clean install?

Did not try a clean install yet, I'll give it a try only with Fedora 40 because I only have one computer and it's also for work

A live USB should be sufficient for this I think, no?

If people have the same issue, I'd highly recommend to submit new bug reports. Issues like this are often caused by a bunch of different things, not just one.