Window management - Apps raised from indicators sometimes dont have the focus

[Omer Akram]

Ubuntu 11.10 beta
compiz 1:0.9.5.94+bzr2803-0ubuntu5
unity 4.16.0-0ubuntu1

1. open banshee, start a song in it and minimize
2. open another application lets say gnome-terminal
3. click on the sound menu and select banshee

What happens
banshee icon in the launcher wiggles and banshee main window is not shown

What should happen
banshee main window should come to focus

This is a long standing bug which Ted Gould thinks should be fixed at window manager's level.

====Some other observations=====
The problem wont happen
1. if every other app is minimized or
2. Banshee is the only opened app or
3. after opening gnome-terminal, banshee window is closed so that it hides to the SoundMenu and opened again

=====Comment from Ted Gould=====
<om26er> tedg, Hi! any thoughts on the long standing bug 627195 ? Its been there before unity so I guess we can conclude unity not to be responsible

<tedg> om26er, My thought is that window managers should $%#$ get fixed... though I haven't convinced smspillaz of it yet.

=====The good rule=====
3v1n0: Indicators should present the application windows by passing to them the timestamp of the menu item activation event.

Unfortunately for indicator-sound, this is not trival as it sounds, since it needs a change to the MPRIS dbus specification.
See comment https://bugs.launchpad.net/ayatana-design/+bug/627195/comments/26 for more informations.

For what concerns libappindicator based indicators (such as the one used by tomboy), since it's not currently possible in libdbusmenu to pass the event during activation (so that clients will be able to get the proper timestamp using gtk_get_current_event_time), there are two "hackish" ways:
1. Use the server time to present a window:
   https://bugzilla.gnome.org/show_bug.cgi?id=688830
2. Get the event timestamp from the dbus-menu linked to the gtk-menus:
   https://archive.is/2tLX6
3. Qt applications workaround: http://is.gd/WnW9eN

Window managers will obey to it.

===================================

SRU for sni-qt:

[Test case]

git clone https://github.com/3v1n0/indicators-examples-snaps
cd indicators-examples-snaps/qt4-systray
qmake-qt4
./systray

Close the app, now try to restore it from in the indicator (after having played with some app writing text on it such as gnome-terminal or gedit).
The app should be in foreground now

[Omer Akram (om26er)]

The related rhythmbox bug 562191

[Omer Akram (om26er)]

Here is another example to reproduce.

[Omer Akram (om26er)]

in unity open gwibber, minimize it now click on the messaging menu and select Broadcast. gwibber window comes up but not focused

[Launchpad Janitor (janitor)]

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

[Omer Akram (om26er)]

<om26er> tedg, Hi! any thoughts on the long standing bug 627195 ? Its been there before unity so I guess we can conclude unity not to be responsible

<tedg> om26er, My thought is that window managers should $%#$ get fixed... though I haven't convinced smspillaz of it yet.

[Owais Lone (loneowais)]

I can fix this by setting "focus prevention level" from Low to None in CCSM

[Launchpad Janitor (janitor)]

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

[Laryllan (laryllan)]

I added this bug to the papercuts project.
It affects Empathy too.

[Chris Wilson (notgary-deactivatedaccount)]

Thanks for forwarding this to the paper cuts project, however it unfortunately doesn't qualify for inclusion there as any work this far down into the stack, ie at the level of the window manager, is non-trivial and so cannot be considered a paper cut.

[Nikolaus Waxweiler (madleser)]

Possibly related: Assign some key-combination to "show player" (e.g. meta-p) in system settings -> keyboard -> shortcuts -> multimedia, press combination, watch as symbol in dash to the left wiggles but does not put focus on it. Very annoying when I want to quickly change songs without moving the mouse to the left screen border, wait until dash shows up and select player icon (or worse yet, when not having media player attached to dash, use the sound indicator *before* having to do those steps). I'm now improvising by attaching the media player to the dash and pressing meta+<number of icon> to make the player window appear and be in focus. Sucks, but it works.

[Alexandr (olexandr-dmitriev)]

Hello, any forecasts if the fix will be released before final 12.04?

[TomasHnyk (sup)]

Another case that triggers this:
1. Install Opera (it does not happen wiht Firefox)
2. Set it to default browser (system settings > system info > default applications)
3. Run gnome-open http://www.ubuntu.com

[Alexandr (olexandr-dmitriev)]

The same on 12.04.

[Alexandr (olexandr-dmitriev)]

Sorry, but what the status fix commited means? Does it mean that this fix in proposed? If so - that it still does not work on 12.04, using gedit and devhelp plugin. The devhelp windows just blinking unusable in the appbar.
Maybe the status should be changed to confirmed?

