Duplicated window title bars with Unity 3.2.8

Bug #691741 reported by László Torma on 2010-12-17
90
This bug affects 13 people
Affects Status Importance Assigned to Milestone
Unity
Fix Released
Undecided
Didier Roche
unity (Ubuntu)
Undecided
Unassigned

Bug Description

Chromium has two window title bars when maximized in Unity 3.2.8. See the attached screenshot. The bug is only present when Chromium starts maximized. When Chromium starts with normal window, maximizing works as expected (the window title bar is merged into the top panel). Also, when I open a new (maximized) window, the window title bar merges with the top panel even if Chromium was originally started maximized (and thus the first window has two title bars).

update: other applications are also affected

László Torma (tormalaszlo) wrote :
description: updated
Travis Watkins (amaranth) wrote :

This happens with every application for me.

Changed in unity:
status: New → Confirmed
description: updated
summary: - Duplicated window title bars with Unity 3.2.8 and Chromium
+ Duplicated window title bars with Unity 3.2.8
Jorge Castro (jorge) wrote :

Jason Smith tells me that this is "normal" for now to test the top panel rendering the widgets. (similar to how we did double menus during 10.10 testing)

Alex Launi (alexlauni) on 2010-12-20
Changed in unity (Ubuntu):
status: New → Confirmed
Dooitze de Jong (dooitze) wrote :

All apps have two windows when they are maximized (except nautilus)

description: updated
description: updated
description: updated
Diogo Almeida (digalmeda) wrote :

Added another screenshot of the bug, happening with nautilus.

Besides this, some windows have different titles (see attached screenshot).

Robert Roth (evfool) wrote :

Found exact way to reproduce:
1) Open any application
2) Maximize it - its titlebar goes into the top panel, thats ok so far
3) Click the Close button in the top panel to close the window - I guess window state is saved
4) Reopen the window - as the window state is rememebered as maximized, the window is restored as such, but its own titlebar is not hidden, thus it does have a titlebar in the top panel and one in the window.

Sam Spilsbury (smspillaz) wrote :

If the window is maximized by default, then we are not getting a ::stateChangeNotify so unity won't know that the window as actually maximized. We should check on window creation if a window is already maximized

Robert Roth (evfool) on 2011-01-05
Changed in unity:
assignee: nobody → Robert Roth (evfool)
assignee: Robert Roth (evfool) → nobody
Changed in unity (Ubuntu):
assignee: nobody → Robert Roth (evfool)
status: Confirmed → In Progress
Robert Roth (evfool) on 2011-01-07
Changed in unity (Ubuntu):
assignee: Robert Roth (evfool) → nobody
status: In Progress → Confirmed
Matt Goodall (matt-goodall) wrote :

Once I've got the duplicate title bar by starting an application maximised (see comment #7) it doesn't matter how many times I restore the window to normal size and maximise again - there's always a duplicate.

However the following steps (continuing from those in comment #7) almost always gets rid of the duplicate title bar for me:

5) Restore the window to normal size (unmaximise).
6) Minimise the window.
7) Restore the window (unminimise).
8) Maximise the window.

I'm not sure if that's of any help but I thought it was odd that the maximise event is only handled correctly after a minimise. Also, note that the window must be restored to normal size first; minimising from a maximised state doesn't seem to make any difference.

Didier Roche (didrocks) on 2011-01-13
Changed in unity (Ubuntu):
status: Confirmed → Fix Committed
Changed in unity:
status: Confirmed → Fix Committed
milestone: none → 3.2.10
assignee: nobody → Didier Roche (didrocks)
Didier Roche (didrocks) on 2011-01-14
Changed in unity:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity - 3.2.12-0ubuntu1

