[compiz++] Compiz sometimes loses focus when closing some windows

[Chow Loong Jin]

Binary package hint: compiz

With compiz++, closing certain windows can cause focus to be completely lost, such that even Compiz's keybindings do not work until clicking on another window.

Currently the only consistent way I have been able to reproduce it is using Pidgin, by bringing the buddy list to the top via a keybinding in Compiz and this command: dbus-send --session --dest=im.pidgin.purple.PurpleService --print-reply /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterace.PurpleBlistSetVisible int32:1

What happens is:-
1. Press keybinding
2. Pidgin's window appears on top of everything, but unfocused, and demanding attention (focus prevention = normal)
3. Use the "Activate Demanding Attention Window" action from Extra WM Actions
4. Pidgin is now focused. Press Alt+F4 to get rid of it.
5. Focus is now completely lost, and none of Compiz's keybindings work until clicking on a window to bring focus to it.

Further experimentation has shown that Pidgin's buddy list window is the only one which appears on top even when not focused, and I think this may be related to why focus is lost when closing this window.

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.2.1+glibmainloop2-0ubuntu1

---------------
compiz (1:0.9.2.1+glibmainloop2-0ubuntu1) natty; urgency=low

  * new upstream snapshot with glibmm experimental branch:
    - Compiz crashes when scrolling in Openoffice (LP: #675506)
    - Compiz sometimes loses focus when closing some windows (LP: #671459)
    - Fix --replace hang (LP: #680165)
  * debian/65compiz_profile-on-session:
    - add unity profile to default session
  * debian/rules:
    - add bailer, detection, regex and animation and fade plugin to both
      profiles
    - get an optimized plugin default order
  * debian/patches/060_move_checks_to_compiz.patch:
    - start stripping it down as now we have a detection and bailer plugins
      for that. The failsafe session should be moved in the detection plugin.
  * debian/patches/055_fix_COMPIZ_DEFAULT_PLUGINS.patch,
    debian/patches/056_Preserve-DESTDIR-if-no-override-in-COMPIZ_DESTDIR.patch
    debian/patches/057_update_gnome_bindings.patch:
    - removed, upstreamed
  * debian/patches/065_add_bailer_and_detection_plugins.patch:
    - add bailer and detection plugins to fallback to 2D session or run in
      degraded mode.
  * debian/compiz-gnome.install, debian/unity.ini,
    debian/compiz-gnome.gconf-defaults:
    - add the unity profile to ini and gconf backend
  * debian/patches/001_fix_gconf_path.patch:
    - fix the path when generating the gconf keys (compiz-1)
  * debian/patches/002_ship_splited_gconf_cmakeext_files.patch:
    - ship and link the splited gconf extension schema builder
  * debian/control:
    - add libglibmm-2.4-dev build-dep and to -dev dep
  * debian/patches/003_more_gconf_parser_fix.patch:
    - fix parser breakage with some plugins
 -- Didier Roche <email address hidden> Fri, 26 Nov 2010 20:30:56 +0100

[Chow Loong Jin (hyperair)]

Reopening bug due to newfound test case:
1. Switch to an unused workspace (nothing open there)
2. Use GNOME Do's keybinding to open it.
3. Press Esc in GNOME Do's window to deactivate it without launching anything.
4. Try using any global keybinding -- it won't work.
5. Click on the desktop to restore focus.
6. Repeat #4 and notice that keybindings work again.

  status triaged

--
Kind regards,
Loong Jin

[Launchpad Janitor (janitor)]

This bug was fixed in the package compiz - 1:0.9.2.1+glibmainloop3-0ubuntu1

---------------
compiz (1:0.9.2.1+glibmainloop3-0ubuntu1) natty; urgency=low

  * new glibmainloop branch snapshot:
    - fix launching an application set it to the wrong place (LP: #683273)
    - Can't resize windows to be displayed on several monitors (LP: #455378)
    - Scale All Windows gets its suffixes wrong for a 3x3 layout (LP: #683063)
    - Compiz sometimes loses focus when closing some windows (LP: #671459)
    - Fix hanging when session exit (LP: #683121)
  * debian/patches/000_fix_OOo_crash1.patch
    debian/patches/000_fix_OOo_crash2.patch
    debian/patches/001_fix_gconf_path.patch
    debian/patches/003_more_gconf_parser_fix.patch:
   - remove, upstreamed.
  * debian/patches/060_move_checks_to_compiz.patch:
    - adapt to new version
  * debian/patches/01_backport_trunk_fix.patch:
    - backport some additional fixes from trunk, otherwise compiz crash at start
  * debian/source_compiz.py:
    - fix gconf path
  * debian/compiz-gnome.gconf-defaults, debian/rules, debian/unity.ini,
    debian/patches/030_no_fade_in_staticswicher.patch:
    - change order to load fade before staticswichter to avoid the fade effect
      when alt + tabbing (LP: #683635)
    - add snap and workarounds by default as well
  * debian/compiz-gnome.gconf-defaults,
    debian/compiz-keybindings.sed,
    debian/patches/021_hide_tooltip_on_decorator.patch,
    debian/patches/057_update_gnome_bindings.patch:
    - update the gconf path from allscreens to screen0 as new gconf path in the
      gconf backend
  * debian/control:
    - handle the ABI breakage with other compiz components
 -- Didier Roche <email address hidden> Mon, 13 Dec 2010 16:38:10 +0100

[Daniel Wagenaar (dawagenaar)]

In Compiz 0.9.4.0 as shipped with Ubuntu 11.04 this bug still affects me. I am not using Unity, but "classic gnome". When I close the last window on a workspace using key bindings, so that no window has focus any more, key bindings cease to work. I first noticed this happening if Nautilus is running without drawing the desktop (I use Compiz's wallpaper plugin). However, the problem did not go away if I re-enabled Nautilus's desktop.

Perhaps this is naive, but why doesn't Compiz process key bindings independently of whether any window has focus? Focus state seems hardly relevant for key bindings for, e.g., Desktop Wall.

[Sam Spilsbury (smspillaz)]

On Sat, Jun 11, 2011 at 11:02 PM, Daniel Wagenaar <email address hidden> wrote:
> In Compiz 0.9.4.0 as shipped with Ubuntu 11.04 this bug still affects
> me. I am not using Unity, but "classic gnome". When I close the last
> window on a workspace using key bindings, so that no window has focus
> any more, key bindings cease to work. I first noticed this happening if
> Nautilus is running without drawing the desktop (I use Compiz's
> wallpaper plugin). However, the problem did not go away if I re-enabled
> Nautilus's desktop.

Interesting. Could you run xev -root in a terminal, reproduce this bug
and then send me the output ?

>
> Perhaps this is naive, but why doesn't Compiz process key bindings
> independently of whether any window has focus? Focus state seems hardly
> relevant for key bindings for, e.g., Desktop Wall.

We use XGrabKey, so this shouldn't be an issue.

>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/671459
>
> Title:
>  [compiz++] Compiz sometimes loses focus when closing some windows
>
> Status in “compiz” package in Ubuntu:
>  Fix Released
>
> Bug description:
>  Binary package hint: compiz
>
>  With compiz++, closing certain windows can cause focus to be
>  completely lost, such that even Compiz's keybindings do not work until
>  clicking on another window.
>
>  Currently the only consistent way I have been able to reproduce it is
>  using Pidgin, by bringing the buddy list to the top via a keybinding
>  in Compiz and this command: dbus-send --session
>  --dest=im.pidgin.purple.PurpleService --print-reply
>  /im/pidgin/purple/PurpleObject
>  im.pidgin.purple.PurpleInterace.PurpleBlistSetVisible int32:1
>
>  What happens is:-
>  1. Press keybinding
>  2. Pidgin's window appears on top of everything, but unfocused, and demanding attention (focus prevention = normal)
>  3. Use the "Activate Demanding Attention Window" action from Extra WM Actions
>  4. Pidgin is now focused. Press Alt+F4 to get rid of it.
>  5. Focus is now completely lost, and none of Compiz's keybindings work until clicking on a window to bring focus to it.
>
>  Further experimentation has shown that Pidgin's buddy list window is
>  the only one which appears on top even when not focused, and I think
>  this may be related to why focus is lost when closing this window.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/671459/+subscriptions
>

--
Sam Spilsbury

[Sam Spilsbury (smspillaz)]

On Sat, Jun 11, 2011 at 11:13 PM, Sam Spilsbury <email address hidden> wrote:
> On Sat, Jun 11, 2011 at 11:02 PM, Daniel Wagenaar <email address hidden> wrote:
>> In Compiz 0.9.4.0 as shipped with Ubuntu 11.04 this bug still affects
>> me. I am not using Unity, but "classic gnome". When I close the last
>> window on a workspace using key bindings, so that no window has focus
>> any more, key bindings cease to work. I first noticed this happening if
>> Nautilus is running without drawing the desktop (I use Compiz's
>> wallpaper plugin). However, the problem did not go away if I re-enabled
>> Nautilus's desktop.
>
> Interesting. Could you run xev -root in a terminal, reproduce this bug
> and then send me the output ?
>
>>
>> Perhaps this is naive, but why doesn't Compiz process key bindings
>> independently of whether any window has focus? Focus state seems hardly
>> relevant for key bindings for, e.g., Desktop Wall.
>
> We use XGrabKey, so this shouldn't be an issue.

Well, rather, XGrabKey doesn't work in situations where the focus is
on a parent window (eg the root window) which is probably what's
happening in this case.

>
>>
>> --
>> You received this bug notification because you are a bug assignee.
>> https://bugs.launchpad.net/bugs/671459
>>
>> Title:
>>  [compiz++] Compiz sometimes loses focus when closing some windows
>>
>> Status in “compiz” package in Ubuntu:
>>  Fix Released
>>
>> Bug description:
>>  Binary package hint: compiz
>>
>>  With compiz++, closing certain windows can cause focus to be
>>  completely lost, such that even Compiz's keybindings do not work until
>>  clicking on another window.
>>
>>  Currently the only consistent way I have been able to reproduce it is
>>  using Pidgin, by bringing the buddy list to the top via a keybinding
>>  in Compiz and this command: dbus-send --session
>>  --dest=im.pidgin.purple.PurpleService --print-reply
>>  /im/pidgin/purple/PurpleObject
>>  im.pidgin.purple.PurpleInterace.PurpleBlistSetVisible int32:1
>>
>>  What happens is:-
>>  1. Press keybinding
>>  2. Pidgin's window appears on top of everything, but unfocused, and demanding attention (focus prevention = normal)
>>  3. Use the "Activate Demanding Attention Window" action from Extra WM Actions
>>  4. Pidgin is now focused. Press Alt+F4 to get rid of it.
>>  5. Focus is now completely lost, and none of Compiz's keybindings work until clicking on a window to bring focus to it.
>>
>>  Further experimentation has shown that Pidgin's buddy list window is
>>  the only one which appears on top even when not focused, and I think
>>  this may be related to why focus is lost when closing this window.
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/671459/+subscriptions
>>
>
>
>
> --
> Sam Spilsbury
>

--
Sam Spilsbury