[Sebastian Bator (eremit7)]

Fix committed does not mean that the fix is already distributed, that is „fix released“ (see wiki.ubuntu.com/Bugs/Status)

By the way, it is fixed in Ayatana, the upstream project, not Ubuntu itself.

[Alexandr (olexandr-dmitriev)]

Thank you, Sebastion, vor your explanation. I have already read about statuses and did not understand what does it mean according to this bug - fixed - but where and how? I tried to find this bug in changelogs and failed. I would be glad if you can explain me how and where to trace bug fixes in ayatana. Also I do not understand the difference between unity and ayatana projects. I was looking for this bug in unity...

Now I know that it is fixed and this makes me very happy! But how to know on which release this will be moved to ubuntu? Because the fix is dated 2011-11 and this looks a bit strange that this was not included to 12.04.

[Owais Lone (loneowais)]

Alexandr, fix-commited in ayatana means the design team has taken a decision about the matter, it has nothing to do with the code. This has not been fixed in compiz yet AFAIK.

[Omer Akram (om26er)]

That's bug in Compiz so removed unity package from affects.

[Launchpad Janitor (janitor)]

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

[glennric (glennric)]

I have a problem that i think might be related to this, but I want to make sure. If it isn't I will file a separate bug. When I raise a minimized window via an indicator the app seems to have focus, but lacks window decorations. This bug has been around through several Ubuntu releases. This only happens with compiz, and not metacity. Is this the same bug or is this different?
For example if Thunderbird is open, but minimized, and I click on "Thunderbird Mail" from the Messaging Menu in the indicator, then Thunderbird pops up, but there are no window decorations on it.

[glennric (glennric)]

I should add that the bug in my previous comment does not just occur when raising a minimized window via an indicator. It occurs when a minimized window is raised through about any means other than Alt-Tab or clicking on the minimized app itself.

[Pierce Gerhart (piercegerhart)]

This bug disappeared for a while for me, but it's back with a vengeance. Twice today I've closed the wrong window and lost work. I used to have the problem with Rhythmbox, but now It's Spotify. The symptoms are exactly the same otherwise.

[[e-mail] (mattmess1221)]

If you're still having the bug, in CCSM, go into General Options. In the "Focus & Raise Behavior" tab, select Low (default) for "Focus Prevention Level." If it still doesn't work, select off.

[TomasHnyk (sup)]

But changing that setting usually has other undesired effects regarding focus in other circumstances (at least according to my experience).

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

The MPRIS Raise method of the MediaPlayer2 interface does not require a timestamp parameter and this leads to focus issues in recent linux window managers (such as compiz, mutter or xfce) that need the event timestamp that triggered the call in order to correctly focus and raise a window. Otherwise the focus stealing prevention of the window managers would avoid a media player to be fully raised.

See for example this Ubuntu bug: https://bugs.launchpad.net/ayatana-design/+bug/627195

So, we should deprecate this method and provide another - say - RaiseWithTimestamp method that players should use to correctly raise their windows.

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

Unity is not the problem here.
Indicator-session should actually pass the activation timestamp to the player when raising it.

However, the problem is that IndicatorSound is just calling the Raise() method of the MPRIS dbus interface that most of the players are implementing. See: http://specifications.freedesktop.org/mpris-spec/latest/Media_Player.html#Method:Raise

