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

Bug #627195 reported by Omer Akram
530
This bug affects 124 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Fix Committed
Critical
John Lea
DBus Menu
Triaged
Medium
Unassigned
MPRIS
Unknown
High
Messaging Menu
Fix Released
High
Marco Trevisan (Treviño)
13.04
Fix Released
High
Marco Trevisan (Treviño)
The Sound Menu
Fix Released
High
Marco Trevisan (Treviño)
13.04
Fix Released
High
Marco Trevisan (Treviño)
Ubuntu One Client
Fix Committed
Undecided
Marco Trevisan (Treviño)
empathy (Ubuntu)
Fix Released
Undecided
Marco Trevisan (Treviño)
Xenial
New
Undecided
Unassigned
indicator-messages (Ubuntu)
Fix Released
Undecided
Marco Trevisan (Treviño)
Xenial
New
Undecided
Unassigned
indicator-sound (Ubuntu)
Fix Released
Undecided
Marco Trevisan (Treviño)
Xenial
New
Undecided
Unassigned
libdbusmenu (Ubuntu)
Confirmed
Undecided
Unassigned
Xenial
New
Undecided
Unassigned
sni-qt (Ubuntu)
Fix Released
Undecided
Unassigned
Xenial
Fix Released
Medium
Unassigned
tomboy (Ubuntu)
Confirmed
Undecided
Unassigned
Xenial
New
Undecided
Unassigned
ubuntuone-client (Ubuntu)
Fix Released
Undecided
Marco Trevisan (Treviño)
Xenial
New
Undecided
Unassigned

Bug Description

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

Related branches

Revision history for this message
Omer Akram (om26er) wrote :
Revision history for this message
Omer Akram (om26er) wrote : Re: [Bug 627195] [NEW] applications that can come up quickly from the messaging menu or indicator applications can sometime not come up focused

The related rhythmbox bug 562191

Revision history for this message
Omer Akram (om26er) wrote :

Here is another example to reproduce.

Revision history for this message
Omer Akram (om26er) wrote : Re: many apps are unfocused when they are raised from MessagingMenu or SoundMenu

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

summary: - applications that can come up quickly from the messaging menu or
- indicator applications can sometime not come up focused
+ many apps are unfocused when they are raised from MessagingMenu or
+ SoundMenu
affects: indicator-applet → libindicate
Alex Launi (alexlauni)
Changed in libindicate:
status: New → Confirmed
Omer Akram (om26er)
affects: ayatana-ubuntu → unity
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in compiz (Ubuntu):
status: New → Confirmed
Revision history for this message
Omer Akram (om26er) wrote :

<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.

Changed in compiz (Ubuntu):
importance: Undecided → High
Changed in unity:
importance: Undecided → High
Changed in libindicate:
importance: Undecided → High
Changed in unity:
status: New → Confirmed
Omer Akram (om26er)
description: updated
affects: libindicate → ayatana-design
description: updated
summary: - many apps are unfocused when they are raised from MessagingMenu or
- SoundMenu
+ Apps raised from indicators sometimes dont have the focus
Revision history for this message
Owais Lone (loneowais) wrote : Re: Apps raised from indicators sometimes dont have the focus

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

Changed in compiz-core:
status: New → Confirmed
importance: Undecided → High
milestone: none → 0.9.5.96
John Lea (johnlea)
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
status: Confirmed → Fix Committed
tags: added: onew udo
John Lea (johnlea)
Changed in ayatana-design:
status: Fix Committed → Fix Released
John Lea (johnlea)
Changed in unity:
milestone: none → backlog
tags: added: udp
Changed in ayatana-design:
status: Fix Released → Fix Committed
John Lea (johnlea)
Changed in ayatana-design:
status: Fix Committed → Triaged
John Lea (johnlea)
Changed in unity:
assignee: nobody → Ted Gould (ted)
Changed in ayatana-design:
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Omer Akram (om26er)
Changed in unity (Ubuntu):
importance: Undecided → High
Revision history for this message
Laryllan (laryllan) wrote :

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

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

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.

no longer affects: hundredpapercuts
Revision history for this message
Nikolaus Waxweiler (madleser) wrote :

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.

Changed in compiz-core:
milestone: 0.9.5.96 → none
Omer Akram (om26er)
Changed in compiz-core:
status: Confirmed → Triaged
Changed in unity:
status: Confirmed → Triaged
Changed in compiz (Ubuntu):
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
John Lea (johnlea)
summary: - Apps raised from indicators sometimes dont have the focus
+ Window management - Apps raised from indicators sometimes dont have the
+ focus
John Lea (johnlea)
Changed in ayatana-design:
importance: High → Critical
Revision history for this message
Alexandr (olexandr-dmitriev) wrote :

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

Revision history for this message
TomasHnyk (sup) wrote :

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

Revision history for this message
Alexandr (olexandr-dmitriev) wrote :

The same on 12.04.

Revision history for this message
Alexandr (olexandr-dmitriev) wrote :

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?

Revision history for this message
Sebastian Bator (eremit7) wrote :

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.

Revision history for this message
Alexandr (olexandr-dmitriev) wrote :

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.

Revision history for this message
Owais Lone (loneowais) wrote :

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.

Changed in compiz:
importance: Undecided → High
status: New → Triaged
Revision history for this message
Omer Akram (om26er) wrote :

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

