gnome-terminal maximize than un-maximize behaves odd

Bug #1521302 reported by Scott Moser on 2015-11-30
This bug affects 80 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Marco Trevisan (Treviño)
Marco Trevisan (Treviño)

Bug Description

If I open a new terminal ('ctrl-alt-t' or from the run menu), and then maximize and then un-maximize i get odd behavior. maximize does fine, but then clicking the 'un-maximize' button does either:
 a.) moves the terminal fullscreen on my second monitor.
 b.) makes it slightly less than full screen on the current monitor.

I'd expect that it return it to the size it was before maximize.

Note, this does not happen with an 'xterm', only with gnome-terminal, so I"m not sure where the problem lies entirely.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: unity 7.4.0+16.04.20151102-0ubuntu2
ProcVersionSignature: Ubuntu 4.2.0-19.23-generic 4.2.6
Uname: Linux 4.2.0-19-generic x86_64

ApportVersion: 2.19.2-0ubuntu8
Architecture: amd64
 fsck from util-linux 2.27.1
 /dev/sda2: clean, 321516/2444624 files, 2558960/9765632 blocks
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
CurrentDesktop: Unity
Date: Mon Nov 30 14:14:29 2015
DistUpgraded: Fresh install
DistroCodename: xenial
DistroVariant: ubuntu
EcryptfsInUse: Yes
 Intel Corporation Broadwell-U Integrated Graphics [8086:1626] (rev 09) (prog-if 00 [VGA controller])
   Subsystem: Intel Corporation Device [8086:2057]
InstallationDate: Installed on 2015-07-23 (130 days ago)
InstallationMedia: Ubuntu 15.10 "Wily Werewolf" - Alpha amd64 (20150722.1)
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.2.0-19-generic.efi.signed root=UUID=f897b32a-eacf-4191-9717-844918947069 ro quiet splash vt.handoff=7
SourcePackage: unity
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install)
version.compiz: compiz 1:
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.65-3
version.libgl1-mesa-dri: libgl1-mesa-dri 11.0.5-1ubuntu2
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 11.0.5-1ubuntu2
version.xserver-xorg-core: xserver-xorg-core 2:1.17.3-2ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.9.2-1ubuntu1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.5.0+git20150819-0ubuntu1
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.917+git20151019-1~exp1ubuntu1
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.11-1ubuntu3
xserver.bootTime: Mon Nov 30 11:53:26 2015
xserver.configfile: default
xserver.errors: systemd-logind: failed to get session: PID 913 does not belong to any known session
xserver.logfile: /var/log/Xorg.0.log
 product id 1046
 vendor ACR
xserver.version: 2:1.17.3-2ubuntu2

Related branches

