Making Password Prompts Serial again

Mark Banner mbanner at
Thu Mar 18 16:56:33 UTC 2010

I've just been looking at Bug 338549 
<> again. This is the 
bug where on startup our password prompts are no serial, and the results 
are  parallel prompts that can interfere with each other.

We currently have two possible solutions, however as far as I can tell 
at this stage (as suggested by David Bienvenu in the bug) they will both 
have one potentially confusing issue. Best explained with an example:

    * Connection for server 'a' starts and requests a password - prompt
      displayed to user
    * Connection for server 'b' starts - prompt would be queued
    * User enters incorrect password for server 'a'
    * Connection for server 'a' goes away and tries the password
    * User prompted for password for server 'b'
    * User then gets password prompt for server 'a' again.

Given that the current implementation can mean focus loss etc, requiring 
extra clicks, I think this may be an acceptable improvement for 3.1 
which we can build on again later.

To fix the remaining issue explained above I think we'd have to provide 
some wider mutexes/locks in the various protocols which would ensure 
that whilst the authentication period was in progress for one 
connection, another connection couldn't start. This would be a more 
complex solution that I don't think we could get in for 3.1.

So in summary, I think we can make the prompts "serial" and in the cases 
of bad password and multiple accounts, we might get some slightly 
unexpected results, but I think that is a far better result than the 
non-serial prompts that steal focus that we have now.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list