After upgrading to hardy, gnome-terminal windows are not properly restored on login

[Jason Tackaberry]

Binary package hint: gnome-session

(Package might be more appropriate as gnome-terminal, not sure.)

Using hardy updated as of today (2008-04-23), upgraded from gutsy.

I have several terminal windows of varying sizes and number of tabs, carefully placed on various workspaces. Although the number of windows and number of tabs in each window is restored, their sizes are wrong.

Steps to reproduce:
1. Start with a clean session
2. Open several gnome terminal windows, resize to varying sizes and place on different workspaces.
3. Run gnome-session-save
4. Logout
5. Log back in, and note that the terminal windows are not properly sized to their original size (when the session was saved). If you're using compiz instead of metacity, you may also notice that the terminal windows are all restored to the first workspace, rather than their original workspaces.

[Jason Tackaberry (tack)]

This is likely related: if I edit the current profile and change the level of transparency, it immediately adjusts all terminal windows to exactly 25 rows.

It also adjusts the number of columns on some, but not all of the windows, and not all of them get adjusted to the same number of columns.

Because of this, it does seem to be a gnome-terminal bug and not a gnome-session bug, so I am changing the package to gnome-terminal.

[Marnanel Thurman (marnanel)]

I think this is possibly a window manager bug, since it's the window manager's job to resize the windows on restart. I don't see why it would affect compiz and metacity equally, though.

[Jason Tackaberry (tack)]

Also happens with Compiz.

Here is how to reliably reproduce. I setup the following four gnome-terminal windows on 1600x1200 screen, each window with 4 tabs.

1. 848x558 at (4,49) (120x40 with LucidaTypewriter 9)
2. 848x558 at (4,638) (120x40 with LucidaTypewriter 9)
3. 729x363 at (867,49) (103x25 with LucidaTypewriter 9)
4. 729x363 at (867,446) (103x25 with LucidaTypewriter 9)

Run gnome-session-save. Logout, and relog in. Upon login, the restored windows have the following geometries:

1. 568x350 at (8,73) (80x24 with LucidaTypewriter 9)
2. 568x350 at (4,638) (80x24 with LucidaTypewriter 9)
3. 568x350 at (867,49) (80x24 with LucidaTypewriter 9)
4. 729x363 at (867,446) (103x25 with LucidaTypewriter 9)

4 is the only one that got restored properly.

See the attached screenshots, before.jpg and after.jpg.

[Marnanel Thurman (marnanel)]

Okay, that's pretty interesting. The next thing to figure out is whether the configuration was saved wrongly, or is being restored wrongly.

