0.9.7: impossible to click on keyring dialog since the upgrade

Clicking to high, it makes impossible to confirm the keyring creation and will probably bite in other cases, the setup of this dialog is a bit special though, I think that the first dialog grab the focus to force you type your password there and the second one is transient from it or something

I wasn't able to test this with a new session, but at least this branch allows the keyring dialog in seahorse to get focus when it comes up for the first time. I have a suspicion gnome-keyring does the same thing too (eg, has window A B and C, B and C are transients for A, C is opened and requests focus, B unmaps which makes core want to revert the focus back to A which means C ends up without focus).

Hi Seb,

Sam has made a best guess on the fix based on a similar app. But is unable to test against the gnome keyring.

The daily build for compiz is running now, can you check to see if the bug is fixed with that, and if so mark this fix committed, otherwise back to confirmed.

Thanks.

Merged into lp:compiz-core at revision 3000.

Though final testing is pending. This may go back to Confirmed yet.

just tried r3003 from the compiz testing ppa, the issue is still there, I can't click on the confirmation dialog, I also get the decorations on the wrong side since today's update (i.e on the right), not sure if that's a compiz or unity change though

confirmed by downgraded to r2999 from yesterday, the decorator has buttons on the left again, upgrading to 3003 they are on the right, there is an issue with compiz

Confirm, I get the same here.

the decorator buttons issue might be a packaging but, it seems the current testing ppa source has no patches at all, which means i.e the ubuntu config got dropped

I come from bug LP 940836. I see that the current compiz 1:0.9.7.0~bzr2995-0ubuntu5 contains the fix_931958.patch which is a subject of this bug, yet setting the empty password for keyring is not possible.
Setting back to Confirmed.

And I just checked that this does not happen in Unity 2D environment, so this is indeed a bug in compiz.

Fix committed into lp:compiz-core at revision 3000

Since I still had the problem, the workaround I used was logging out and logging in to unity2d and then setting to no password.

This bug was fixed in the package compiz - 1:0.9.7.0+bzr3035-0ubuntu1

---------------
compiz (1:0.9.7.0+bzr3035-0ubuntu1) precise; urgency=low

  [ Łukasz 'sil2100' Zemczak ]
  * New upstream snapshot:
    - Fix gtk-window-decorator crash upon demaximizing a window (LP: #930071)
    - Fix core keybindings (LP: #930412)
    - Fixes compiz crash with SIGSEGV on shutdown (LP: #931283)
    - Plugins can't tell the difference between a key-tap and modifier
      key-release (LP: #925293)
    - compiz-core r3001 (and 3002) ftbfs (LP: #933226)
    - Semi-maximized windows have no shadow or frame (LP: #924736)
    - Untranslated strings in gtk-window-decorator (LP: #780505)
    - Initialize the _NET_WM_STATE_FOCUSED (LP: #932087)
    - [regression] Customized shortcuts don't work (LP: #931927)
    - Window stacking problem (LP: #936675)
    - Quickly demaximized windows can receive maximized window decorations if
      they were initially maximized (LP: #936778)
    - Maximized windows do not get shadows at all (LP: #936774)
    - [regression] Launcher, top panel and keyboard un-responsive after using
      any Super-x shortcut (LP: #934058)
    - No draggable border if mutter isn't installed (LP: #936781)
    - Fix compiz crash with SIGSEGV in XDefineCursor() (LP: #936487)
    - Fixes memory leak at DecorWindow::updateSwitcher() (LP: #940115)
    - Unresolved symbols in plugins cause compiz to exit (LP: #938478)
    - Fix compiz spending about 51% of its CPU time in CompRegion
      construction/destruction (LP: #940139)
    - Fix Conditional jump or move depends on uninitialised value(s) in
      decor_match_pixmap (LP: #940066)
    - Fix 'show desktop' behaviour (LP: #871801)
    - Tweak algorithm used to cast shadows on maximized windows (LP: #936784)
    - "Svg" and "Png" should be "SVG and "PNG" (LP: #942890)
    - Fix invalid memory usage after free() in DecorWindow (LP: #943116)
    - Fix alt + F10 (LP: #943223)
  * Removed cherry-picked patches
  * debian/patches/fix_944631.patch:
    - Always replay the keyboard if something was grabbed and didn't trigger
      an action and don't trigger actions which aren't added accidentally
      (LP: #943612) (LP: #944631)
  * debian/patches/fix_923683.patch:
    - Backports a patch which prevents the shift race condition

  [ Didier Roche ]
  * debian/patches/fix_alt_pressing.patch:
    - Patch from ddv to fix all the regressions with the alt key fix and other
      (LP: #943851, #945373)
    - Fix Quicklist are not showing if right-clicking a launcher icon in Expo
      mode if triggered by Super + S (LP: #944979)
  * debian/patches/fix_806255.patch:
    - Unity/compiz intercepts keystrokes from grabbed windows (LP: #806255)
  * debian/patches/fix_943194.patch:
    - second part for the alt key fix (LP: #943194)
  * debian/patches/additional_alt_tapping_fix.patch:
    - again another alt tapping related fix for some regressions from the
      previous branch. Taken from "tapping-panacea" upstream branch.
 -- Didier Roche <email address hidden> Mon, 12 Mar 2012 10:22:10 +0100

reopening, that's still an issue with compiz 0.9.7.2, one way to get it also is to use seahorse to change you keyring password and try to set an empty one

This is seahorse being stupid.

Applications shouldn't retain grabs while they have modal dialogs open. This is what seahorse is doing. The fact that is works on metacity is a fluke because seahorse is deciding not to take a grab in the particular focus path that metacity uses. Seahorse is also broken on kwin and gnome-shell.

This bug was fixed in the package gnome-keyring - 3.2.2-2ubuntu3

---------------
gnome-keyring (3.2.2-2ubuntu3) precise; urgency=low

  * debian/patches/05_grab_tracking.patch: track when we ungrabbed the keyboard
    because the window state changed so that we only re-grab it when
    we had initially ungrabbed it for this reason. (LP: #931958)
 -- Sam Spilsbury <email address hidden> Tue, 03 Apr 2012 15:46:24 +0800