[Edgy] Focus doesn't always follow window selection

Thanks for your bug. What mode of focus do you use (/apps/metacity/general/focus_mode and /apps/metacity/general/focus_new_windows with gconf-editor)? How do you toggle windows? With the tasks list? Or by clicking?

On Tue, Aug 29, 2006 at 07:08:39PM -0000, Sebastien Bacher wrote:
> Thanks for your bug. What mode of focus do you use
> (/apps/metacity/general/focus_mode and
> /apps/metacity/general/focus_new_windows with gconf-editor)?

Normally i use "focus follows mouse" but i tried with other focus modes
too and it appears to be consistent with other focus modes too. (i'll
get the exact values for you later)

> How do you toggle windows? With the tasks list? Or by clicking?

It would appear that it makes no difference how you toggle the windows.
I was able to reproduce this with clicking with mouse and by using
alt-tab. I didn't try toggling from the panel.

- S

--
     -< Sami Haahtinen >-
      -[ Notify immediately if you do not receive this message ]-
 -< 2209 3C53 D0FB 041C F7B1 F908 A9B6 F730 B83D 761C >-

can you make a screenshot of the issue? I'm not sure I understand the description, or you are the only one to get it, that works fine on my box and nobody else bugged about it. Is that specific to gnome-terminal or does it happen with gedit too by example?

Here are the values:

/apps/metacity/general/focus_mode: sloppy
/apps/metacity/general/focus_new_windows: smart

It's hard to take a screenshot of it as the only visual indication is the cursor in gnome-terminal (in other apps it will just appear as missing cursor)

It's not gnome-terminal specific, just a minute ago it appeared with gajim and now it appeared with firefox.

Oh and correction to my previous entry, alt-tab doesn't break. Things only break when changing windows with a mouse.

I can confirm this bug here

Seems to be a bug in metcity since "spiftacity --replace" seems to fix it.

Just read our question on irc, slomo: no, this bug doesn't appear with spiftacity. Since spifatcity is a "fork" of a previous version of metacity, the problem seems to be instroduced by one of the latest metacity updates.

Someone has the same problem with metacity 2.14.something on debian... so it doesn't seem to be caused by this :(

I get this problem with default settings using the latest metacity in Edgy - I think this is a very important bug to fix before release as it can mean you end up in states that lock your control;

For example, if you click to focus on a qemu window but metacity doesn't give focus, the keyboard will then be disabled and you'll be unable to move the mouse away from that window (so you have to alt+f4, losing any work you may have had).

There is a patch in http://bugzilla.gnome.org/show_bug.cgi?id=354422 which has also been applied to upstream CVS. I have left that bug open however, as I'd like to get more testers to verify whether there is more than one bug here causing issues (especially since I had a difficult time reproducing the problems mentioned in these bug reports).

Elijah wrote:
> I have left that bug open however, as I'd like to get more testers to
> verify whether there is more than one bug here causing issues

I've applied the patch locally and i've been using it for an hour or so.
Usually the bug strikes a couple of times in the first hour.

So far i've been unable to loose focus with the patch.

- S

Should be fixed with that upload:

 metacity (1:2.16.0-0ubuntu2) edgy; urgency=low
 .
   * debian/patches/090_from_bugzilla_fix_focus_stuck.patch:
     - patch from bugzilla #354422,
       fix "Focus doesn't always follow window selection" (Ubuntu: #57344)

Could people having that issue comment on the bug saying if that fix it?