Plank blocks global keybindings when given focus

Bug #1008577 reported by Sergey "Shnatsel" Davidoff on 2012-06-04
This bug affects 34 people
Affects Status Importance Assigned to Milestone
Fix Released
Rico Tzschichholz
Pantheon Dock

Bug Description

Plank sometimes grabs focus on closing the focused window, blocking even Compiz key combos. Also observed in Mutter, not sure about keybindings there, though.

Robert Dyer (psybers) wrote :


1) version of plank (output of plank -d would contain this information)
2) is it our build, or a custom fork (like elementary os)?
3) steps to reliably reproduce this issue
4) how do you know plank is 'focused'? a focused window doesnt 'grab' the keyboard, fyi.

Changed in plank:
importance: Undecided → Low
status: New → Incomplete

Happens for a long while now, both on versions from Rico's PPA and elementary builds. I believe it happens on closing fullscreen window, when Plank shows up in intellihide mode. I can't reproduce it right now though, I'm using Gala with elementary hide mode and it's been reported as a bug in Gala previously, see bug 1008234

Plank is shown and every other window has unfocused theming... I'm not sure what made me think it was Plank and not some other desktop component, probably because Plank shows up just before it happens... I'll try to do some more testing.

I have steps to reproduce this, at least in elementary hide mode under Gala WM (Mutter derivative).
1) Open and maximize a window (e.g. Totem)
2) Bring up a dialog (e.g. press Ctrl+S or select the appropriate item in the menu)
3) Close the dialog
The dock will not hide and the maximized window will not be focused until I click it.
I have Plank version 0.2.0~bzr651+dnd354-0elementary1~precise1 but this bug seems to have occured for ages now, even in vanilla builds.

Changed in plank:
status: Incomplete → New

Instead of opening a dialog, one can open Slingshot app launcher. Plank will not hide and the window beneath it will not gain focus.

Robert Dyer (psybers) wrote :

I'm fairly certain this is by no fault of Plank. You need to file a bug against your specific window manager, which is focusing a window marked as a DOCK (which should never happen).

Changed in plank:
status: New → Invalid
summary: - Grabs focus on closing focused window, blocks even WM keybindings
+ Plank grabs focus on closing focused window, blocks even WM keybindings

If the same bug happens in mutter and not just compiz, then it's probably not a compiz issue.

Changed in compiz:
status: New → Invalid
Changed in gala:
status: New → Fix Released

Okay, Gala was patched to always give focus to a normal window, if there's one. However, when all normal and dialog windows on a workspace are closed, Plank is given focus, and somehow it blocks all desktop-wide keybindings - both those provided by WM and by gnome-settings-daemon. This should not happen.

summary: - Plank grabs focus on closing focused window, blocks even WM keybindings
+ Plank interrupts WM keybindings when given focus
Changed in plank:
status: Invalid → New
summary: - Plank interrupts WM keybindings when given focus
+ Plank blocks global keybindings when given focus
no longer affects: compiz

Still happens to me. Version dumps:

precise@precise-beta-portable ~> plank -d
[INFO 15:09:30.719314] [AbstractMain:176] Plank version:
[INFO 15:09:30.719405] [AbstractMain:177] Kernel version: 3.2.0-26-generic
[INFO 15:09:30.719461] [AbstractMain:178] GLib version: 2.32.3
[INFO 15:09:30.719511] [AbstractMain:179] GTK version: 3.4.2
[INFO 15:09:30.719560] [AbstractMain:180] Wnck version: 3.4.0
[INFO 15:09:30.719614] [AbstractMain:181] Cairo version: 1.10.2
[INFO 15:09:30.719668] [AbstractMain:182] Pango version: 1.30.0

precise@precise-beta-portable:~$ LC_ALL=C apt-cache policy plank
  Installed: 0.2.0~bzr660+dnd357-0elementary1~precise1
  Candidate: 0.2.0~bzr660+dnd357-0elementary1~precise1
  Version table:
 *** 0.2.0~bzr660+dnd357-0elementary1~precise1 0
        500 precise/main amd64 Packages
        100 /var/lib/dpkg/status
     0.2.0~bzr659+dnd357-0ubuntu1~12.04~ricotz1 0
        500 precise/main amd64 Packages

Rico Tzschichholz (ricotz) wrote :

trunk 684 might fix this partly

Changed in plank:
status: New → Incomplete
Changed in plank:
status: Incomplete → In Progress
Changed in plank:
status: In Progress → Incomplete
Changed in plank:
importance: Low → Undecided
Robert Dyer (psybers) wrote :

So the problem is that your WM is focusing Plank? Because it should never do that - docks don't gain focus.

The problem is still there as of Gala 0.1-0~r266+pkg15~precise1 and Plank 0.2.0~bzr719+dnd373-0elementary1~precise1
I have no idea whose fault it really is and I don't really care by now, so marking elementaryos affected just to make sure this bug doesn't get lost.

Changed in gala:
status: Fix Released → Confirmed
Changed in elementaryos:
milestone: none → luna-beta2
un liyim (a10279) wrote :

I'm not using Plank. I use Docky instead and I have the same problem too. So I'm not sure if this is related to Plank.

bwat47 (bwat47) wrote :

I think its something with gala. I was experiencing the issue when I was using gala with XFCE.

bwat47 (bwat47) wrote :

I don't have this problem at all when using plank under cinnamon (muffin, a mutter fork).

