[BUG]: Problems when moving floating windows with mouse between monitors #496

Closed
opened 2026-01-05 14:51:07 +01:00 by adam · 2 comments
Owner

Originally created by @alex-ds13 on GitHub (Oct 17, 2024).

Originally assigned to: @alex-ds13 on GitHub.

Summary

Currently when using the mouse to move windows, komorebi only checks to start a move operation if the origin workspace is tiling and it checks for the focused container so if we move floating_windows or if we move a window from a floating workspace the MoveResizeStart event won't create a pending move operation or it will create a wrong one (in the case of floating_windows).

Then moving this windows back can create problems.

In the case of the floating_windows nothing bad seems to happen and it is all ignored, although the window never gets transferred to the other monitor on komorebi as it should...

The worst thing is when moving from a floating layout since that won't create a pending move, the window won't be transferred however when moving back, since now the origin workspace will be tiling it will create the pending operation but with the focused container which will be the container that already existed before on that workspace, which results on komorebi transferring that window to the other monitor, however this only happens on komorebi since the target workspace is now a floating workspace it's update function won't move the window from the other monitor and it stays there looking like it is were it was before but unmanaged, when in fact it is now owned by the floating workspace and the only way to fix it is to manually move it with mouse to the floating workspace and then use a keybind/command to move it to the tiling workspace again...

Version Information

This happens on 0.1.29 and even on master...

Komorebi Configuration

(Can I leave this emtpy?! :P )

Hotkey Configuration

(Can I leave this emtpy?! 😅)

Output of komorebic check

(Can I leave this emtpy?! 😅)

Originally created by @alex-ds13 on GitHub (Oct 17, 2024). Originally assigned to: @alex-ds13 on GitHub. ### Summary Currently when using the mouse to move windows, komorebi only checks to start a move operation if the origin workspace is tiling and it checks for the focused container so if we move `floating_windows` or if we move a window from a floating workspace the `MoveResizeStart` event won't create a pending move operation or it will create a wrong one (in the case of `floating_windows`). Then moving this windows back can create problems. In the case of the `floating_windows` nothing bad seems to happen and it is all ignored, although the window never gets transferred to the other monitor on komorebi as it should... The worst thing is when moving from a floating layout since that won't create a pending move, the window won't be transferred however when moving back, since now the origin workspace will be tiling it will create the pending operation but with the focused container which will be the container that already existed before on that workspace, which results on komorebi transferring that window to the other monitor, however this only happens on komorebi since the target workspace is now a floating workspace it's update function won't move the window from the other monitor and it stays there looking like it is were it was before but unmanaged, when in fact it is now owned by the floating workspace and the only way to fix it is to manually move it with mouse to the floating workspace and then use a keybind/command to move it to the tiling workspace again... ### Version Information This happens on 0.1.29 and even on master... ### Komorebi Configuration ```json (Can I leave this emtpy?! :P ) ``` ### Hotkey Configuration (Can I leave this emtpy?! 😅) ### Output of komorebic check (Can I leave this emtpy?! 😅)
adam added the bug label 2026-01-05 14:51:07 +01:00
adam closed this issue 2026-01-05 14:51:07 +01:00
Author
Owner

@alex-ds13 commented on GitHub (Oct 17, 2024):

@LGUG2Z I've already seen where the problem is and have some ideas to fix it. If you want you can assign this to me!

@alex-ds13 commented on GitHub (Oct 17, 2024): @LGUG2Z I've already seen where the problem is and have some ideas to fix it. If you want you can assign this to me!
Author
Owner

@alex-ds13 commented on GitHub (Oct 17, 2024):

This issue was first brought up on this discord support thread.

Another related issue was found there where using the move-window commands to a direction where it ends up moving them to another monitor or workspace also misbehaves if the target workspace is not tiling (floating mode). I'll have this one on a different PR.

I'm adding this comment here so I don't forget about this later... 😅 @LGUG2Z If you want me to instead open another issue for this one, I can do so...

@alex-ds13 commented on GitHub (Oct 17, 2024): This issue was first brought up on [this](https://discord.com/channels/898554690126630914/1296419073235619902) discord support thread. Another related issue was found there where using the `move-window` commands to a direction where it ends up moving them to another monitor or workspace also misbehaves if the target workspace is not tiling (floating mode). I'll have this one on a different PR. I'm adding this comment here so I don't forget about this later... 😅 @LGUG2Z If you want me to instead open another issue for this one, I can do so...
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/komorebi#496