Tk Source Code

View Ticket
Login
Ticket UUID: 4c5184d97445eae528a6c9647e171799a6e57d6d
Title: X11: wm deiconify loses the position of a window moved by the user
Type: Bug Version: 8.6.18, 9.0.5, 9.1.0
Submitter: serhiy.storchaka Created on: 2026-10-03 15:17:44
Subsystem: 67. Unix Window Operations Assigned To: jan.nijtmans
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2026-10-04 17:15:47
Resolution: Fixed Closed By: jan.nijtmans
    Closed on: 2026-10-04 17:15:47
Description:

If the window manager placed a toplevel and the user then moved it, wm withdraw and wm deiconify place it anew instead of returning it to where the user left it. KWin and openbox center it, icewm puts it in the top-left corner:

button .b -text "withdraw + deiconify" -command {wm withdraw .; after 500 wm deiconify .}
pack .b

Move the window, then click the button.

When a withdrawn window is mapped again, the window manager places it as a new window unless WM_NORMAL_HINTS has USPosition or PPosition. Tk sets them only if the program specified the position (wm geometry +x+y or wm positionfrom). With wm geometry . +100+100 the window returns to the position where the user moved it.

On Windows the window keeps its position.

User Comments: jan.nijtmans added on 2026-10-04 17:15:08:

Fixed in [0df196cee12eed25|trunk], core-9-0-branch and core-8-6-branch

Many thanks!


serhiy.storchaka added on 2026-10-03 15:42:37:

Proposed fix in branch x11-withdraw-keep-position: when a window that has been mapped is withdrawn, Tk sets USPosition in its size hints, so the window manager keeps its position when it is mapped again. Tested with KWin, icewm, openbox and fvwm (fvwm ignores PPosition).

If the screen gets smaller while the window is withdrawn, the window is now handled like a window positioned by wm geometry +x+y: icewm moves it onto the screen, but openbox and fvwm can leave it partly or completely off-screen.