Tom Beckmann (tombeckmann) wrote :

In cinammon, you got a desktop window, nautilus, so mutter/muffin has no problem to figure where to move focus to.

Daniel Fore (danrabbit) on 2012-12-23
Changed in elementaryos:
milestone: luna-beta2 → luna-beta3

So what I'm gathering is that the issue exists because we don't have a window to give focus to when there are no windows open. How does GNOME Shell handle this when Nautilus isn't drawing the desktop? I imagine it's a similar situation.

Tom Beckmann (tombeckmann) wrote :

GNOME shell has no Plank. If you run it, it should cause the same issue.

Changed in plank:
status: Incomplete → Opinion
status: Opinion → Incomplete
bwat47 (bwat47) wrote :

Any progress on this? Definitely one of the most annoying bugs in luna... Couldn't we just have something draw a desktop window in luna? I know you guys don't want desktop icons, but you don't need to enable desktop icon functionality for it.

Cody Garver (codygarver) wrote :

We have something that does, lp:pantheon-wallpaper but it has memory leaks.

Cody Garver (codygarver) on 2013-04-20
Changed in pantheon-dock:
milestone: none → luna-beta3
no longer affects: elementaryos
Changed in gala:
milestone: none → luna-beta3
importance: Undecided → High
Changed in pantheon-dock:
importance: Undecided → High
Cody Garver (codygarver) on 2013-05-14
Changed in pantheon-dock:
status: New → Incomplete
Robert Dyer (psybers) on 2013-05-16
Changed in plank:
status: Incomplete → Invalid

More like "Won't Fix" than "Invalid". Plank does completely grab keyboard after all.

blitux (dev-pabloquiroga) wrote :

This affects all people who use drop down terminals like guake, tilda, terra, etc. and other kind of aps (like synapse). The only workaround, if there are no windows on desktop, is to open an app and focus it, and then pressing the key/keys binded to the app.

Cody Garver (codygarver) on 2013-06-27
Changed in gala:
milestone: 0.3-beta1 → luna-rc1
Tom Beckmann (tombeckmann) wrote :

Apparently mutter feels the need to always focus a window, if nothing's left it will even go for a dock window, see (the "else return topmost_dock" part).

However, removing the line in src/Widgets/DockWindow.vala telling the DE that plank will not accept focus seems to make the blocking on plank go away, at least it did here as far as I tested, thus practically solving the issue. I don't know if there are any unwanted consequences though, but looks like wingpanel can live without that flag.

Cody Garver (codygarver) on 2013-08-11
Changed in gala:
milestone: luna-rc1 → 0.3-beta1
Allen Lowe (lallenlowe) wrote :

This bug is painfully present in Luna Final Release. It is a real showstopper when your keyboard suddenly seems to stop responding. We should push a fix out to Luna for this, not just for isis.

Changed in gala:
importance: High → Critical
Cameron Norman (cameronnemo) wrote :

@Tom Beckmann, where is that line?

Cameron Norman (cameronnemo) wrote :

Nevermind, I found it in plank. But you said it was src/Widgets/DockWindow.vala. It is *lib*/Widgets/DockWindow.vala (line 69 right now).

So how has that been going for you, Tom? Is it working, or no?

Robert Dyer (psybers) wrote :

Correct me if I'm wrong, but the fact Plank's window says it does not accept focus and Gala gives Plank's window focus... seems to imply there is a bug in Gala. Removing that line from Plank might fix the symptom, but not the actual bug. It's a hack.

Cameron Norman (cameronnemo) wrote :

I totally agree. Be assured that you will never get a merge request from me removing that line. Pantheon dock, however, might. Simply for the sake of this bug has >100 fire balls.

It seems that it is a bug in libmutter by the looks of Tom Beckmann's link (comment 24). At the top of the block of code with the

    return topmost_dock;

there is a comment that says

Find the topmost, focusable, mapped, window.

so it is probably a libmutter/Gala bug.

I have the same problem, either using mutter oder gala as window manager and independent of plank running or not.

Actually the behaviour is quite weird: the keypress event is routed to the focused window, but without the <super> modifier.

If a terminal is focussed and I press "<super>+t", the terminal gets a "t".

If I press "<super>+t" again without releasing "<super" an other terminal window opens.
I then can open any amount of terminals without releasing <super>.

If I release <super> the next "<super>+t" is shown in the last opened terminal window as "t".

Same problem here guys, in different computers. I'm using Luna and i am a keyboard addicted user. It is very annoying that sometimes i have to stop my activity to click on plank or wingpanel. Please fix this bug.
However it happens often after closing Chromium, Synaptic or "not included by default" app.
For example, if you open and close Files no issue, but if you open and close Files as administrator the bug appears.

Changed in gala:
importance: Critical → High
Rico Tzschichholz (ricotz) wrote :

This bug is fixed in "mutter - 3.4.1-0ubuntu99~elementary7" and will also be included in mutter 3.10.1

Changed in pantheon-dock:
status: Incomplete → Invalid
Changed in gala:
status: Confirmed → Fix Committed
assignee: nobody → Rico Tzschichholz (ricotz)
Rico Tzschichholz (ricotz) wrote :

Keep tracking this as gala bug

no longer affects: plank
Cody Garver (codygarver) on 2013-11-21
Changed in gala:
status: Fix Committed → Fix Released
Daniel Fore (danrabbit) on 2014-01-17
Changed in pantheon-dock:
milestone: isis-beta1 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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