(fix) Reject resize_request on surfaces which are already being resized

[peterkrull]

Addresses #1526 and #2035

I added some log messages, and saw that certain applications (like Stream) would start two resize requests, creating a corrupted state. This patch just rejects the second resize event, if we are already resizing.

[Drakulix]

Seems sensible. Thanks!

[peterkrull]

Hmm, I had only tested this on the steam client, where it solves the issue, but it still seems broken on Clion..

[peterkrull]

On further review it seems that JetBrains products handle resizing differently, but the symptom of top/left resizing acting oppositely is similar. Specifically, they resize by requesting a specific position, but due to

cosmic-comp/src/xwayland.rs

Lines 911 to 912 in c569a35

	// We only allow floating X11 windows to resize themselves. Nothing else
	let shell = self.common.shell.read();

The position is ignored, and only the size is changed.

[Drakulix]

On further review it seems that JetBrains products handle resizing differently, but the symptom of top/left resizing acting oppositely is similar. Specifically, they resize by requesting a specific position, but due to

cosmic-comp/src/xwayland.rs

Lines 911 to 912 in c569a35

	// We only allow floating X11 windows to resize themselves. Nothing else
	let shell = self.common.shell.read();

The position is ignored, and only the size is changed.

So what is the effect here? Does the window still change it's size? Or is the JetBrains window waiting for the new position? We obviously don't want the window to change it's position in tiling mode.

[peterkrull]

On further review it seems that JetBrains products handle resizing differently, but the symptom of top/left resizing acting oppositely is similar. Specifically, they resize by requesting a specific position, but due to

cosmic-comp/src/xwayland.rs

Lines 911 to 912 in c569a35

	// We only allow floating X11 windows to resize themselves. Nothing else
	let shell = self.common.shell.read();

The position is ignored, and only the size is changed.

So what is the effect here? Does the window still change it's size? Or is the JetBrains window waiting for the new position? We obviously don't want the window to change it's position in tiling mode.

It is visually the same effect. Top left corner is anchored since its requested position is ignored, but the size changes.

2026-02-17.16-40-38.mp4

[Drakulix]

On further review it seems that JetBrains products handle resizing differently, but the symptom of top/left resizing acting oppositely is similar. Specifically, they resize by requesting a specific position, but due to

cosmic-comp/src/xwayland.rs

Lines 911 to 912 in c569a35

	// We only allow floating X11 windows to resize themselves. Nothing else
	let shell = self.common.shell.read();

The position is ignored, and only the size is changed.

So what is the effect here? Does the window still change it's size? Or is the JetBrains window waiting for the new position? We obviously don't want the window to change it's position in tiling mode.

It is visually the same effect. Top left corner is anchored since its requested position is ignored, but the size changes.
2026-02-17.16-40-38.mp4

Hmm, maybe we can relax the rule a bit in that case. Something like if the size changes, also allow position changes for floating windows, but reject pure position updates?

We don't want X11 apps to arbitrarily move themselves, as that has been abused in the past, but I'd like to make sure JetBrains IDEs are working somewhat reasonably well.

[hojjatabdollahi]

For what it's worth you can enable wayland support in Jetbrain IDEs which solves this issue (and also fractional scaling issues). And they're gonna make that the default in the upcoming version:
https://blog.jetbrains.com/platform/2026/02/wayland-by-default-in-2026-1-eap/

(Not saying we shouldn't fix the issue)