You should have a directory called ~/.config/metacity, or one called ~/.metacity. (Or perhaps you have both.) In one of these directories you'll find a file with the extension .sm which was saved at the moment you logged out. Please review this file to make sure there's no sensitive content (there won't be anything more sensitive than the titles of windows; I assume from your posts above you know how to do this, but let me know if you need a hand) and attach it here. Thanks!

[Marnanel Thurman (marnanel)]

Sorry, was typing faster than I thought. The file will have the extension .ms, not .sm, and it will be in a subdirectory "sessions" of one of those directories I told you about.

[Jason Tackaberry (tack)]

Attached is the file as requested. I will also attach ~/.gnome2/session for good measure. I removed ~/.metacity/sessions/* and ~/.gnome2/session and ran gnome-session-save. The resulting files are what was created.

I then logged out and logged back in. The windows weren't restored properly, although they were restored in a different configuration than the screenshot. (Could be non-deterministic, or it could be that compiz and metacity respond differently, as the earlier screenshots were taken when I was running compiz, and I have switched back to metacity to provide the session files you requested. This is the reason some of the positions are different than what I indicated in comment #3.)

It does look like the geometries are correct, but I'll leave that determination to you.

Also, it appears that I can trigger a resize of some or all of the terminal windows by changing the window manager theme using gnome-appearance-properties.

Are you unable to reproduce this so far? It can't possibly be just me, as I've installed Hardy on 3 separate machines (two upgrade from Gutsy, one fresh install) on very different hardware and they all behave the same way.

[Elio Bezerra da Silva (elio7769-deactivatedaccount-deactivatedaccount)]

Não me mandem mais nada. E não falo inglês e não sei por que vocês me mandam
esses avisos. Me irrita e vou classificar tudo como SPAM! PORRA!!!

[C de-Avillez (hggdh2)]

@Elio Bezerra da Silva: se nao desejais tais comunicados, por que estais subscrito a este bug? Em vez de -- sem razao -- reclamar, vá ao link no final do email, e seleccione "Unsubscribe".

Alias, pedimos o respeito aos outros por cá.

[Fionn (fbe)]

Hi, I would just like to CONFIRM this bug.

In addition I can add the experience that downgrading gnome-terminal to the latest gutsy version does indeed seem to FIX the issue. I guess this indicates it is not a WM problem.

ALSO I experienced that the terminals changed size and position when the video mode changed so that not the entire desktop is visible on screen (e.g. 800x600 vidmode on 1600x1200 screen) This also messes up panel icon placements but thats another (but possibly related) bug.

[Kees Kuip (keeskuip)]

I got this bug also. It is very annoying.

At first only the gnome-terminal with mutliple tabs was resized. But now the others are changing size and postion also.

Kees

[laubster (k-launchpad-laubster-org)]

I think I found what's wrong, but haven't found a good workaround yet. The smoking gun is in ~/.xsession-errors:

** (gnome-terminal:6994): WARNING **: Error parsing options: Unknown option --sm-config-prefix, passed from terminal child

"gnome-terminal --help" reveals gnome-terminal version 2.22.1 (delivered with hardy) no longer supports --sm-config-prefix or --sm-client-id (as does gutsy's 2.18.2).

I tried manually stripping those switches from the gnome-terminal entries in ~/.gnome2/session, and the mention in .xsession-errors does go away, but the restore gets confused.

[Daniel Harvey (daniel.harvey)]

Hi, I would also like to CONFIRM this bug.

However, I don't get the "Error parsing options" mention in the last post.

[Marnanel Thurman (marnanel)]

If laubster's diagnosis is correct, then this is a gnome-terminal bug and not a WM bug.

[Kees Kuip (keeskuip)]

Sometimes this problem doesn't occur.
It seems to depend on when the bottom and/or top panel are made visible.

If the panels are visible AFTER the terminals are visible than the terminals are moved to a different place.
If the panels are visible BEFORE the terminals the position of the terminals are NOT changed.

[Daniel Harvey (daniel.harvey)]

I have a different test case which I would like to have others try out.

1. Right click in one of the windows and select "Edit Current Profile".
2. Change something e.g. Add a character to "Select-by-word characters".

As the change is made (i.e. immediately the key is typed), all other terminals EXCEPT the one that was selected revert to 80x25 characters in size.

I've attached before and after screenshots in case my wording is unclear :-)

Anyone else get this behaviour? It seems to confirm that this is gnome-terminal bug and not a WM bug.

[Daniel Harvey (daniel.harvey)]

The after screenshot.

[Jason Tackaberry (tack)]

Actually, rather than reverting my terminals to 80x25, it swiftly crashes gnome-terminal. It doesn't do this every time, but if I play around with various terminal configurations (number of open windows, sizes, number of tabs), I can eventually make it segfault by editing the prefs as you suggest.

Here is a backtrace:

(gdb) bt
#0 terminal_window_update_geometry (window=0x0) at terminal-window.c:1954
#1 0x080708b4 in terminal_window_set_size_force_grid (window=0x0, screen=0x81040b8, even_if_mapped=1, force_grid_width=-1,
    force_grid_height=-1) at terminal-window.c:1596
#2 0x08070a7f in terminal_window_set_size (window=0x0, screen=0x81040b8, even_if_mapped=1) at terminal-window.c:1572
#3 0x0806949d in terminal_screen_update_on_realize (term=0x80d2090, screen=0x81040b8) at terminal-screen.c:901
#4 0x080699d2 in terminal_screen_change_font (screen=0x81040b8) at terminal-screen.c:908
#5 0x08069c88 in terminal_screen_reread_profile (screen=0x81040b8) at terminal-screen.c:629
#6 0xb781300a in g_cclosure_marshal_VOID__POINTER () from /usr/lib/libgobject-2.0.so.0
#7 0xb7806759 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#8 0xb781ad1d in ?? () from /usr/lib/libgobject-2.0.so.0
#9 0x08107b48 in ?? ()
#10 0x00000000 in ?? ()

(The other threads don't look interesting.)

[Patric (patric-thurm)]

I did some research regarding the window restore problem and came to the conclusion that it most likely is a bug in gnome-terminal. You can work around this by using the old version 2.18 of gnome-terminal from Ubuntu 7.10. Therefore I recommend to assign this bug to the gnome-terminal developers to verify.

Things to try:

-open an xterm or similar non gnome-terminal terminal application

-start 2 gnome-terminal as background process (gnome-terminal &)

-move both windows around the desktop to a different position

-in the xterm call gnome-session-save

-example output of gnome-session-save:
Saving session: gnome-terminal --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-6876--1795818576-1211528538 --active --geometry 80x24+84+634 --title pt@asterix: ~ --working-directory /data2/home/pt --zoom 1 --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-6876--1889095960-1211528539 --active --geometry 80x24+661+470 --title pt@asterix: ~ --working-directory /data2/home/pt --zoom 1

-close both gnome-terminal

-execute the command as specified by gnome-session-save ("gnome-terminal ... --zoom 1")

-both gnome-terminal will be restored, but only the last one in the list will be restored to the right position

-if gnome-terminal is called one by one each one gets restored correctly:
first execute "gnome-terminal --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-6876--1795818576-1211528538 --active --geometry 80x24+84+634 --title pt@asterix: ~ --working-directory /data2/home/pt --zoom 1" -> first window is restored; then close and execute "gnome-terminal --window-with-profile-internal-id=Default --show-menubar --role=gnome-terminal-6876--1889095960-1211528539 --active --geometry 80x24+661+470 --title pt@asterix: ~ --working-directory /data2/home/pt --zoom 1" -> second window is restored

It is also interesting that there is a difference in the content of .gnome2/session when calling gnome-session-save compared to when using the gnome session autosave feature! However content of .metacity/sessions/* is not different.

Also I see that window restore works when using compiz (most poeple do, as this is the default window manager in hardy?) but not in metacity. Compiz seems to rearrange the gnome-terminal windows (which do restore wrong by theirselfs in the first place) whilst metacity doesn't and will leave the windows in their wrong positions.

[Patric (patric-thurm)]

Replacing the current buggy gnome-terminal can be done as follows (take care, very evil procedure!):

-download right gnome-terminal 2.18 from http://packages.ubuntu.com/gutsy/gnome-terminal

-extract package to some temporary path (without actually installing it), e. g.:
dpkg-deb --extract gnome-terminal_2.18.2-0ubuntu1_i386.deb /tmp/gnome-terminal-2.18

-make sure no gnome-terminal processes are running

-as root (need xterm or similar or non GUI console (e.g. Ctrl+Alt+F1)):
cp /usr/bin/gnome-terminal /usr/bin/gnome-terminal.orig
cp /tmp/gnome-terminal-2.18/usr/bin/gnome-terminal /usr/bin/gnome-terminal
ln -s /usr/lib/liblaunchpad-integration.so.1 /usr/lib/liblaunchpad-integration.so.0

[Pedro Villavicencio (pedro)]

Is this still an issue with intrepid?

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

[Jason Tackaberry (tack)]

I'm fine with closing this bug report.

This bug no longer applies to Intrepid.

Intrepid's session management is broken beyond all repair anyway. It doesn't even bother starting gnome-terminal, let alone starting windows with the wrong geometry.

[Fionn (fbe)]

Just for the records:

I just installed a clean, new shiny jaunty and gnome-terminal STILL does not properly restore!? I really wonder how all you coding guys survived the last YEARS!? Do you really re-open and re-arrange all your terminals each time you login? Thank god I saved my ancient gnome-terminal 2.18 packages from gutsy(!) and with a little tweaking they installed even on jaunty.

Anyway, this means two years of broken session management - if you ever wondered why QT and KDE are about to win on the desktop, this sort of "maintenance" may be part of the answer.

[Ole Reinhardt (ole-reinhardt)]

My thoughts exactly!

At least with metacity session management seems to work from time to time. But after a cold restart of gnome the whole session is broken in any way. I don't understand what is that much of a problem that this issue _never_ worked correctly during my last 6 years of gnome experience! Realy awsome.

[Pedro Villavicencio (pedro)]

somebody having the issue should send it to bugzilla.gnome.org