Scott Moser (smoser) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity (Ubuntu):
importance: Undecided → Medium
Adam Conrad (adconrad) wrote :
Adam Conrad (adconrad) wrote :
Adam Conrad (adconrad) wrote :
Iain Lane (laney) on 2016-02-01
Changed in unity (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
Will Cooke (willcooke) on 2016-02-16
tags: added: rls-x-incoming u7-trello-import
tags: removed: u7-trello-import
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:

tags: added: iso-testing
Scott Moser (smoser) wrote :

Please fix!

Scott Moser (smoser) wrote :

(i know that isnt' helpful, but this bug is so annoying to me, and it seems likely to be annoying to even normal users who hit maximize of a terminal and then try to un-maximize it).

LGB [Gábor Lénárt] (lgb) wrote :

Indeed, I use tons of terminals in my work, and I often need maximize/unmaximize operations, now it makes my life quite hard :(
This was my original bug-report, which is now considered as duplication of this bug: #1573563

Jaromir Obr (jaromir-obr) wrote :

An annoying bug happening to me since I upgraded Ubuntu from 15.10 to 16.04. So it seems to be a regression in 16.04.
Other applications I tried are not affected.

I'm running GNOME Terminal 3.18.3, unity 7.4.0+16.04.20160415-0ubuntu1

Ubuntu/unity is going down the drain. Bugs such as these impair productivity for MONTHS and nobody seems to care. What good are shiny new features developed every six months if you cannot stabilize your platform and make it actually USABLE to power users?

This, along with broken Alt-Tab behavior reported in #1568242 are a serious deal breaker, if we have to fight the interface to actually get ANY work done...

Goodbye Ubuntu, it was nice knowing you. You're a collection of shiny bells and whistles with zero value to power users.

(@V.K.: I absolutely share your frustration. For me #1532226 (a really critical issue, reported early January, they began working on it late March, no result whatsoever so far) will make me switch to another distro as soon as I find the time.)

Martin Lund (martin-lund) wrote :

I'm seeing the exact same issue after upgrading to Ubuntu 16.04 LTS.

I share the frustration - I'm using this feature all the time.

Benedict (benedictbroy-gmx) wrote :

Would be a fantastic productivity boost if this got fixed!

Martin Lund (martin-lund) wrote :

Doing some gdb debugging setting a breakpoint in gnome-terminals terminal-window.c:terminal_window_update_size() reveals that the terminal window does indeed minimize to its original windows size but then somehow up sizes to full window.

Sometimes I have also seen that the issue goes away when gdb debugging which might indicate a sequence/timing issue but I wouldn't trust that finding entirely.

Khurshid Alam (khurshid-alam) wrote :

I can not reproduce this with mutter(Gnome-Shell) or metacity (Gnome-Flashback) session. However it is happening Flashback(compiz) session. So I am thinking it has something to do with compiz.

Martin Lund (martin-lund) wrote :

I can confirm, the issue does not exists using metacity.

Matt Kliewer (mattkliewer) wrote :

This bug is up there in terms of annoying factor, I sure hope this is being actively looked into.

Changed in unity (Ubuntu):
status: Confirmed → In Progress
Changed in unity (Ubuntu Xenial):
status: Confirmed → In Progress

> This bug is up there in terms of annoying factor, I sure hope this is being
> actively looked into.

This is the case... There's actually a race of events. Not really sure if it's all unity fault or even gtk not properly handling two events at time, as we send it two configure requests, but I guess we're going to change the way unity/compiz (as the last one is affected also without unity) to behave in a way it couldn't confuse toolkits.

Khurshid Alam (khurshid-alam) wrote :

𝐒𝐢𝐦𝐢𝐥𝐚𝐫 𝐢𝐬𝐬𝐮𝐞 𝐰𝐢𝐭𝐡 𝐞𝐦𝐚𝐜𝐬 𝐚𝐬 𝐰𝐞𝐥𝐥. lp:1578240

Paul White (paulw2u) on 2016-05-05
tags: added: yakkety
Martin Lund (martin-lund) wrote :

Any updates on this issue?

Malcolm (malcolm06021990) wrote :

Hello to all!
Users are waiting for any updates :)

denos (shane-systemnexus) wrote :

While the Ubuntu team works on this (thanks!), there is a workaround: use another terminal.

For example, terminator has 100% feature overlap for what I need and works with F11 / maximize
sudo apt-get install terminator

But you want your terminal to launch from ctrl-alt-t? That's controlled by the link at:

But you need to launch it with command line arguments (eg. --geometry)? Point the link at a shell script that launches your terminal with the arguments you need.

Details on setting the default terminal:

I don't want to clutter this bug report up with unrelated discussion, so please don't respond to this comment. It's just intended to help those of you (like me) who rely on the functionality that the Ubuntu team is working to fix.

Please do NOT promote the usage of Terminator (as it is found in Xenial).

Terminator uses a much older version of the same terminal emulation widget (VTE) than gnome-terminal, which contains way more bugs and lacks plenty of useful features present in newer versions. You might get a superior experience when unmaximizing, but will get an inferior one at many-many other aspects.

If anything along these lines, I can recommend trying Terminator's gtk3 bzr branch, or Terminix (neither one shipped by Xenial).

Jonathan Kamens (jik) wrote :

gnome-terminal is not the only application affected by this bug. It happens for me with GNU Emacs regularly.

The bug is most likely related to the window setting geometry hints (resize increments).

There's a proposed fix in this ppa: lp:~3v1n0/+archive/ubuntu/xenial-maximization-fix
The compiz package is building right now, it should be there in few minutes.

If this doesn't fix things for you, let me know.

Ouch wrong link. Good one is:

Just do:
  sudo add-apt-repository -u ppa:3v1n0/xenial-maximization-fix && sudo apt install compiz

rcspam (rcspam) wrote :


Ok it's fix for me...

Matt Kliewer (mattkliewer) wrote :

This fix works for me as well. Thanks!

tags: added: desktop-trello-import
Robert Schlabbach (robert-s-t) wrote :

For the curious and technically savvy, I suppose this is the actual fix:

diff -Nru compiz- compiz-
--- compiz- 2016-04-15 05:30:40.000000000 +0000
+++ compiz- 2016-05-12 18:01:52.000000000 +0000
@@ -543,11 +543,11 @@

     recalcType ();
     recalcActions ();
+ stateChangeNotify (oldState);

     if (priv->managed)
  screen->setWindowState (priv->state, priv->id);

- stateChangeNotify (oldState);
     screen->matchPropertyChanged (this);

Malcolm (malcolm06021990) wrote :

This fix works for me. Thanks!

Robert, yes... That's the fix (as always the one-line changers are the ones involved in tricky cases like this one).

I've written a little on the merge proposal, but that stateChangeNotify call causes unity to readd the decorations to the window (since when there are none when maximized), and thus to request the window to be resized to occupy the space = workspace - windows extents size.

What basically happens in a buggy state is:
 1. Compiz tells the window to unmaximize
 2. Unity tells the window to resize to cover the maximized are + decorations
 3. Window restores, going back to the old geometries, and notifies compiz
 3. Compiz receives the notification from the window with the new geometries
 4. Compiz confirms the new restored geometries sending them back to the window.

However, while point 2. is the one causing problems the fact is that some windows (g-t, emacs: probably the ones with embedded widgets which take more to resize) seem to ignore the new correct geometries that we send back to the window, we basically send two events almost together and the 2nd one seems to be discarded by these.

Now, inverting points 2. and 1. we avoid sending to the window to use a maximized space after that we said that we want it restored.

All this is quite racey, and I still have some doubt about some gtk3 involvement, since while it's true we're sending them confusing stuff, they shouldn't ignore our last request.

Tomas Kral (kralutomas) wrote :

I have this problem with Google Chrome too and with more programs. This problem seems to be with compiz because in Gnome Shell maximize - un-maximize works fine. Please fix this anoying issue because I can't image, that I'll have to live with this problem next 4 years.

Cedric Schieli (cschieli) wrote :

The fix works for me.

Martin Lund (martin-lund) wrote :

Fix also working fine for me.

Will we see this fix pushed into Xenial at some point?

Sure, it's landing now in yakkety, then it will go through the SRU process.

Paul White (paulw2u) wrote :

Confirmed fixed in yakkety (Unity 7.5.0+16.10.20160517-0ubuntu1).

Thanks Marco!

Neil Wilson (neil-aldur) wrote :

Has the SRU process been kicked of for Xenial?


Yes, the fix is in proposed pocket right now (, if you enable -proposed repository and you get this fixed, please tag the bug as "verification-done".

Proper announcement should be posted in affected bugs soon (hopefully).

Changed in unity (Ubuntu):
status: In Progress → Fix Released
affects: unity (Ubuntu) → compiz (Ubuntu)
no longer affects: unity
Paul White (paulw2u) on 2016-05-26
tags: added: verification-done
Neil Wilson (neil-aldur) wrote :

SRU Verification performed. The proposed package corrects the problem.

Thanks, if you want to help speeding up the resolution of this bug for other people too, please help perform bug verifications for the other issues listed here

Hello Scott, or anyone else affected,

Accepted compiz into xenial-proposed. The package will build now and be available at in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at . Thank you in advance!

Changed in compiz (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: removed: verification-done
tags: added: verification-needed
tags: added: verification-done
removed: verification-needed
Brian Millan (brian.millan) wrote :

Compiz Installed version: 1:

Accepted this from proposed:
Compiz Available version: 1:

This fixed the issue for me. Thanks!

tags: removed: amd64 apport-bug compiz-0.9 iso-testing rls-x-incoming ubuntu xenial yakkety
tags: added: amd64 apport-bug compiz-0.9 iso-testing rls-x-incoming ubuntu xenial yakkety
removed: verification-done
tags: added: verification-done
removed: amd64 apport-bug compiz-0.9 iso-testing rls-x-incoming ubuntu xenial yakkety
tags: added: apport-bug compiz-0.9 iso-testing ubuntu xenial yakkety
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:

compiz (1: xenial; urgency=medium

  [ Andrea Azzarone ]
  * Add an option to notify that a key press is actually an "auto
    repeat" one. (LP: #1572241)

  [ Alberts Muktupāvels ]
  * OpenGL: use the number of Opaque windows around to decide whether
    paint the bg or not (LP: #1574866)

  [ Marco Trevisan (Treviño) ]
  * Scale: use the selectedWindow as starting point when focusing a
    window (LP: #1575168)
  * Scale: allow to iterate through windows using Tab key
  * Window: call stateChangeNotify when compiz state changed but before
    changing the WM state (LP: #1521302)

  [ Eleni Maria Stea ]
  * Expo, Scale: add support for bottom offsets (LP: #1562346, LP:

  [ handsome_feng ]
  * Add a YBottomOffset value when stretch maximized windows。 (LP:

  [ CI Train Bot ]
  * No-change rebuild.

 -- Marco Trevisan (Treviño) <> Thu, 26 May 2016 00:12:16 +0000

Changed in compiz (Ubuntu Xenial):
status: Fix Committed → Fix Released

The verification of the Stable Release Update for compiz has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Fred Cooke (fred-cooke) wrote :

This bug report was quite helpful for me. I have this exact symptom, but in LXDE using openbox (3.6.1-1ubuntu2) in Lubuntu. Primarily with gnome-terminal, also. In particular, the hint about the window resizing correctly, then jumping back up, and the patch itself reordering the events sent to the window helped as I could verify the double movement as I can see a flicker the first time, and no flicker subsequent times (because both states are large/black). I'll try to follow up with openbox for a fix, however it seems to me that the VTE/gnome-terminal code is also a bit iffy to be affected in this way when little else seems to be.

To post a comment you must log in.