Master layout strange window focus changing behaviour

[queer-bird]

This isn't a bug that brings everything to a crash, but it is definitely a strange behavior.

It also seems difficult to isolate.

Sometimes I will have a workspace full of tiles and it will get stuck in a strange state where the buttons I usually press to "cyclenext" or "cycleprev" will only cycle between two of the open windows. They are stuck like this until I close them all. In this state I can close the master window and the others will still stay stacked on the right hand side of the screen as if it were still there. This state is isolated to a single workspace, I can go to another and things work like normal. It is very weird, in this state "cycleprev" will always swap between the master and the top right window, and "cyclenext" will always swap between the bottom right and the window above it.

I think it may have something to do with Firefox, as it frequently happens after I use Firefox and go back to playing with tiles...But I am likely totally wrong.

Sorry I can't be more specific, I've been trying to see what the trigger is for some time now but I just can't figure it out. I'm on Gentoo right now, but the same thing happened on Arch.

That all being said, I love the work you are doing. I was a long time dwm user, but Hyprland has really won me over, even though I turn off a lot of the selling points! (animations, gaps, rounding)

[patrickaldis]

I also have the same issue. But cannot work out the trigger

[vaxerski]

I need this to be reproducible, cuz I've never seen this.

[rezaamashi]

I have the same problem with stuck on focusing certain clients in master tiling . In my case I can cycleprev and cyclenext fine until I move a client from another workspace into said workspace. When that happen cyclenext would only focusing between master and topmost slave client (just between 2 of them). cycleprev would be able to break that cycle only to be stuck on focusing the slave clients, and vice versa for cyclenext.

As of writing this, while trying to get the trigger right in my case, the workspace where I move the client from, wp3, had this problem where it doesn't stack properly with the master client missing. After I close the client in wp3, there was a client that seemingly in different layer of the WM, I can't focus and hyprctl kill it. Only until after I move 3 clients from the testing workspace, wp1, that it fixes the tiling. But after the 4th clients it is the same problem as in the first paragraph.

[patrickaldis]

Yeah. I can confirm @rezaamashi I have the same trigger.

To summarise:

My configuration consists of

general {
    ...
    layout=master
    ...
}

master {
    new_is_master=false
}

Reproducible steps:

• open 2 windows on workspace 1
• open 1 window on workspace 2
• move window from workspace 2 -> 1 using movetoworkspacesilent

The master-stack layout on workspace 1 now has this weird behavior cycling through these windows

[shetozz]

IDK if my problem applies to the same issue or not, but basically cyclenext in full-screen mode changes the focus but doesn't swap the windows, so I end up with the unfocused window on top.

[rezaamashi]

I have the same problem with stuck on focusing certain clients in master tiling . In my case I can cycleprev and cyclenext fine until I move a client from another workspace into said workspace. When that happen cyclenext would only focusing between master and topmost slave client (just between 2 of them). cycleprev would be able to break that cycle only to be stuck on focusing the slave clients, and vice versa for cyclenext.

As of writing this, while trying to get the trigger right in my case, the workspace where I move the client from, wp3, had this problem where it doesn't stack properly with the master client missing. After I close the client in wp3, there was a client that seemingly in different layer of the WM, I can't focus and hyprctl kill it. Only until after I move 3 clients from the testing workspace, wp1, that it fixes the tiling. But after the 4th clients it is the same problem as in the first paragraph.

Haven't check on this issue for a while. But for now, the reproducible problem (the first paragraph) is fixed in the latest hyprland-git from AUR. So far I only experienced the problem missing/phantom client once. But as the nature of it was irreproducible I can't get the hang of what was the cause.

[vaxerski]

There have been numerous improvements to master since this issue was opened, but I've never been able to repro this. I'll let the original reporters report back on the issue @queer-bird @patrickaldis