Always Visible and On Top Windows Steal Focus on Workspace Switch

[Alec Warner]

1. Open any application (e.g. TextEditor)
2. Right click the title bar
 2a. Select "Always on Visible Workspace"
3. Right click the title bar
 3a. Select "Always on Top"
4. Open a different application (e.g. Terminal)
5. Ensure that window has focus
6. Switch workspaces (Notice: the first application now has focus)
7. Return to first workspace (Notice: the second application does not regain focus)

Expected:

The initial application should not have ever regained focus, and certainly the second application should have it when returning to that workspace.

antarus@mach ~ $ lsb_release -rd
Description: Ubuntu 12.04.1 LTS
Release: 12.04

antarus@mach ~ $ apt-cache policy unity
unity:
  Installed: 5.18.0-0ubuntu2
  Candidate: 5.18.0-0ubuntu2
  Version table:

[Launchpad Janitor (janitor)]

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

[Chris J Arges (arges)]

I have observed this same behaviour in P/Q/R.

[Matt Goodall (matt-goodall)]

I believe another example of this is when using the Chromium Hangouts extension[1]. The extension uses Chromium Panels - small windows anchored to the edge of the screen that appear on all workspaces - and those panels have the same effect. See "Panels window causes Workspace switching focus to break"[2] for more.

[1] https://chrome.google.com/webstore/detail/hangouts/nckgahadagoaajjgafhacjanaoiihapd.
[2] https://code.google.com/p/chromium/issues/detail?id=295856

[Onyxwolf (onyxwolf-x)]

This affects Saucy too! same symptoms... To add to the symptoms, this also occurs when selecting an application (already launched, so just to switch to it, via unity launcher) other than the "Always on top/visable on all workspaces" application, when it must switch workspaces to focus the selected app... Instead of focusing the selected app, once the workspace is switched it will focus the "Always on top/visable on all workspaces" window instead.

This has been a security risk for me (let's try that approach :D , ok I know I can just disable the visable on all workspaces or always on top to fix BUT) as I've accidently provided my domain password to coworkers because of this issue. (IM client is my "Always on top/visable on all workspaces" so when I go to switch to my RDP session and I'm in a hurry, I just type out password and hit enter w/out thinking about it, so find I just IM'd my password to last my convo!!!! VERY annoying, as I've had to drop what I'm doing and change my password)!

I have confirmed the symptoms are present no matter what application I set to "Always on top/visable on all workspaces"...

[Mark Russell (marrusl)]

Does this make more sense to fix now that compiz/X is default in trusty?

[Andrew (publicface)]

I have what looks to be the same or a related problem. I experience it in a variety of instances, however the most recent example is in using jitsi - a softphone. I receive(d) a call in jitsi, I answer it. I then switch workspaces. When the call is terminated, I have to go back to jitsi and click on it in order to regain control of my mouse. ubuntu 12.04 with KDE/kubuntu-desktop.

apt-cache policy kubuntu-desktop
kubuntu-desktop:
  Installed: 1.254.1~ppa6
  Candidate: 1.254.1~ppa6
  Version table:
 *** 1.254.1~ppa6 0
        500 http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu/ precise/main i386 Packages
        100 /var/lib/dpkg/status
     1.254 0
        500 http://us.archive.ubuntu.com/ubuntu/ precise/main i386 Packages

[Edward (edward-coffey)]

This issue is present in trusty. Possibly a duplicate of #1073488
Google Hangout chats in Chrome (and Chromium?) are probably the most popular trigger for this issue.

[Kip Warner (kip)]

Unfortunately it looks like upstream has not expressed any interest in supporting a feature to deal with this situation, so unfortunately I don't think it's something we will be able to either. Supporting a separate fork of Compiz is not really something we have the resources for right now.

[Dariusz Gadomski (dgadomski)]

@Marco
I am thinking about a fix for this:
* Add a setting to change the current behavior (e.g. Remember viewport focus)
* Before changing viewport save the currently focused window
* When coming back to a viewport instead of focusing the default window do:
i) if the new setting is enabled try to restore the focus (if the window is still there)
ii) else fallback to the default behavior (focusDefaultWindow)

I want to know your opinion on this approach before starting the implementation.

Do you think it makes sense to implement this in core (src/) or is it rather specific to wall plugin and should be implemented there (along with the setting in wall plugin settings)?

[Marco Trevisan (Treviño) (3v1n0)]

I guess this is something that would affect also other VP implementations (such as cube), so I think it's better to do this at core level (if applicable).

I'm ok with the setting, so we could even enable it by default, eventually.

[Thomas Bushnell, BSG (tbushnell)]

Any estimate when this will be pushed for trusty?

[Marco Trevisan (Treviño) (3v1n0)]

2014-11-11 0:31 GMT+01:00 Thomas Bushnell, BSG <email address hidden>:
> Any estimate when this will be pushed for trusty?

Next SRU, so in probably two weeks.

[Christopher Townsend (townsend)]

The fix for this caused a couple of regressions as seen in bug #1393020 and bug #1398512. Due to this, we will have to revert this fix in Vivid and will need a proper fix. That said, moving this bug back to triaged for now.

[Bruno Nova (brunonova)]

Has there been no more progress on this issue?

This issue is very annoying in 16.04 when, for example, I have something like xpad "always visible".
When I switch to an "empty" workspace (with only xpad), xpad gains focus. But when I return to the previous workspace, xpad still has focus.
Worse, since I don't have xpad "always on top", xpad can have focus UNDER another window.

Something like that proposed "Remember viewport focus" option would be very nice, if it doesn't cause regressions, of course.

[Jonathan Jogenfors (etnoy)]

I also want to know the progress here. It is certainly an unexpected behavior on Unity when multiple monitors are used with viewport switching. Setting focus to follow the mouse is a clunky workaround and makes it very difficult to use programs such as gimp.

This bug has been "in progress" for years now. The fix can't be that difficult, honestly.