Regression: windows not centered after exiting fullscreen in scrolling layout (since 96de3464)

[Haku-taku]

Hyprland version

Hyprland 0.55.0 built from branch upstream_main at commit 5a7078d dirty (internal: fix bugs revealed by hu update).

Regression

yes

Describe the bug

Since commit 96de346, after entering and then exiting fullscreen, the window does not fully center – it is offset to the left by a few pixels.

I found this issue in a build from the Git repository. Meanwhile, in my test, the 0.55.4 tagged release does not have this problem. I then manually performed a binary search by checking out various commits and building/testing each one to determine when the issue first appeared.

Commit 96de3464 split RECALCULATE_REASON_TOGGLE_FULLSCREEN into TOGGLE_DEFAULT_HANDLED_FULLSCREEN and TOGGLE_LAYOUT_HANDLED_FULLSCREEN, and added both to the soft-recalculate list in isHardRecalculateReason. This was intentional — entering fullscreen already calls centerOrFitCol explicitly in requestFullscreen, so a hard recalculate would be redundant.

However, exiting fullscreen goes through a different path:

1. requestFullscreen(FSMODE_NONE) -> calls clearFullscreenTarget -> restores the column width from restoreColumnWidth, but does not call centerOrFitCol
2. CSpace::setFullscreen then calls recalculate(TOGGLE_LAYOUT_HANDLED_FULLSCREEN), which is soft. So the ScrollingAlgorithm does not scroll the viewport
3. The column shrinks back to normal width, but the viewport stays at its fullscreen position -> the window appears off-center

Before the commit, recalculate() was called with RECALCULATE_REASON_UNKNOWN (hard), which masked this gap by forcefully scrolling the viewport on every recalculate.

I fixed it by adding centerOrFitCol in clearFullscreenTarget after restoring the column width:

diff --git a/src/layout/algorithm/tiled/scrolling/ScrollingAlgorithm.cpp b/src/layout/algorithm/tiled/scrolling/ScrollingAlgorithm.cpp
index 8d21cc4c..f05aba60 100644
--- a/src/layout/algorithm/tiled/scrolling/ScrollingAlgorithm.cpp
+++ b/src/layout/algorithm/tiled/scrolling/ScrollingAlgorithm.cpp
@@ -1255,8 +1255,10 @@ void CScrollingAlgorithm::clearFullscreenTarget(std::vector<SFullscreenScrollSta

         clear(TARGET);

-        if (const auto COL = TDATA ? TDATA->column.lock() : nullptr; COL && it->restoreColumnWidth)
+        if (const auto COL = TDATA ? TDATA->column.lock() : nullptr; COL && it->restoreColumnWidth) {
             COL->setColumnWidth(*it->restoreColumnWidth);
+            m_scrollingData->centerOrFitCol(COL);
+        }

         it = fullscreenTargetList.erase(it);
     }

This mirrors what requestFullscreen(FSMODE_FULLSCREEN) already does on the enter path (lines 1041/1045).

Reproduction steps

1. Open a window
2. Make it 100% width (so we can see the bug more clearly)
3. Fullscreen it and then exit fullscreen with either hl.dsp.window.fullscreen or hl.dsp.window.fullscreen_state

System info and config

hyprctl.txt

[vaxerski]

@erstarr

[erstarr]

centerOrFitCol isn't called in unFS intentionally.

Consider:

0.5 | 0.8 --> 0.5 | FS
You scroll to 0.5, then unFS the right col.
The expectation is that the right col unFSes without moving the viewport to fit the 0.8 width column into view.

unFS action is more the restoration of state, so it shouldn't move viewport imo. Especially since it's possible to dispatch FS states to windows that aren't what you are focused on.

The real bug is the fact that it shifts left by a few pixels.

This also happened if you FS and unFSed a window pre 0.55 (scroll FS added) - the viewport would shift by a few pixels though it shouldn't have.

I've added this as a bug to be fixed in #14705. Please help test when it's ready

[Haku-taku]

0.5 | 0.8 --> 0.5 | FS You scroll to 0.5, then unFS the right col. The expectation is that the right col unFSes without moving the viewport to fit the 0.8 width column into view.

That's a very good example. I've got it.

unFS action is more the restoration of state, so it shouldn't move viewport imo. Especially since it's possible to dispatch FS states to windows that aren't what you are focused on.

In my previous thinking, I had assumed that we will only operate on a focused window, which now proves to not fully account for all cases. The few-pixel shift is definitely the root issue.

And I will keep an eye on #14705 and help test once it progresses.

[winkelnp]

This is still an issue in v56.0, unfullscreening a window leaves it stuck to the right side.

2026-07-23.12-06-03.mp4

[erstarr]

#15716