Can't access maximized window by clicking titlebar

[Jono Bacon]

Binary package hint: unity

This is the context in which I am seeing this bug:

 * I have an app open and maximized (as such it's windows controls have been subsumed into the panel) (e.g. Firefox).
 * I open another app that is open but not maximized (e.g. the Terminal).
 * If I have the Terminal open and behind it I see the maximized Firefox, if I want to access Firefox I naturally go and click on the window border (which is now the panel) expecting it to highlight Firefox and bring it to the foreground, but nothing happens.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity 3.4.2-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.38-3.30-generic 2.6.38-rc4
Uname: Linux 2.6.38-3-generic i686
Architecture: i386
DRM.card0.DP.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.DP.3:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.HDMI.A.2:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
DRM.card0.LVDS.1:
 status: connected
 enabled: enabled
 dpms: On
 modes: 1440x900 1440x900
 edid-base64: AP///////wAwrjZAAAAAAAARAQOAHhN46s11kVVPiyYhUFQAAAABAQEBAQEBAQEBAQEBAQEBrCeghFGEGjAwIDYAL74QAAAZ1SGg+FCEfjAwIDYAL74QAAAZAAAADwCVCjKVCigZCQBMo1dUAAAA/gBMVE4xNDFCVDA0MDAyAL4=
DRM.card0.VGA.1:
 status: disconnected
 enabled: disabled
 dpms: Off
 modes:
 edid-base64:
Date: Wed Feb 16 14:01:53 2011
DistUpgraded: Fresh install
DistroCodename: natty
DistroVariant: ubuntu
GraphicsCard:
 Subsystem: Lenovo Device [17aa:20e4]
   Subsystem: Lenovo Device [17aa:20e4]
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110202)
InstallationMedia_: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110202)
MachineType: LENOVO 7417CTO
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 LC_MESSAGES=en_US.utf8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.38-3-generic root=UUID=70dfeb40-de6f-4ce0-9058-9ba257c3facd ro quiet splash vt.handoff=7
ProcVersionSignature_: Ubuntu 2.6.38-3.30-generic 2.6.38-rc4
SourcePackage: unity
dmi.bios.date: 11/26/2009
dmi.bios.vendor: LENOVO
dmi.bios.version: 7UET81WW (3.11 )
dmi.board.name: 7417CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr7UET81WW(3.11):bd11/26/2009:svnLENOVO:pn7417CTO:pvrThinkPadT400:rvnLENOVO:rn7417CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 7417CTO
dmi.product.version: ThinkPad T400
dmi.sys.vendor: LENOVO
version.compiz: compiz 1:0.9.2.1+glibmainloop4-0ubuntu11
version.libdrm2: libdrm2 2.4.23-1ubuntu3
version.libgl1-mesa-glx: libgl1-mesa-glx 7.10-1ubuntu3
version.xserver-xorg: xserver-xorg 1:7.6~3ubuntu4
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:6.13.2+git20110124.fadee040-0ubuntu4
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.14.0-1ubuntu9
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:0.0.16+git20110107+b795ca6e-0ubuntu4

[Mark Shuttleworth (sabdfl)]

I see how it's natural to want to do this. The one gotcha for me is that
the panel is also hosting the menu of the app which is in the
foreground. So it's arguably as much part of that app, as the top
maximised one.

I *think* we can implement what you want and have that "just work". It
may be just fine that way, or it may need to be re-thought after some
testing.

So let's call this a design +1 with room to reconsider in Natty+1.

Mark

[Jono Bacon (jonobacon)]

Thanks for the response, Mark. I know that right now the menus are currently not displayed unless you hover over them - do you think this could be one reason to always display the menus for foreground apps?

I know the design team have much more expertise in this area, and I would never wish to take my limited interaction design experience and use it as a guide, but I noticed when we did some developer tools usability testing last week and on some other occasions when I have had someone use Unity, I have noticed that some folks don't realize there is a menu there as it is not visible.

