Scrolling layout regressions

Bugs / FRs / Support
, ,
1
Hyprland version 
hyprctl version
Hyprland 0.53.0 built from branch main at commit b4ee4674f9a74e3d602c7fb17bc09f79d221583c clean (protocols: implement image-capture-source-v1 and image-copy-capture-v1 ( 11709)).
Date: Sun Feb 22 12:30:11 2026
Tag: v0.53.0-157-gb4ee4674f, commits: 6913

Libraries:
Hyprgraphics: built against 0.5.0, system has 0.5.0
Hyprutils: built against 0.11.0, system has 0.11.0
Hyprcursor: built against 0.1.13, system has 0.1.13
Hyprlang: built against 0.6.8, system has 0.6.8
Aquamarine: built against 0.10.0, system has 0.10.0

Version ABI string: b4ee4674f9a74e3d602c7fb17bc09f79d221583c_aq_0.10_hu_0.11_hg_0.5_hc_0.1_hlg_0.6
no flags were set

These are regressions compared to the latest version of hyprscrolling, but might be intentional for all I know.
It’s really messing with my workflow and I’d appreciate it being optional.

Basically, if you configure scrolling this way:

input:follow_mouse = 1

scrolling {
    fullscreen_on_one_column = false
    column_width = 0.333
    focus_fit_method = 0
    follow_focus = false
    follow_min_visible = 0
    explicit_column_widths = 0.25, 0.333, 0.5, 0.667, 0.75, 1.0
}

And you open at least 3 windows, hovering over a window that’s not currently centered won’t center it, which is good, but if you click inside of that window, or even try to drag and drop a file into it, it will get centered, that’s not good.

For example, say that you have these windows:
Discord | Element | Dolphin | Terminal
Center dolphin, try to drag and drop a file into matrix, and your cursor will end up on discord in the end.

Another example is trying to use a side window without centering it, for example, prompting ai while coding and using terminal for source control.
Browser(0.25) | Editor(0.5) | Terminal(0.25)
Previously, you could make the code editor take up most of the space and be in the center and use both side windows just fine, but now, trying to use either of the side windows will result in them getting centered, and that’s quite annoying.

Another minor issue that I discovered is the first(leftmost) window never getting centered with this config, it just fits into the screen when you scroll to it.
This one is way less annoying tho.

2

Actually found 2 more issue since I made the post.

  1. Newly created windows on an empty workspace don’t follow this setting:
    explicit_column_widths = 0.25, 0.333, 0.5, 0.667, 0.75, 1.0

You have to reload the config after creating a window on that workspace in order for it to work.

  1. If you drag the mouse over a window barely visible at the edge of the screen, follow_focus = false won’t be respected and that window will get centered anyways.
3

newly spawned windows should follow column_width AFAIU.

this should be controlled by follow_min_visible, and works for me…

1 Like
4

I’ve fixed the focus issues on git. Should be much better now.

1 Like
5

newly spawned windows should follow column_width AFAIU.

I worded that poorly, my bad.
Windows do indeed spawn with the column_width value.
What I meant is, cycling through values didn’t use the latest ones.
I just checked, this is also fixed on latest git, great!

this should be controlled by follow_min_visible, and works for me…

I will do further testing on git and report back, could 100% be on me.
Just checked, this issue is still present in latest git.
I have a super ultrawide so maybe that’s messing with the logic or something?
I use follow_min_visible = 0.

6

that’s the opposite of what you want. follow_min_visible is a ratio. If you set it to 0, it means “0% of the window needs to be visible for follow to kick in”. If you don’t want the auto switch to happen, set it to 1.

1 Like
7

It sadly doesn’t matter what I set it to, it just gets focused regardless.
It also seems that it only happens if the focused window is to the left, not to the right.
I made a short video to show the bug: