xdotool and wmctrl don't move and resize windows after they are (semi)maximized

[Ilya Schurov]

The command

/usr/bin/xdotool windowmove `/usr/bin/xdotool getwindowfocus` 0 0

is supposed to move currenly selected window to the top left corner. It works fine on clean start, but after I maximize (or half-maximize) and then restore some window, it becomes "broken", and this command silently do nothing with it. The same holds for appropriate wmctrl command like

wmctrl -i -r `/usr/bin/xdotool getwindowfocus` -e 10,0,0,-1,-1

This affects Unity desktop, but does NOT affect Gnome shell desktop, so I believe it's a bug somewhere in Unity.

The same issue is discussed in the following thread:

http://ubuntuforums.org/showthread.php?t=1414155&page=2

It seems to affect both 11.10 and 12.04 (but I checked only 12.04).

user@xennie:~$ lsb_release -rd
Description: Ubuntu precise (development branch)
Release: 12.04

user@xennie:~$ apt-cache policy unity
unity:
  Installed: 5.8.0-0ubuntu2
  Candidate: 5.8.0-0ubuntu2
  Version table:
 *** 5.8.0-0ubuntu2 0
        500 http://ru.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

user@xennie:~$ apt-cache policy xdotool
xdotool:
  Installed: 1:2.20110530.1-3ubuntu1
  Candidate: 1:2.20110530.1-3ubuntu1
  Version table:
 *** 1:2.20110530.1-3ubuntu1 0
        500 http://ru.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages
        100 /var/lib/dpkg/status

user@xennie:~$ apt-cache policy compiz
compiz:
  Installed: 1:0.9.7.2-0ubuntu4
  Candidate: 1:0.9.7.2-0ubuntu4
  Version table:
 *** 1:0.9.7.2-0ubuntu4 0
        500 http://ru.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

user@xennie:~$ apt-cache policy xorg
xorg:
  Installed: 1:7.6+12ubuntu1
  Candidate: 1:7.6+12ubuntu1
  Version table:
 *** 1:7.6+12ubuntu1 0
        500 http://ru.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: unity 5.8.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.2.0-21.34-generic 3.2.13
Uname: Linux 3.2.0-21-generic x86_64
ApportVersion: 2.0-0ubuntu2
Architecture: amd64
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Mon Apr 2 02:50:17 2012
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity
UpgradeStatus: Upgraded to precise on 2012-03-31 (0 days ago)

[Ilya Schurov (ily2)]

This also may be related to https://bugs.launchpad.net/ubuntu/+source/wmctrl/+bug/582348, but I'm not sure.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stéphane Gourichon (stephane-gourichon-lpad)]

Bug confirmed on clean install of 12.04 Precise (I can provide more details on request).

This breaks many of the uses of xdotool and wmctrl.

(Context information) The new Unity desktop becomes handy with those Ctrl-Alt-arrow and Ctrl-Super-(Left|Right) to quickly position windows in a (physical) screen. This is fine if you have one screen. Having two screens you soon miss the ability to move windows between screens with a keystroke. I hacked a script for that, but this bug breaks it for all practical purpose.

[Sean Aubin (seanaubin)]

Gouri, would you mind posting or sending me the script that you used as a work-around?

[Daniel Hahler (blueyed)]

I have just tried to reproduce this on Ubuntu 13.10, but could not do so.
I noticed however, that the window gets moved sometimes from the right to the left screen, but sometimes only to the upper left of the right screen.

Besides, for moving a window to the next/previous output, you can use Unity's "Put" plugin. I have mapped Ctrl-Alt-n to move a window from one output to the next.

[Launchpad Janitor (janitor)]

[Expired for unity (Ubuntu) because there has been no activity for 60 days.]

[Dave Raffensperger (draffensperger)]

I am using Ubuntu 14.10 and I have this same issue though perhaps a slightly more general case of it. For me wmctrl and xdotool don't move or resize windows at all as far as I can tell. I would like to be able to customize window sizes to display something e.g. 2/3rd of the screen and something else 1/3rd of the screen with quick keystrokes that run those commands.

[KSSG (kssg)]

I have a similar issue with wmctrl in 15.04. Trying to place a window in the top-left corner, right next to the launcher, doesn't work.

"wmctrl -r :ACTIVE: -e 1,0,0,1240,1034" will place the window about 5 pixels to the right no matter what. If I try to place a window on the top right corner "wmctrl -r :ACTIVE: -e 1,1280,0,640,360" it's 5 pixels below where it should be. I can't find any explanation and I can confirm it works in other desktops. Other operations like "wmctrl -r :ACTIVE: -e 1,1280,720,640,335" work as expected, though, it just seems to have something against the left edge and top edge.

I am not sure if this is the right bug to post into, but they are pretty similar so they might be related.

[Michisteiner (michisteiner)]

i have the same experience as dave and KSSG, although on 14.04. My suspicion is it happens only with nvidia driver, not the intel one. but are not 100% sure ..

[Donjan Rodic (bryonak)]

Doesn't seem to depend on drivers or Unity, rather on Compiz.
As described in
http://askubuntu.com/questions/576604/what-causes-the-deviation-in-the-wmctrl-window-move-command
both xdotool and wmctrl report the correct (inner) position of the window, but for moving use the decorated (outer) size.

For example, this should leave a terminal window at exactly the current position:
xdotool windowmove --relative `xdotool getactivewindow` x y
But instead it moves it by the decoration size, which you can find out with xprop looking at the _NET_FRAME_EXTENTS(CARDINAL) variable
In my case,
xdotool windowmove --relative `xdotool getactivewindow` -1 -28
leaves the terminal window at the current position.

This would be solved if we could move the window with -100 further to the left (so the decoration part is off the screen), but unfortunately there seems to be a hard gap blocking it.