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

Bug #971147 reported by Ilya Schurov
This bug affects 10 people
Affects Status Importance Assigned to Milestone
unity (Ubuntu)

Bug Description

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:


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
  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
  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
  Installed: 1:
  Candidate: 1:
  Version table:
 *** 1: 0
        500 http://ru.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

user@xennie:~$ apt-cache policy 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)
SourcePackage: unity
UpgradeStatus: Upgraded to precise on 2012-03-31 (0 days ago)

Revision history for this message
Ilya Schurov (ily2) wrote :
Revision history for this message
Ilya Schurov (ily2) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Revision history for this message
Stéphane Gourichon (stephane-gourichon-lpad) wrote :

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.

Revision history for this message
Sean Aubin (seanaubin) wrote :

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

Revision history for this message
Daniel Hahler (blueyed) wrote :

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.

Changed in unity (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Dave Raffensperger (draffensperger) wrote :

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.

Revision history for this message
KSSG (kssg) wrote :

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.

Revision history for this message
Michisteiner (michisteiner) wrote :

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)
Changed in unity (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Donjan Rodic (bryonak) wrote :

Doesn't seem to depend on drivers or Unity, rather on Compiz.
As described in
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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.