[dev] dwm floating rule does not sanitize window geometry from previous WM

[Ricardson]

Hi,

I run dwm with Firefox assigned to tag 1 as floating. I was previously using 1wm, a minimal WM that blindly moves every window to 0,0 on ConfigureRequest with no EWMH awareness. This leaves Firefox with corrupted geometry in its session state.

When switching to dwm with isfloating = 1, dwm inherits that bad geometry as-is Firefox covers the entire screen including the bar, making tags and slstatus invisible.
The interesting part: temporarily switching the rule to isfloating = 0, recompiling, and restarting dwm corrects the geometry because tiling mode recalculates window placement itself. Switching back to isfloating = 1 and recompiling again then works correctly.

This suggests dwm floating mode accepts incoming window geometry without validation, while tiling mode is more resilient because it ignores client-requested geometry entirely. It may be worth dwm clamping floating window geometry against monitor bounds on map, at least to prevent windows from covering the bar.

----
Kind regards,
Ricardson (r1w1s1)

[NRK]

Hi Ricardson,

> This suggests dwm floating mode accepts incoming window geometry
> without validation, while tiling mode is more resilient because it
> ignores client-requested geometry entirely. It may be worth dwm
> clamping floating window geometry against monitor bounds on map, at
> least to prevent windows from covering the bar.

If I run:

nsxiv -g 1920x1080 ~/pictures

On a standard 1080p resolution monitor with nsxiv set to floating in
config.h, then I expect the nsxiv window will take up the whole screen.
Why should the WM prevent me from doing that?

Also, terms like "sanitize/validate" are used when input is coming from
a potentially malicious source. dwm doesn't deal with malicious sources
because if a malicious source can create windows in your xorg session
then you're compromised already.

- NRK

[Ricardson]

Hi NRK,

You're right, "sanitize/validate" was the wrong framing -apologies for that.

And the nsxiv -g example is a valid point. A user explicitly requesting a specific geometry should be respected.

In my case the root cause is 1wm, which moves every window to 0,0 on ConfigureRequest with no EWMH awareness, leaving Firefox with corrupted session state. When switching to dwm that stale geometry gets inherited. So the bug is really in 1wm, not dwm.

Thanks for the clarification

----
Ricardson (r1w1s1)

[Страхиња Радић]

2026-02-22T18:22:35Z Ricardson <r1w...@fastmail.com>:

> In my case the root cause is 1wm, which moves every window to 0,0 on
> ConfigureRequest with no EWMH awareness, leaving Firefox with corrupted
> session state.

The root cause is Firefox, which should include a built-in mechanism to
override the saved geometry without erasing or manually altering the
saved state. Likewise, recent versions of Firefox unfortunately use
Wayland, so useful X.Org-based tools, such as wmctrl, won't be able to
manipulate its window. I'm talking about somwthing like

wmctrl -r Firefox -e 0,100,100,640,480
# | | | | height
# | | | width
# | | Y position
# | X position
# gravity

You could alter xulstore.json using jq:

cfgfile=$(find ~/.config/mozilla -name xulstore.json | sed 1q)
mv "$cfgfile" "$cfgfile.bak"
jq '.[]."main-window" |= {
screenX: "100",
screenY: "100",
width: "640",
height: "480",
sizemode: "normal"
}' "$cfgfile.bak" > "$cfgfile"

or simply delete the file and have Firefox regenerate it.