microsoft / microsoft/vscode

Linux/X11: restored window height is clamped to 1080 on a 4K display in a mixed-resolution layout

Open
#325,956 1 comment 2 reactions 1 assignee Claimed by @deepak1556 View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## Type of issue
Bug

## Environment

- VS Code: `1.128.1` (`5264f2156cbcd7aea5fd004d29eaa10209155d66`, x64)
- Electron: `42.5.0`
- Chromium: `148.0.7778.271`
- Node.js: `24.17.0`
- OS: Ubuntu 26.04 x64, kernel `7.0.0-27-generic`
- Desktop: KDE Plasma `6.6.5`, KWin `6.6.4`
- Session: X11; renderer command line confirms `--ozone-platform=x11`
- Extensions disabled: not tested; the incorrect size occurs during native `BrowserWindow` creation before the renderer reports ready
- VS Code Insiders: not tested

Monitor layout, all scale 1:

```text
DP-1-0 3840x2160 +1920+0 (primary)
eDP-1 1920x1080 +0+1080
DP-1-2 1920x1080 +5760+0
HDMI-1-0 1920x1080 +5760+1080
virtual desktop: 7680x2160
```

## Steps to reproduce

1. Open two normal, non-maximized VS Code windows on the 3840x2160 primary display.
2. Resize both windows taller than 1080 pixels.
3. Exit cleanly using **File > Exit**.
4. Confirm `windowsState` in `User/globalStorage/storage.json` contains the tall heights.
5. Start VS Code again with `code --log trace`.
6. Compare the trace's restored/constructor state with the mapped X11 geometry (`xwininfo`).

## Expected behavior

Each window is mapped with the exact saved `x`, `y`, `width`, and `height`.

## Actual behavior

`x`, `y`, and width are restored exactly, but both heights are deterministically clamped to `1080`. VS Code then observes and persists the reduced heights, so the original tall state is lost.

First reproduction:

| Window | Saved before restart | Live after restart |
|---|---:|---:|
| Workspace | `3779,28 1870x2038` | `3779,28 1870x1080` |
| Folder | `3837,28 1919x2076` | `3837,28 1919x1080` |

Second reproduction:

| Window | Saved before restart | Live after restart |
|---|---:|---:|
| Workspace | `3972,28 1784x2037` | `3972,28 1784x1080` |
| Folder | `3919,65 1744x1962` | `3919,65 1744x1080` |

## Trace evidence

The main-process trace shows that VS Code reads, validates, and passes the correct geometry to the constructor:

```text
window#validateWindowState: validating window state on 4 display(s) {"mode":1,"x":3972,"y":28,"width":1784,"height":2037}
window#validateWindowState: multi-monitor working area {"x":1920,"y":0,"width":3840,"height":2160}
window#ctor: using window state {"mode":1,"x":3972,"y":28,"width":1784,"height":2037}

window#validateWindowState: validating window state on 4 display(s) {"mode":1,"x":3919,"y":65,"width":1744,"height":1962}
window#validateWindowState: multi-monitor working area {"x":1920,"y":0,"width":3840,"height":2160}
window#ctor: using window state {"mode":1,"x":3919,"y":65,"width":1744,"height":1962}
```

The mapped X11 windows nevertheless become `1784x1080` and `1744x1080`.

## Controlled tests

- `--force-device-scale-factor=1`: no change; both heights still become 1080.
- `"window.titleBarStyle": "native"`: reproduces.
- `"window.titleBarStyle": "custom"`: reproduces; alternate frameless path confirmed by Motif hints and absent `_NET_FRAME_EXTENTS`.
- No KWin rule matches VS Code position or size.
- KWin reports the primary work area correctly and other normal windows (Firefox, Brave, Obsidian) can be taller than 1080 on the same display.
- Storage databases pass integrity checks and shutdown is clean.

## Source-path observation and workaround

The current `CodeWindow.applyState()` reapplies `BrowserWindow.setBounds()` after construction on macOS and Windows, but not Linux. This is the workaround added for macOS/Windows multi-display creation issues in #74872 and #155589.

A local user-level proof that sends `_NET_MOVERESIZE_WINDOW` after the VS Code windows map restores the exact saved bounds. An end-to-end test restored these native-titlebar windows correctly:

```text
3923,28 1784x2015
3851,61 1744x1873
```

This suggests that extending the existing post-construction `setBounds()` workaround to Linux/X11 may address the defect without changing persistence or validation logic.

Related but not identical: #170001 (gradual bounds drift). This report is a deterministic height-only clamp to the smaller displays' `1080` height.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.