Then again, if the menu *is* always visible, I wonder if I would still feel like the panel is a natural place to select the background maximized window - I might feel quite different if I see another apps menu in there. I guess some usability testing would be a good step forward in assessing this.

[Paul Sladen (sladen)]

If it's any value, I have attempted to click on the global "title bar" in order to raise a full-screen application that is underneath. The foreground application is effectively "borrowing" the global menu area which now belongs to the maximised application.

There's possibly some work that could be done; for instance if I have a foreground (non-maximised) terminal the global menu simply sits there saying "Terminal" (process name); which seems a little pointless and it might as well just display the menus. Whereas for a maximised application, the more useful document name is displayed; along with the WM buttons to indicate that it is the full-screen application.

[Mark Shuttleworth (sabdfl)]

The reason I think this is likely to work is that one would not
instinctively click on a menu in order to raise the window. When w e get
a true proximity transition to show the menu (i.e. when the menu starts
showing before you actually get to the panel) this will be even more
pointed. So I'm +1 on implementing the work implied by the bug -
clicking on the panel *outside* the menu raises the maximised window. We
should probably have some buffer around the menu, and the indicators.

Mark

[Loris Zinsou (nepenthes)]

Could the menu start showing progressively, with 20% opacity 15 pixels away from the menu+buffer, with a transition to 100% opacity when on the menu+buffer ? I think it would be consistent with the unity launcher behavior.

If one could drag the panel to unmaximize the window, that would be great too.

[Mark Shuttleworth (sabdfl)]

Loris, a proximity effect is our desired goal, we can't do that in X at
the moment, hence the fallback to the mouseover.

[PEIGNOT Kévin (kpeignot)]

Wouldn't it make more logical to have the menu in the window for unmaximized windows? I mean, like that :
     -the menu are always just above the window;
     -we don't lose vertical space, because it's not a maximized window;
     -it remain intuitive : the menu is always just above the window.
In this case, if you have a maximized window, but it's an unmaximized one that have the focus, don't show any menu in the panel while the maximized windows don't get the focus. Like that, you can give the focus to the maximized window by clicking the panel, and the maximized application name.

[Matthew Paul Thomas (mpt)]

This bug report is about title bars for maximized windows, not menus for unmaximized windows.

[entonjackson (aj-mysc)]

I think another big problem is, trying to minimize a maximized window while another unmaximzed window has the focus.
This case occurs very often and makes the workflow much slower in Ubuntu than in Windows or OS X.
E.g.: I have an open and maximized Chromium window in the background, while working in nautilus (has focus). Now i want to minimize chromium. No chance. Titlebar now belongs to nautilus. So one needs first to click somewhere into the area of the maximized window or on the icon of the maximized program in the launcher to access it. But in case of a webbrowser like chromium you then have to be cautious about not clicking a link or whatever that could change the content, what is not wanted.
Maybe as a first (and dirty) solution, the window control buttons should be integrated into the title whenever a maximized window is open on this workspace? This could at least give the chance to access the 3 most importent window actions (close, minimize, maximize). And while hovering over these, the title and menus fade to the ones of the maximized window.
Maybe this could be a first, dirty solution.

Fact is, it (this bug) makes working with Ubuntu much slower, because you always have to check how to access maximized windows, before doing something with them.

[Madcap (madcap)]

This bug is not a duplicate of bug #723882 and, in fact, I'm still experiencing it in Ubuntu 12.04.2 despite #723882 being fixed a while ago.

The issue here is that a maximized window does not get raised when you click on the title bar (which is the universal menu bar).

My configuration is thus:

I have sloppy focus turned on (gsettings set org.gnome.desktop.wm.preferences focus-mode 'sloppy'). I have auto-raise turned off (gsettings set org.gnome.desktop.wm.preferences auto-raise false), and raise-on-click also turned off (gsettings set org.gnome.desktop.wm.preferences raise-on-click false).

Thus, the only way for me to bring one window to the front (not including Alt-Tab or similar switchers) is to click on the window title bar or border. Since maximized windows don't have a border, the title bar is my only option, but clicking it does not raise the window.