On startup Gnome Keyring asks for password in the background

suspect this might really be a gnome-keyring issue

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

the duplicate comment was a bit quick but that's not a keyring issue, either a dialog focus one or a client one rather

The padlock icon allows a right click that offers the option to 'un-minimise' which could mean that its either started before the launcher or that its somehow started minimised?

Does someone reproduce the issue? It might a race on startup

I suspect to reproduce, you just need to enable autologin and then have a saved wifi connection that needs a password. Since your gnome keyring is still locked (isn't auto-unlocked when you autologin), NM needs to ask you to unlock it. (haven't tested myself to reproduce, just have seen this sort of thing before)

I'd like one other person to reproduce to see if it's a common issue; I think I understand what's going on, but it's the first report we ever got.

Tracking for SRUs, seems too intrusive to fix in karmic

Oliver Grawert saw the problem but here are the instructions to reproduce. Install with no net connection and select auto-login. When the new install comes up join a network and enter your credentials. From then on every boot results in a grey padlock appearing on the left hand side of the panel waiting for you to enter your password.

Hi,

I just installed Karmic Beta Netbook Remix in a Dell Mini 10v and I got this bug.

In the first session i saved my home network and then at first reboot I noticed that It was offline but i needed time to discover the window in background. I have autologin like reporter.

The lock in top right corner is a little clue (look screenshot) but it's an usability problem to fix, imho

I'm able to reproduce this also, the important pieces to make it happen are:
1. a saved wifi connection
2. you have to setup your gnome-keyring with a password, rather than leaving it blank
3. reboot the system

Workarounds are pretty simple and could probably be release noted if this can't be fixed for final image. Either no password can be provided for the keyring, and you will never be prompted for it. Or, if you do provide a password, you'll need to actually click the "lock icon" that comes up when the system boots to bring the password prompt to the foreground. However, it is correct that this is a fairly significant usability issue and many are likely to run into the problem.

Forgot to mention one item in the above list - auto-login needs to be enabled too I believe

Ok, we'll try to fix this one in time for the last karmic upload window on Monday.

Some comments about a possible resolution so that interested parties can comment and exchange while a fix is being worked on:
 - the bug seems to be triggered by gnome-keyring being launched early in the session, and then being masked by netbook-launcher when it starts later
 - a possible fix could be to be less aggressive in the way netbook-launcher raises it's main window on startup. The call to gtk_window_present may be a bit too much
 - some wnck wizardry might help in placing netbook-launcher just below the gnome-keyring window.

I've pushed a tentative fix to my PPA, but can not reproduce the problem to verify the fix.

I changed /etc/xdg/autostart/netbook-launcher.desktop to Exec=/usr/bin/netbook-launcher-wrapper which is a shell script with:
#/bin/sh
set -e
sleep 5
exec /usr/bin/netbook-launcher "$@"

But gnome-keyring appears on top of n-l when it loads, with or without my fix.

If someone with the issue could test the packages in my PPA that would be appreciated.

This is somewhat confusing. After looking at the code for nl-window, it appears it doesn't actually call gtk_window_present on itself at all. It does that for transient windows assigned to itself but not on itself. I think the keyring is actually getting minimized(?) rather than being obstructed from view. I am looking into fixing that.

Ok I have a more in depth break down of the bugs behavior.

1) Gnome Keyring window is opened (in the forground)
2) Netbook Remix Launcher is opened (in the background)
3) Window manager, for some reason performs a focus event on NL (netbook launcher)
4) In response, NL performs a wnck_screen_toggle_showing_desktop
5) Gnome Keyring window gets minimized

Resolving this issue is somewhat complex since the window manager behavior is not exactly defined. I hope that by setting the launcher as "keep below" it wont focus and thus wont be triggered. Though this is not reliable. We could try to delay the initialization of our wnck callbacks and try to work around that first triggering focus, however this will be a race condition. We could merely ignore the first focus, but again this behavior is undefined.

I think the best option (from NL's POV) is to merely get a wnckprop out of the gnome keyring, and use one of its properties to unminimize it if we find it. Kinda hacky really but I am not sure what else to do. I suppose we could implement our own form of show_desktop that ignores these kinds of windows, but that seems even more hacky.

A proper solution would be to make it so that gnome keyring windows simply refuse to minimize.

I agree with the solution to target only g-keyring's wnckprops: this should limit potential regressions.

I am still having significant issues duplicating this bug despite following instructions posted here. I do strongly believe this bug to be a race condition however. I have attached a branch that may help in this regard, if anyone can beta test it that is effected by the bug, please let me know.

Re: re-raising g-keyring windows. After playing around with it some more it is somewhat annoying to work with if you do not want to fill in the keyring request right away. Basically whenever one of those keyring windows is around you cannot in any way access the launcher. Is this acceptable?

Jason,

I've just checked out your branch and unfortunately it still doesn't work. This time you get to see the gnome-keyring dialog box for around a second before the netbook UI is shown over the top of it. So it looks like the dialog box is being obscured somewhere later in the chain.

Also, as the dialog box is in the background, it seems any subsequently launched apps don't grab the focus. Launch the Terminal app with gnome-keyring in the background and the cursor isn't active until you click the Terminal window.

This bug was fixed in the package netbook-launcher - 2.1.12-0ubuntu2

---------------
netbook-launcher (2.1.12-0ubuntu2) karmic; urgency=low

  * New patch, 60_unminise-gnome-keyring, unminimise gnome-keyring windows
    once on startup, in an idle handler, as the desktop toggling on
    netbook-launcher startup causes the window to be minimized; written by
    Neil Patel; LP: #447886.

 -- Loic Minier <email address hidden> Mon, 26 Oct 2009 11:32:32 +0000

Fixed it :)