Repository navigation
[Bug]: Windows UI shifts vertically while app is unfocused #5369
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/desktop
Steps to reproduce
- Open T3 Code on Windows.
- Switch to another application so the T3 Code window is in the background or unfocused.
- Look at the T3 Code window, then click it to bring it back into focus.
- Observe the UI immediately before and during the focus transition.
Expected behavior
The interface should remain in exactly the same position whether the window is focused or unfocused. Bringing the app to the foreground should not cause any visible layout movement or reflow.
Actual behavior
While the T3 Code window is in the background, the visible interface appears vertically shifted upward. The underlying layout or interactive regions seem to remain roughly a centimeter lower than where the interface is visually rendered, creating an apparent mismatch between what is displayed and where the UI is actually positioned.
As soon as I click the window and it becomes active again, the interface snaps or adjusts back into the correct position. This repeated vertical shift whenever the app changes between background and foreground is extremely distracting and frustrating during normal use.
Impact
Moderate degradation or recurring frustration
Version or commit
Unknown
Environment
Windows desktop app. Exact Windows and T3 Code versions were not captured.
Logs or stack traces
No response
Screenshots, recordings, or supporting files
A screen recording showing the window before and after focus would likely make the shift easiest to see, but none is currently attached.
Workaround
Clicking the T3 Code window and returning it to the foreground causes the layout to correct itself temporarily.
Activity
Jardo-51 commentedon Aug 5, 2026
I have noticed something similar in the browser. When switching to another tab, the "Syncing messages..." pill appears, which moves the whole thread content up. After switching back, it takes a second for the pill to disappear, causing the content to move back again:
2026-08-05_t3code_content_jump-.2.mp4
maria-rcks commentedon Oct 9, 2026
Note
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-08-05.
Is it still relevant on the current version? If so, your version and OS would help.
Jardo-51 commentedon Oct 10, 2026
I am not experiencing the issue I described in my comment anymore. My version is
0.0.43-nightly.20260926.2282.ElliotDrel commentedon Oct 21, 2026
Note
🤖 OpenAI assistant (exact model identifier unavailable) responding on behalf of Elliot
Glad to hear the browser behavior improved. I haven't retested my original Windows desktop report on recent releases, so I can't confirm whether it's fixed for me. Sorry I can't give a more helpful update.
For historical context, I filed this on August 4, 2026, when v0.0.31 was the latest stable release. My exact T3 Code and Windows versions weren't recorded, so that release is a date-based reference, not a confirmed installed version.
t3-code-bot commentedon Oct 29, 2026
closing as resolved at the request of @UtkarshUsername. @Jardo-51 confirmed that the related browser layout shift no longer occurs on
0.0.43-nightly.20260926.2282: #5369 (comment)that confirmation covers the browser behavior. the original Windows desktop reporter has not retested recent releases. if the desktop shift still occurs on a current version, please share the version and reproduction details so we can revisit it.
ElliotDrel commentedon Oct 31, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Elliot
Retested: the Windows desktop shift still happens, and the trigger is restoring a minimized window from the taskbar.
Environment: T3 Code (Beta) 0.1.5, Windows 11 Home build 26200
Steps: minimize T3 Code, then click it in the taskbar.
Result: for about 170ms (5 frames at 30fps) the layout sits about 15px too low and the panel buttons draw on top of the Windows minimize, maximize, and close buttons. It then snaps into place.
A half-speed recording will follow in a separate comment.
Root cause: on Windows, Electron reports an empty window controls overlay while the window is minimized. A small Electron 44.10 test window logged this:
overlay.visiblegetTitlebarAreaRect()true0,0,863,40false0,0,0,0env(titlebar-area-*)becomes undefined at that point, so the.wcovariables fall back to 52px and no reserved space. The page lays out that way while minimized, and that stale layout is what appears on restore until the corrected frame paints.The test window logged the bad geometry but was not filmed, and the real app has not been run with this logging. The recording does match it: the bar is 12 CSS px taller, about 15 screen px on this display, and the panel buttons move right into the window buttons' space.
Possible fix: while the overlay is visible on Windows desktop, save its height and button width as CSS variables, and use those as the
env()fallbacks instead of 52px and 0. Keep thewcoclass while minimized. Layout that relies onenv()is unchanged when the window is not minimized. In the same test window, the fallbacks held 40px and 137px through minimize and restore, both windowed and maximized.The earlier attempt in #5996 was closed during PR cleanup without being reviewed on its merits. In this test
visiblestayedtruein fullscreen, so its fullscreen IPC may not be needed.I have not confirmed whether plain loss of focus, as first reported above, has the same cause. Blur alone was not tested.
ElliotDrel commentedon Oct 31, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Elliot
Half-speed recording of the restore from my last comment, on T3 Code (Beta) 0.1.5:
t3code-windows-restore-shift-half-speed.mp4
Shifted frame above the settled layout:
Proposed fix: #27973