no longer affects: compiz-core
no longer affects: unity (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in unity (Ubuntu):
status: New → Confirmed
Ted Gould (ted)
Changed in unity:
assignee: Ted Gould (ted) → nobody
Tim Penhey (thumper)
Changed in unity:
milestone: backlog → none
Tim Penhey (thumper)
tags: added: exbacklog
John Lea (johnlea)
Changed in unity (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → High
Revision history for this message
glennric (glennric) wrote :

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.

Revision history for this message
glennric (glennric) wrote :

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.

Revision history for this message
Pierce Gerhart (piercegerhart) wrote :

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.

Revision history for this message
mattmess1221@gmail.com (mattmess1221) wrote :

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.

Revision history for this message
TomasHnyk (sup) wrote :

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

Changed in indicator-sound:
importance: Undecided → High
status: New → Triaged
Changed in compiz:
status: Triaged → Invalid
Changed in unity:
status: Triaged → Won't Fix
status: Won't Fix → Invalid
Revision history for this message
In , Marco Trevisan (Treviño) (3v1n0) wrote :

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.

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

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

description: updated
Changed in compiz (Ubuntu):
status: Triaged → Invalid
Changed in unity (Ubuntu):
status: Triaged → Invalid
Changed in indicator-sound (Ubuntu):
status: New → Confirmed
Revision history for this message
TomasHnyk (sup) wrote :

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

Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

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.

Revision history for this message
TomasHnyk (sup) wrote :

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).

Changed in indicator-sound:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
milestone: none → 13.04.0
status: Triaged → In Progress
Changed in mpris:
importance: Unknown → High
status: Unknown → Confirmed
Revision history for this message
Marco Trevisan (Treviño) (3v1n0) wrote :

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

Changed in indicator-sound (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: Confirmed → In Progress
Changed in indicator-messages:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
importance: Undecided → High
status: New → In Progress
Revision history for this message
TomasHnyk (sup) wrote :

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

Changed in empathy (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
Revision history for this message
In , Lars Karlitski (larsu) wrote :

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 ;)

Changed in indicator-sound:
milestone: 13.04.0 → none
assignee: Marco Trevisan (Treviño) (3v1n0) → nobody
status: In Progress → Triaged
Changed in indicator-messages:
assignee: Marco Trevisan (Treviño) (3v1n0) → nobody
status: In Progress → Triaged
Changed in indicator-messages (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
description: updated
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-messages:
status: Triaged → Fix Committed
Changed in indicator-messages:
status: Fix Committed → Triaged
Changed in indicator-messages (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
In , Fdo-bugs (fdo-bugs) wrote :

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.

Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-sound:
status: Triaged → Fix Committed
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-sound:
status: Fix Committed → Triaged
Changed in indicator-sound:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: Triaged → In Progress
Changed in indicator-messages:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: Triaged → In Progress
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-messages:
status: In Progress → Fix Committed
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in indicator-sound:
status: In Progress → Fix Committed
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in empathy (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in empathy (Ubuntu):
status: Fix Committed → Fix Released
Changed in indicator-sound (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-messages (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in indicator-sound (Ubuntu):
status: Fix Committed → Fix Released
Changed in indicator-messages:
milestone: none → 13.10.1
Changed in ubuntuone-client:
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
Changed in libdbusmenu:
importance: Undecided → Medium
status: New → Triaged
description: updated
Changed in tomboy (Ubuntu):
status: New → Confirmed
Changed in ubuntuone-client (Ubuntu):
assignee: nobody → Marco Trevisan (Treviño) (3v1n0)
status: New → In Progress
Changed in ubuntuone-client:
status: In Progress → Fix Committed
Dave Morley (davmor2)
tags: added: u1-notrack
description: updated
Changed in ubuntuone-client (Ubuntu):
status: In Progress → Fix Released
Ted Gould (ted)
Changed in indicator-messages:
status: Fix Committed → Fix Released
Changed in indicator-sound:
status: Fix Committed → Fix Released
Revision history for this message
In , Lars Karlitski (larsu) wrote :

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.

Revision history for this message
Rael Gugelmin Cunha (rael-gc) wrote :

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

Revision history for this message
Rael Gugelmin Cunha (rael-gc) wrote :

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

no longer affects: indicator-messages (Ubuntu Raring)
no longer affects: indicator-sound (Ubuntu Raring)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in libdbusmenu (Ubuntu):
status: New → Confirmed
Revision history for this message
JaSauders (jasauders) wrote :

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.

Revision history for this message
JaSauders (jasauders) wrote :

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!

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

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.

Revision history for this message
In , Fdo-bugs (fdo-bugs) wrote :

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.

description: updated
description: updated
Revision history for this message
Mathew Hodson (mhodson) wrote :

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!

Changed in sni-qt (Ubuntu Xenial):
importance: Undecided → Medium
status: New → Fix Committed
no longer affects: unity (Ubuntu Xenial)
no longer affects: unity (Ubuntu)
no longer affects: compiz (Ubuntu Xenial)
no longer affects: compiz (Ubuntu)
affects: compiz → ubuntu-translations
no longer affects: ubuntu-translations
Mathew Hodson (mhodson)
affects: unity → ubuntu-translations
no longer affects: ubuntu-translations
tags: added: verification-needed
tags: added: verification-done
removed: verification-needed
Revision history for this message
Chris Halse Rogers (raof) wrote :

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.

Changed in sni-qt (Ubuntu):
status: New → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

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) <mail@3v1n0.net> Fri, 17 Feb 2017 01:14:24 +0000

Changed in sni-qt (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Chris Halse Rogers (raof) wrote : Update Released

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.

Revision history for this message
In , Gitlab-migration (gitlab-migration) wrote :

-- 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.

Changed in mpris:
status: Confirmed → Unknown
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

Bug watches keep track of this bug in other bug trackers.