[Bug 300062] Auth handler prompts for password on timeout when waiting for kwallet

Daniele E. Domenichelli daniele.domenichelli at gmail.com
Wed Dec 12 11:10:21 GMT 2012


https://bugs.kde.org/show_bug.cgi?id=300062

Daniele E. Domenichelli <daniele.domenichelli at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|Future                      |0.5.2

--- Comment #5 from Daniele E. Domenichelli <daniele.domenichelli at gmail.com> ---
With the last few changes the behavior has changed again, it is improving but
it is still not working perfectly so I investigated this issue a little
further:

* Nothing running and wallet closed
* MC starts is started somehow (normally on login by the presence plasmoid, but
it is reproducible by killing everything and starting it manually)
* MC starts gabble (or haze, etc)
* The connection is created for accounts with auto-connect enabled: mc-tool
reports  Current=offline Requested=available Changing=yes
* The kcm-auth-handler is started and it gets the auth channel to handle
* The kcm-auth-handler tries to open kwallet and the kwallet dialog pops up
* [wait]
* connection fails (timeout): mc-tool still reports  Current=offline
Requested=available Changing=yes
* if no accounts are connected gabble exits.
* now insert password in kwallet dialog. ktp-auth-handler can now read the
password but gets the channel invalidated signal (I'm not sure why it is not
received earlier), so it kills the authentication operation and removes the job
correctly. gabble is still not running. Presence stays Current=offline
Requested=available Changing=yes forever. Plasmoid keeps spinning forever.
* When all the jobs are done, ktp-auth-handler exits as expected.
* if you open the contact list, authentication starts again, this time the
wallet is open and accounts go online

I'm no longer sure if this is our problem or a bug in mission control reporting
the account to be changing even if it's not, what do you think?

Anyway, I have this problem at login also if I insert the password immediately
as soon as the kwallet dialog is displayed, perhaps the authentication starts
when the desktop is not yet ready, and the dialog is displayed too late... Do
you think we can delay this? is there any signal or method to be sure that the
desktop is ready before we request the presence?

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Kde-telepathy-bugs mailing list