What happens
Switching the recording bar to the vertical layout and back moves it up the screen. On Windows 11 at 125 % scaling (2.0.0-rc.1, same code on main), each vertical→horizontal round trip left the bar about 130 DIP (162 px) higher than where it started. It repeats on every round trip, so a few toggles walk the bar toward the top of the screen.
Measured with the window bounds (DIP):
| Step |
HUD window |
| Launch (horizontal) |
316, 149, 908×697 |
| → vertical |
446, 19, 649×827 (correct: bar bottom-centre kept) |
| → horizontal |
432, 19, 936×697 (expected ≈ 316, 149) |
The window keeps its top-left instead of re-anchoring on the bar's bottom-centre, which is what hudResizeBounds is written to do.
Cause
Logged the two HUD IPC channels in the main process during the flip:
set-size 648×826 content [297,229,54,577] bounds before [316,149,908,697]
content [427,99,54,577] bounds before [446,19,649,827] <- stale
Right after hud-overlay-set-size, the renderer's ResizeObserver fires measureHudSize again. It reports the stack rect through hud-overlay-content, measured in the old viewport: [427,99] is the vertical bar centred in the 908×697 window. By then the main process has already resized the window to 649×827, and it stores that rect as hudContentRect. The next set-size anchors on it, and the result is exactly the bounds above.
The stack is always centred and pinned HUD_BAR_BOTTOM above the window's bottom edge (the comment on grantedContent already says so). So its rect can be computed from the allocated size, like grantedContent is, instead of being measured a frame too early.
Fix
In LaunchWindow.tsx, build the reported content rect from the allocated window size, with the same formula as grantedContent. Only its size comes from the measurement.
What happens
Switching the recording bar to the vertical layout and back moves it up the screen. On Windows 11 at 125 % scaling (2.0.0-rc.1, same code on
main), each vertical→horizontal round trip left the bar about 130 DIP (162 px) higher than where it started. It repeats on every round trip, so a few toggles walk the bar toward the top of the screen.Measured with the window bounds (DIP):
316, 149, 908×697446, 19, 649×827(correct: bar bottom-centre kept)432, 19, 936×697(expected ≈316, 149)The window keeps its top-left instead of re-anchoring on the bar's bottom-centre, which is what
hudResizeBoundsis written to do.Cause
Logged the two HUD IPC channels in the main process during the flip:
Right after
hud-overlay-set-size, the renderer'sResizeObserverfiresmeasureHudSizeagain. It reports the stack rect throughhud-overlay-content, measured in the old viewport:[427,99]is the vertical bar centred in the 908×697 window. By then the main process has already resized the window to 649×827, and it stores that rect ashudContentRect. The nextset-sizeanchors on it, and the result is exactly the bounds above.The stack is always centred and pinned
HUD_BAR_BOTTOMabove the window's bottom edge (the comment ongrantedContentalready says so). So its rect can be computed from the allocated size, likegrantedContentis, instead of being measured a frame too early.Fix
In
LaunchWindow.tsx, build the reported content rect from the allocated window size, with the same formula asgrantedContent. Only its size comes from the measurement.