As you see this method is not taking any parameter, while it should actually take the timestamp of the click event (the one we get into indicator-sound's MetadataMenuitem::handle_event), in order to work with the Focus Stealing Prevention mechanism that the windows managers are using nowadays (both compiz and mutter in fact).

I've opened a bug for the MPRIS specification at https://bugs.freedesktop.org/show_bug.cgi?id=62917 and I encourage you to complete it.
However this process can be long and until then the only way we have is to patch our players.

Basically what we need to do is *temporary* using the workaround shown in the bug linked below to bypass the focus stealing prevention when the Raise method is called on them:
https://bugzilla.gnome.org/show_bug.cgi?id=688830

[TomasHnyk (sup)]

Marco Trevisan: how does gnome-open fit into this (see my comment #13)

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

TomasHnyk: also gnome-open should pass the timestamp to the application it wants to launch, but it does not (it uses g_app_info_launch_default_for_uri without any GAppLaunchContext that keeps the event timeout), and this is not possible to do since in theory the terminal should pass the enter-key event timestamp to such programs. An environment variable could be used instead.

However starting from Raring, also nautilus would highlight this problem when you open a location from terminal (the same doesn't happen when launched from unity), for the very same reason. When you open it from unity all works fine since we pass the event timestamp to the application.

[TomasHnyk (sup)]

Marco: so both gnme-terminal and gnome-open should be patched? Should bugs against them be opened?

On a related note, is this bug https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/782758 related (only in reverse, because there, the problem is reversed - application gets focus even when it should not).

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

TomasHnyk: well, not sure... More than gnome-open gnome-terminal would be needed.
Not sure how much trivial it can be, though.

[TomasHnyk (sup)]

I see. So it is basically this bug that you filled: https://bugzilla.gnome.org/show_bug.cgi?id=693815

[Lars Karlitski (larsu)]

Instead of only passing a timestamp, this could be the same platform data that GApplication uses in its Activate method (of type "asv"). This would make passing these kinds of things more uniform and easier to handle for toolkits, as well as being extensible.

Maybe we could even call it Activate ;)

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-messages/13.04 at revision None, scheduled for release in indicator-messages, milestone 13.04.0

[Fdo-bugs (fdo-bugs)]

Not convinced that following GApplication's slightly esoteric form is helpful. The name's fine, but the way it encodes/decodes the timestamp is kinda weird.

We'll probably need a CanRaiseWithTimestamp property or some such to let clients know whether this is implemented. Or a HasRaiseWithTimestamp, which can be used in combination with CanRaise.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-sound/13.04 at revision 346, scheduled for release in indicator-sound, milestone 13.04.0

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-sound/13.04 at revision 347, scheduled for release in indicator-sound, milestone 13.04.0

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-messages at revision 339, scheduled for release in indicator-messages, milestone Unknown

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-sound at revision 346, scheduled for release in indicator-sound, milestone Unknown

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:indicator-sound at revision 347, scheduled for release in indicator-sound, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package empathy - 3.6.4-0ubuntu3

---------------
empathy (3.6.4-0ubuntu3) raring; urgency=low

  * debian/patches/47_git_activate_with_platform_data.patch:
    - Use g_application_activate to pass platform-data to the GtkApplication
      when running it. (LP: #627195)
 -- Marco Trevisan (Trevino) <email address hidden> Wed, 03 Apr 2013 18:24:18 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-messages - 12.10.6daily13.04.09-0ubuntu1

---------------
indicator-messages (12.10.6daily13.04.09-0ubuntu1) raring; urgency=low

  * Automatic snapshot from revision 340

indicator-messages (12.10.6daily13.04.08-0ubuntu1) raring; urgency=low

  [ Marco Trevisan (Treviño) ]
  * Window management - Apps raised from indicators sometimes dont have
    the focus (LP: #627195)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 339
 -- Ubuntu daily release <email address hidden> Tue, 09 Apr 2013 02:02:02 +0000

[Launchpad Janitor (janitor)]

This bug was fixed in the package indicator-sound - 12.10.2daily13.04.09-0ubuntu1

---------------
indicator-sound (12.10.2daily13.04.09-0ubuntu1) raring; urgency=low

  * Automatic snapshot from revision 348

indicator-sound (12.10.2daily13.04.08-0ubuntu1) raring; urgency=low

  [ Marco Trevisan (Treviño) ]
  * Indicator-sound should send the event timestamp when launching a
    player (LP: #1163434)
  * Window management - Apps raised from indicators sometimes dont have
    the focus (LP: #627195)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 347
 -- Ubuntu daily release <email address hidden> Tue, 09 Apr 2013 02:02:50 +0000

[Lars Karlitski (larsu)]

Created attachment 88321
Add org.mpris.MediaPlayer2.Activate

Alex, the desktop entry spec recently gained support for org.freedesktop.Application, which has a method Activate() that takes a platform data. I think it makes sense to reuse this terminology and the platform-data convention.

The attached patch deprecates Raise() and CanRaise in favor of Activate() and CanActivate.

[Rael Gugelmin Cunha (rael-gc)]

I'm on 14.04, and this still happens, for Rhythmbox, Empathy, etc.

[Rael Gugelmin Cunha (rael-gc)]

Ok, I realized that for some reason, any applications were gaining focus.

I fixed following this answer into askubuntu: http://askubuntu.com/questions/128738/when-i-launch-an-app-the-focus-doesnt-move-to-the-opened-app

Run in a terminal:

gconftool-2 --type=Integer --set /apps/compiz-1/general/screen0/options/focus_prevention_level 0

[Launchpad Janitor (janitor)]

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

[JaSauders (jasauders)]

Running 14.04.2 here with some of the same issues. I was seeing it with ownCloud client, network manager, and a weather applet known as my-weather-indicator. The issue came up at random, but it was easy to replicate within a matter of 15-20 seconds while continuously navigating around open windows followed by opening applications with system tray icons.

I brought up conversation with some other users who gave me a suggestion that has, so far, worked. Figured I'd post it here in case it can benefit anybody else until the bug can be properly fixed. I ran this in terminal, followed by a log out/log in.

dconf write /org/compiz/profiles/unity/plugins/core/focus-prevention-level 0

This is a similar idea that Rael posted in response 43 above. I seem to recall Ubuntu switching to dconf over gconf at some point. I tested it in my 14.04.2 virtual machine (brand new, but fully updated install) however the gconf key didn't appear to fix the issue, as I was still able to replicate it. In the same VM, that dconf write command above seemed to fix the issue, as I have been unable to replicate it in my VM, nor my main laptop.

The default focus-prevention-level is 1, which is considered "low", but appears to be the cause of this random behavior. Setting it to 0 seems to make it consistent. I haven't ran with this change for days/weeks/months, but in my tinkering so far today, the issue hasn't resurfaced a single time.

[JaSauders (jasauders)]

I couldn't see an obvious way to edit my above post, so apologies for sending out a second comment, but I do have to ask... why would the default parameter for focus-prevention-level not be 0 anyways? It doesn't seem, do I dare say, all that logical to have it set to 1 since it only ends up providing inconsistent behavior with the way things from system tray open. It being set to 0 provides that consistency. It would surely remove the "look on your launcher, see? it's there after all" comments I have to make quite often so users know that the application they tried to open from system tray isn't broken, it indeed launched, it's just... minimized and in your left launcher.

Thanks for all of your work!

[Matthew Paul Thomas (mpt)]

JaSauders, when a window opens or asks for focus, the window manager has to decide whether focusing it is a good idea.

If you choose an item in an indicator menu, wanting to see a particular window, obviously it should be focused, right? Well, no. For example, when I choose the date item in the clock menu, Evolution takes 31 seconds to launch and open its window. If I get bored and continue typing this comment in Firefox in the meantime, I don't want the Evolution window to be focused when it eventually opens, because that would mean some of my typing would go into the wrong window.

So, a window should be focused if you don't do anything -- or you aren't *about to* do anything -- between the time you ask for it and the time it opens. Simple enough, right? Well, no. Because the window manager usually doesn't know (A) exactly what action of yours -- if any -- caused the window to open in the first place, or (B) whether you are about to do something. (It can't see your finger getting ready to press a key, for example.) The fixes for this bug address (A), by including the timestamp of your menu selection with the request to launch a particular app. But sometimes that isn't possible, often it isn't supplied even when it is possible, and either way, that still doesn't address (B).

So the focus-prevention-level setting is a dial for how eager the window manager should be in granting focus requests. The higher it is, the more often you'll get focus sticking -- a window failing to take focus when you expect it to. But the lower it is, the more often you'll get focus stealing -- one window taking focus while you are trying to use another.

[Fdo-bugs (fdo-bugs)]

So... this has been sitting in my inbox for a *long* time, sorry.

I think a better approach would be to suggest clients make direct use of the desktop entry spec, rather than duplicating the methods here. We already have a property to direct clients to the desktop file for the media player, so they can check that desktop file for whether it can be activated, and call the org.freedesktop.Application Activate() method.

[Mathew Hodson (mhodson)]

Accepted sni-qt into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/sni-qt/0.2.7+16.04.20170217.1-0ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on 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 https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris Halse Rogers (raof)]

This appears to have been fixed in the sni-qt 0.2.7+17.04.20161124.2-0ubuntu1 upload to Zesty. Quite why the LP:# link in that upload didn't close this bug is unclear.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sni-qt - 0.2.7+16.04.20170217.1-0ubuntu1

---------------
sni-qt (0.2.7+16.04.20170217.1-0ubuntu1) xenial; urgency=medium

  * statusnotifieritem: reset app usertime on activation to ensure
    compiz will raise it (LP: #627195)
  * IconCache: get the proper theme path based on the fact we're using a
    themed icon or not (LP: #1600136)
  * fsutils: always use $XDG_RUNTIME_DIR if it's set for saving icons

 -- Marco Trevisan (Treviño) <[e-mail]> Fri, 17 Feb 2017 01:14:24 +0000

[Chris Halse Rogers (raof)]

The verification of the Stable Release Update for sni-qt 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.

[Gitlab-migration (gitlab-migration)]

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xdg/mpris-spec/issues/7.