---------------
unity (3.2.12-0ubuntu1) natty; urgency=low

  * New upstream release.
   - Window border doesn't get restored (LP: #691812)
   - When a menu is triggered from Alt+key, app name stays visible on panel
     (LP: #691765)
   - show the launcher on <Super> KeyPress, this will be needed when the
     shortcut will be implemented if we are in intellihide mode
   - Make sure an underscore is correctly placed under the corresponding
     accelerator-key. (LP: #683427)
   - Adding a dummy --replace option for compatibility reason (LP: #692569)
   - Compiz crashed with SIGSEGV in CompWindow::id() (LP: #694945)
   - Tooltip text not vertically centered (LP: #697791)
   - Maximizing a window horizontally or vertically removes the title bar
     (LP: #696780)
   - Mousewheel support for indicators (LP: #681428)
   - Avoid Quicklists being positioned so that they are partially offscreen at
     the bottom screen-edge. (LP: #691114)
   - Migrate awn, docky and cairo-dock dock launchers (LP: #692967)
   - Include manpages, and make them translatable. (LP: #684896)
   - Automaximize windows in Unity with some rules like blacklisting some
     applications, initial window size.
     It fixes also some bugs, like maximized window on first map not
     undecorated (LP: #667009, #669716, #693779, #691741)
   - Update libunity to conform to latest GIO VAPI breakage (LP: #679964)
   - Initial unity-atk module implementation (LP: #701680)
   - Panel autohide when on Quicklist (LP: #683261)
  * debian/control:
    - unity breaks on older bamf version (dbus protocol changed)
    - needs latest and greatest from dee
    - add libatk1.0-dev build-dep
  * CMakeList:
    - distro-patch to avoid building tests right now as building them is failing
      with the current vala/gir stack. THIS NEED TO BE REMOVED.
  * debian/rules:
    - don't --fail-missing as we don't want to install the vapi yet. The gir
      package will come next week.
  * debian/unity-common.install:
    - install the manpages
  * debian/libunity3.symbols:
    - updated
 -- Didier Roche <email address hidden> Fri, 14 Jan 2011 20:47:25 +0100

Changed in unity (Ubuntu):
status: Fix Committed → Fix Released
Timothy Kross (timkross) wrote :

Steps to reproduce:
1) Make sure "Use System Title Bar and Borders" is unticked (It is in the right click menu of the tab bar)
2) Maximize Chromium
3) Tick "Use System Title Bar and Borders"
4) Untick "Use System Title Bar and Borders"
5) Restore Chromium

Result:
At step 2 we see two sets of window controls, one drawn by Chromium and one in the top panel.
After step 3 we see two sets of window controls, one in the top panel, one in Chromium's titlebar.
When step 5 is executed we will find again that we have two sets of window controls, but this time one is drawn by Chromium and one by Unity.

Expected result:
At step 2: One set of window controls, the one drawn by Chromium.
At step 3: One set of window controls; in the top panel (Unity).
At step 5: One set of window controls, the one drawn by Chromium.

Toby Smithe (tsmithe) wrote :

This still occurs when un-maximising a fullscreen, say, Chromium window.

Diogo Almeida (digalmeda) wrote :

That image doesn't correspond to the problem related here. If you maximize that window, do you get the same as in the other screenshots?

Toby Smithe (tsmithe) wrote :

You're right. It doesn't. I misinterpreted the bug report. In any case, the answer to your question is "no". But I feel that there's a bug here, anyhow. Shall I open another report?

Robert Roth (evfool) wrote :

@Toby Smithe: Check bug #711567, I guess that is a more general one stating the issue you are explaining, and if it is, you can mark that as affecting you and watch that for further updates.

Toby Smithe (tsmithe) wrote :

Yes; that does affect me. But that affected me independently of this one that has more recently appeared. Previously, even though that one would still be the case, I could un-maximise Chromium and not have any superfluous window dressing: it seems bug 711567 is more to do with the interaction of the "Use system titlebar..." option in Chromium, whereas this one seem independent of having to fiddle with that option. Regardless, the effect that obtains on step 5 in bug 711567 is identical to the effect here; just, as I said, there's no changing of Chromium options needed in this case. I would say that step 5 in that bug seems like a more specific version of this more general case.

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

Other bug subscribers