Applications that save position re-open at wrong location (shifted by window decorations)

Bug #155101 reported by Victor Osadci on 2007-10-20
This bug affects 13 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)

Bug Description

Binary package hint: nautilus

When using nautilus in spatial mode, with compiz enabled, windows appear lower by the size of the title bar, each time they are opened.

To reproduce:
1. Move a nautilus window to the top of the desktop;
2. Open the window;
3. Close the window;
4. Repeat step 2 and 3 several times;

The window is now a lot lower than is initially was.

Chris Halse Rogers (raof) wrote :

I see this also, although not with all windows: Opening the home folder (places->Home folder) works as expected - it always appears in the same place. However, repeadedly opening and closing a folder from that home directory window does display this bug.

Tested with both gtk-window-decorator and emerald, both show the same behaviour.

Changed in compiz:
importance: Undecided → Low
status: New → Confirmed

  The bug is either with compiz or gtk-window-decorator, and it does not affect only Nautilus windows but many others as well. For example, GIMP and Pidgin will both open exactly the height of the title bar lower than where they were at the time of closing. But they do not keep descending after that.

  The reason why I am mentioning gtk-window-decorator is because this issue does not manifest itself when the decorations are off, i.e. all the windows reopen on the positions as were saved with the session manager.

  In response to my own input above: Pidgin, GIMP and other windows *do* keep descending, just like Victor and Chris had originally reported for Nautilus. Plus, the windows seem to move to the right by the width of the decoration border, too; this should be a good clue to the developers.

  Also: while turning off decorations apparently keeps the windows in place (quite obvious, though), different window placing strategies (smart, cascade, random -- as configured in the Place plugin) all exhibit this behavior. Likely to have something to do with reporting the window geometry to the session manager when it's being closed.

Victor Osadci (victor-os) wrote :

Confirming this on hardy alpha 6.

Danny Baumann (dannybaumann) wrote :

While I personally can't reproduce the problem, I think the problem may be the one in this Gnome bug:

At least this bug causes Rhythmbox sometimes being incorrectly placed by the amount of frame size when switching between small and full mode.

savage (savage) wrote :

I have a similar problem (current version of Hardy), which may be the same issue as here, only with gnome-terminal. If I save my gnome session, a terminal window in the upper left corner is taken to have a geometry "100x32+5+24", as found in the saved session file (~/.gnome2/session). The +5+24 corresponds to the width of the border and title bar. If I open up several terminals in rapid succession, with a script such as:

gnome-terminal --geometry 100x32+5+24 &
gnome-terminal --geometry 100x32+5+24 &
gnome-terminal --geometry 100x32+5+24 &
gnome-terminal --geometry 100x32+5+24 &

the windows will randomly be placed in the upper left or +5+24 from the upper left (except the first one always seems to be upper left). The randomness disappears if the Compiz "Window Decoration" option is turned off (so windows have no border/title bar): all windows are +5+24.

I suspect this is a timing issue between placing the window and adding the border/title bar. Adding a border to an existing window seems to shift the window to maintain the position of the corner, but I do not think there is any shift if the border already exists when the window is placed. So it seems the final position is going to depend upon which action is performed first: placing the window or adding the border. Maybe the order of those events is not fixed? (This is only a guess at what is going on. I don't know much about the internals of Gnome and Compiz.)

More details here:

I don't know if this is the same problem as the one Danny Baumann links to.

The Fiddler (stapostol) wrote :

This is still an issue in Intrepid (both x86 and amd64 versions). Has the bug been reported upstream?

summary: - nautilus windows position changes each time the window is opened
+ Applications that save position re-open at wrong location
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
summary: - Applications that save position re-open at wrong location
+ Applications that save position re-open at wrong location (shifted by
+ window decorations)
Travis Watkins (amaranth) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at Thanks again and we appreciate your help.

The bug Danny mentioned has been fixed in GTK+ so I believe this problem is resolved now. I have not been able to reproduce it with karmic.

Changed in compiz (Ubuntu):
status: Triaged → Incomplete
Botond Szász (boteeka) wrote :

I can confirm that it is still reproducible in Karmic too. It is observable with Skype and Pidgin, which close their windows but remain running in the notification area. Whenever these programs' icons get a click in the notification area they show/hide their windows, but whenever the windows gets shown they are always redisplayed a little bit lower and a little bit to the right until they reach the bottom panel.

Andrew Chadwick (achadwick) wrote :

Small python script to assist future testers. This is still present in Karmic under Compiz, but not under Metacity. Repeated bouncing on the Tab key shows and hides the small utility window, causing it to gradually move down the screen with {compiz-gnome 1:0.8.4-0ubuntu2.1, python-gtk2 2.16.0-0ubuntu1, libgtk2.0-0 2.18.3-1ubuntu2.1} at least.

HeWhoE (hewhoe) wrote :

In the newest release, 10.04 (Lucid Lynx), I notice this issue when hiding and unhiding the GIMP Toolbox by pressing the TAB key. A way to work around the issue with the GIMP Toolbox is to tell compiz to always place the window in a fixed position:

1. In the CompizConfig Settings Manager, go to Place Windows (in the Window Management section) and click on the Fixed Window Placement tab.

2. In the "Windows and fixed positions" box, click on New. An Edit window will pop up.

3. In the Edit window, enter title=Toolbox in the "Position windows" box. Then enter 0 for both the X and Y positions. Finally, put a check mark in the box for "Keep In Workarea" (otherwise, the Toolbox window will always be off the screen.

HeWhoE (hewhoe) wrote :
arpl (aris-plakias-gmail) wrote :

This is fixed in Maverick. At least this is the case with the Skype window.

Martinique (nouseva-voima) wrote :

I still experience this in Maverick, with applications which can be minimized to tray, such as Pidgin and Gwibber. I've struggled with more show-stopping display bugs, so I haven't really followed if this particular behaviour has remained unchanged through 8.xx and 9.xx versions.

Unlike described in earlier comments, in my case the affected windows move upwards and and a little to the left with each reopening, eventually causing the titlebar to end up behind the top panel. If one keeps clicking the tray icon to close and reopen the window, eventually Compiz (or whatever causes this) seems to realize its mistake and pops the window back below the panel instead of behind it.

Apparently the time between closing and reopening matters; If the closing animation is still running when the window is reopened, the positioning always goes wrong.

Steven Stromberg (gyozaguy-x) wrote :

This bug still exists in Ubuntu 15.10 and Ubuntu GNOME 15.10.

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

Other bug subscribers

Remote bug watches

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