Hmm. gtk+ bug or gnome-shell bug ?

We get a ConfigureRequest, so I'm guessing it's a GTK+ or vte bug.

(Sorry, it could also be a _NET_MOVERESIZE_WINDOW, not just a ConfigureRequest. No idea which is it actually is)

I see this bug as well.

gnome-terminal-3.6.0-95.2.x86_64
mutter-3.6.0-112.2.x86_64
gnome-shell-3.6.0-141.2.x86_64

*** Bug 686950 has been marked as a duplicate of this bug. ***

Punting back over to gnome-terminal.

Works here (g-t 3.4 with metacity); no related changes in g-t since 3.4 => not a g-t bug either.

Trying gtk+.

The bug report is lacking info, e.g. which distribution is being used. Is this only ubuntu, or has anyone seen this on fedora?

I've reproduced the behavior with mutter and gnome-terminal 3.6. As I said, we get a ConfigureNotify from the client, so they're asking us to resize.

er, ConfigureRequest

I guess this is because in 3.6 unfocusing causes a re-style to apply the 'onfocused' effect?

(In reply to comment #7)
> The bug report is lacking info, e.g. which distribution is being used. Is this
> only ubuntu, or has anyone seen this on fedora?

It's Arch Linux. (Sorry for not mentioning that.)

I am seeing it on openSUSE 12.2 


gnome-terminal-3.6.0-95.2.x86_64
mutter-3.6.0-112.2.x86_64
gnome-shell-3.6.0-141.2.x86_64

(In reply to comment #10)
> I guess this is because in 3.6 unfocusing causes a re-style to apply the
> 'onfocused' effect?

Wait a minute... I wonder if this is the re-realizing code designed to flip back and forth between metacity and mutter that's screwing us over. Are you connecting to the style-changed signal?

The unrealize + re-realize only happens on composite-changed, not on focus-out. 

There are a few style-set handlers in 3-6 / style-updated handlers on master, but that has been there forever and never caused this problem. And why would that only cause problems on gnome-shell, not on metacity (I can't repro the problem here using g-t master with matacity from f17) ?

*** Bug 688373 has been marked as a duplicate of this bug. ***

This also appears to occur with gnome-terminal under compiz/unity:

https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1040885

(In reply to comment #14)
> There are a few style-set handlers in 3-6 / style-updated handlers on master,
> but that has been there forever and never caused this problem. And why would
> that only cause problems on gnome-shell, not on metacity (I can't repro the
> problem here using g-t master with matacity from f17) ?

Maybe because metacity doesn't support BACKDROP state?

*** Bug 688959 has been marked as a duplicate of this bug. ***

Dupe 388959 includes a purported workaround patch.

(In reply to comment #19)
> Dupe 388959 includes a purported workaround patch.

http://bugzilla.gnome.org/show_bug.cgi?id=388959 ?

Punting back to gnome-terminal; it's clear this is not a GTK+ bug.

Sorry, https://bugzilla.gnome.org/show_bug.cgi?id=688959

(In reply to comment #21)
> Punting back to gnome-terminal; it's clear this is not a GTK+ bug.

Is it? It's not happening with gtk 3.4, so clearly something in gtk+ has changed.

(In reply to comment #23)
> Is it? It's not happening with gtk 3.4, so clearly something in gtk+ has
> changed.

It's not happening in gtk 3.4 with gnome-shell/mutter?

(In reply to comment #24)
> (In reply to comment #23)
> > Is it? It's not happening with gtk 3.4, so clearly something in gtk+ has
> > changed.
> 
> It's not happening in gtk 3.4 with gnome-shell/mutter?

It's not happening on gtk+-3.4 with gnome-terminal-3.4.  gnome-terminal from git requires gtk+ >= 3.6.0.

This should be a 3.8 blocker, I think. Makes working with terminals pretty impossible.

So I think what is happening here is that some widget somewhere in our UI is requesting a different size when the window is unfocused than when it's focused. Someone who can repro the bug could try to find which widget that is.

If you ask me it's the first tab requesting a smaller size than the current tab ;-)

How would you find out?

(In reply to comment #27)
> So I think what is happening here is that some widget somewhere in our UI is
> requesting a different size when the window is unfocused than when it's
> focused. Someone who can repro the bug could try to find which widget that is.

It's easy to reproduce with Fedora 18; launch gnome-terminal, maximize it, create a new tab, restore the window, focus on a different window.

GTK_DEBUG=size-request gnome-terminal --disable-factory (on g-t version 3.6) resp. GTK_DEBUG=size-request ./gnome-terminal-server (for g-t master, then use the client to open a terminal)?

Created attachment 233066 [details]
resize log

resize log showing the problem -- I create a tab and resize the window, then I wait almost a minute (from 14:22:23 to 14:23:16) and then unfocus

Hmm. I had hoped that the difference would be trivial in a diff, but (after removing the timestamps) the diff is highly nontrivial :/

I have committed a patch to master that should fix this; please test. Thanks to Jasper on IRC for his analysis of the problem!

(In reply to comment #33)
> I have committed a patch to master that should fix this; please test. Thanks to
> Jasper on IRC for his analysis of the problem!

Looks like that fixed it.  I can no longer reproduce the issue using the steps I mentioned in comment #29.

Works for me too, thanks!

*** Bug 695064 has been marked as a duplicate of this bug. ***

I see a gnome-terminal resizing issue that is similar and might be related to this bug:

Open gnome-terminal
- add another tab (CTRL-Shift-T)
- start Midnight-commander in tab (mc)
- use cursor keys to navigate to a directory
- press enter to enter directory
- press enter to exit directory again

Observed behavior: The gnome-terminal window size shrinks by one.
Expected behavior: The gnome-terminal window size stays the same.

The bug does not appear if there is only a single tab in the window.

I am happy to file a new bug; it seems all the duplicate of this one have the terminal snap to an "original" size, which is different here. However, the problem seems to be fairly recent.

gnome-terminal: 3.6.2-0ubuntu1
mc: 3:4.8.11-1
gnome-shell-common: 3.10.4-0ubuntu5.1

At which step does it shrink? It really sounds weird if it shrinks while using mc.

3.6.2 is an ancient version. Please upgrade from gnome3 staging (https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+packages) and complain at Ubuntu so that they upgrade g-t to a recent version.

Oh, it shrinks when you switch to the parent directory. Switching in and out of a directory again will have it shrink by another line. The window will get shorter and shorter. I can make a movie.

This sounds truly unbelievable :)

Are you using gnome-shell, or Ubuntu's default unity desktop?

Please upgrade vte and g-t from gnome3 staging, and upload a video if the problem persists.

Thank you! 

I am using the default unity desktop.

I updated gnome-terminal and some libvte's to the versions below from the staging area:

libvte-2.90-9                                               1:0.36.3-1ubuntu1~trusty1
libvte-2.90-common                                          1:0.36.3-1ubuntu1~trusty1
libvte-common                                               1:0.28.2-5ubuntu1        
libvte9                                                     1:0.28.2-5ubuntu1        
python-vte                                                  1:0.28.2-5ubuntu1       

I am not sure if this includes the "vte" you mentioned. I killed-all "gnome-terminal-server" and started gnome-terminal again. The problem is still there. Will upload a movie soon.

ah, gnome-terminal version is: 3.12.1-0ubuntu1~trusty1

It's probably a different bug then.  Could you please open a new bugreport?  Please CC me.  I also use Ubuntu Trusty, so I'll try to reproduce the problem.  But I'm leaving for a vacation right now, so please be patient.

Will do. Thank you! I can always just not use tabs :)

One thing that I suspect: mc sets the window/tab title to reflect the current directory.  Maybe this string has special characters with bigger ascent/descent that causes the tab label to grow vertically (maybe just by 1 pixel).

You could try to disable updating the window title (mc -> F9 -> Options -> Layout -> Xterm window title – I assume gnome-terminal would no longer shrink for you), or manually set the window title to what mc would set it (echo -ne '\e]0;This is the new title\a' – I assume you could trigger the window size change by this command, substituting the actual title with what mc sets it to).

For the new bug, please also attach a script(1) transcript of reproducing the problem.

Geez, I can also reproduce it (should've tried before writing my previos comment).

for i in {1..10}; do echo -ne '\e]0;䈀\a'; sleep 0.1; echo -ne '\e]0;x\a'; sleep 0.1; done

Disabling updating the window-title "fixes" the issue. The tab title mc is setting looks garbled. Maybe it is some locale setting that is messed up. Do you think it is still worth writing a bug report?

The window size change is definitely a bug in gnome-terminal which deserves its own bug entry.  Apparently we need to re-compute the style/size/grid/wmhint/idontknowwhat on tab title change.

The garbled looking title also sounds like an issue (might be gnome-terminal or mc bug, depending on how it looks like, a screenshot could help us tell).

Does the garbled window title look something like this?
└␌ [␊±└⎺┼├@°⎺⎺]:/├└⎻/┴├␊

In this case it's bug 732586.

It does, so thank you for the pointer!

I've filed bug 732588 for your main issue, let's continue there :)