---
title: Chromium window launched from the panel can't be resized on X11 (first resize hangs, frame shows what's behind)
date: 2026-10-15
summary: On X11, a Chromium window started from a panel or menu launcher with StartupNotify=true never acknowledges its first _NET_WM_SYNC_REQUEST, so KWin freezes the resize or grows the frame without a repaint. Unset DESKTOP_STARTUP_ID in the launcher.
tags: x11, chromium, kwin, window-manager, startup-notification
environment: Arch Linux (kernel 7.2); Chromium 152.0.7977.82 (stock Arch package, and a locally patched build); KWin 6.7.5 (kwin_x11) with OpenGL compositing; xfce4-panel 4.20.8 launcher; NVIDIA driver 610 on X11
author: shaun, written up with claude
status: published
---

## Symptoms

A **newly opened** Chromium window on an X11 desktop refuses to resize:

- Dragging a side or corner does nothing, or moves it by a single pixel and then stops.
- Or, after several seconds, the window frame does grow, but Chromium doesn't repaint. The new strip shows whatever was behind the window (stale pixels from another app), and the top edge flickers while you drag.
- Minimize/restore, maximize/restore and further resizes don't fix it. The window stays broken until it's closed.

Two details tell this apart from other Chromium resize bugs:

1. It always happens on the window's **first** resize. A window that survives its first resize keeps working for the rest of its life.
2. It only affects windows **opened from a panel/taskbar launcher or menu entry**. Windows opened with Ctrl+N, or from a terminal, are fine. That makes it look random, and makes it hard to reproduce from a script.

There are no errors in the journal, and Chromium doesn't log anything.

## Root cause

KWin (like other compositing WMs) uses the EWMH `_NET_WM_SYNC_REQUEST` protocol for resizes. Before each configure, it sends the client a sync request with a counter value. The client is supposed to set its XSync counter (`_NET_WM_SYNC_REQUEST_COUNTER`) to that value once it has drawn a frame at the new size. KWin waits for that acknowledgement before it applies the next step.

When a launcher with `StartupNotify=true` starts Chromium, the launcher puts a startup-notification ID in the environment (`DESKTOP_STARTUP_ID`). Chromium copies it to the new window as `_NET_STARTUP_ID`. **A window with that property never acknowledges its first sync request.** A passive trace of a stuck window looks like this:

```
00:53:36.667 window       0x3c0001f            (new window, launched from the panel)
00:53:36.668 sync-request counter=1  -> set-counter 1      (map: acked)
00:53:38.444 sync-request counter=2                         (first user resize)
             ... no set-counter, ever ...  live XSyncQueryCounter -> 1
```

The WM then either keeps waiting, so the window can't be resized, or (KWin, after about 11 s) gives up and resizes the frame while the client still hasn't drawn into it, which shows stale pixels.

Proven by a deterministic A/B on the same desktop, profile and binary, using the same synthetic 1-pixel-step resize drag:

| How the window was opened | `_NET_STARTUP_ID` | First resize |
|---|---|---|
| Click on the panel's Chromium launcher | `xfce4-panel/…_TIME…` | stuck, counter stays at 1 |
| Terminal, `DESKTOP_STARTUP_ID=test_TIME123 chromium --new-window` | set | stuck, counter stays at 1 |
| Terminal, no `DESKTOP_STARTUP_ID` | none | fine, counter 1→22 |
| Panel launcher **after the fix** (twice) | none | fine, 1→25 and 1→27 |

It reproduced on both the stock Arch Chromium 152 and a locally patched build. *Inference, not verified in Chromium's source:* the startup-notification code path seems to defer or skip the frame that would complete the first sync. Only tested under KWin. Other WMs that use `_NET_WM_SYNC_REQUEST` (xfwm4, Openbox, Mutter on X11) probably behave the same way, but that hasn't been checked.

## Fix

Stop the startup ID from reaching Chromium. Do this in whatever the launcher runs. A small wrapper script is the easiest place:

```bash
#!/bin/bash
# A startup-notification ID makes Chromium's new X11 window never ack its
# first _NET_WM_SYNC_REQUEST, so the window can't be resized.
unset DESKTOP_STARTUP_ID XDG_ACTIVATION_TOKEN
exec /usr/bin/chromium "$@"
```

Point the panel launcher's or menu `.desktop` entry's `Exec=` at that wrapper. Alternatively, set `StartupNotify=false` in the `.desktop` file. Check both your menu entry (`~/.local/share/applications/`) and any copy the panel keeps for itself. xfce4-panel, for example, stores its own under `~/.config/xfce4/panel/launcher-N/`.

**Caveat:** the panel's "launching…" busy cursor no longer gets cleared by the new window, so it spins until it times out. Nothing else changes.

**Recovering a window that's already stuck:** drag its tabs out into a new window, then close the stuck one. For the last tab, open a blank tab first, then drag the last real tab out. You don't need to restart the browser.

## How it was found

- A passive tracer (python-xlib) logged every `_NET_WM_SYNC_REQUEST` the WM sent, every client `XSyncSetCounter`, and all configure events for Chromium windows. Every broken window showed sync request #2 (its first resize) unacknowledged. Every healthy window acknowledged every request.
- Synthetic XTest drags, run by a script on windows opened from a terminal, **never** reproduced it. That ruled out (wrongly, it turned out) the idea that it was always present. Other things ruled out along the way: the browser profile, the GPU/compositor, the new-tab page, the window sitting idle a long time, another Chrome instance starting, and a periodic headless-Chromium job.
- The break came from a passive X input log. Every stall was preceded, 2–4 s earlier, by a click at the same spot on the panel, and a new Chromium window appeared about 0.3 s after each click. Clicking the panel launcher from the test script reproduced the stall on the first try, and setting `DESKTOP_STARTUP_ID` from a terminal reproduced it too.

## References

- EWMH, `_NET_WM_SYNC_REQUEST`: <https://specifications.freedesktop.org/wm-spec/latest/>
- Startup Notification spec (`DESKTOP_STARTUP_ID`, `_NET_STARTUP_ID`): <https://specifications.freedesktop.org/startup-notification-spec/latest/>
- Related but different Chromium X11 bug: [Chromium window drag warps the window (xfwm4) or the cursor (KWin) on X11](https://www.misc2.com/technotes/chromium-x11-drag-warp-net-wm-moveresize/)