Opened 10 years ago

Last modified 6 years ago

#9372 new defect

XMPP (with Google) tries to connect before password is entered

Reported by: BladeOfLight16 Owned by: deryni
Milestone: Component: XMPP
Version: 2.5.8 Keywords: XMPP password
Cc: briand

Description (last modified by BladeOfLight16)

Since my Google Talk account is connected with my e-mail, I don't have the password saved. I've noticed that if I wait to enter the password, though, I get an error meassage in the Buddy List. It says

[my e-mail address]/Home disconnected
Read Error

Of course it can't connect. I haven't entered my password; the window for entering it is still on the screen waiting for input. Shouldn't the client delay trying to connect until I enter my password?

Also, if I type in the password after getting the message and hit Okay, it doesn't connect. Instead, it asks for my password again either when I hit Reconnect in the error message or wait for it to try to auto-reconnect.

I don't have any trouble connecting if I enter the password quickly enough.

This doesn't happen in any other client that I'm aware of, though I can't be certain. I only use XMPP (Google Talk), AIM, and MSN, and AIM is the only other one I don't have the password saved on.

Addition: I've just tested and this problem still exists in 2.5.8.

Attachments (1)

Google_Failed_Connect_Edited.log (5.1 KB) - added by BladeOfLight16 10 years ago.
Debug Log for Google Talk's Attempt to Connect Before Password Being Entered

Download all attachments as: .zip

Change History (14)

comment:1 Changed 10 years ago by BladeOfLight16

  • Description modified (diff)

comment:2 Changed 10 years ago by BladeOfLight16

  • Description modified (diff)

comment:3 Changed 10 years ago by BladeOfLight16

  • Description modified (diff)
  • Version changed from 2.5.6 to 2.5.8

comment:4 Changed 10 years ago by darkrain42

  • Status changed from new to pending

Please follow the instructions to get a debug log and attach it to this ticket.
Please get a debug log with not entering the password (and getting the 'Read error')

Changed 10 years ago by BladeOfLight16

Debug Log for Google Talk's Attempt to Connect Before Password Being Entered

comment:5 Changed 10 years ago by BladeOfLight16

  • Status changed from pending to new

Attachment (Google_Failed_Connect_Edited.log) added by ticket reporter.

comment:7 Changed 10 years ago by BladeOfLight16

I've attached the debug log. I hope it's not problematic, but I replaced my Windows username with "[Windows Username]" and my Google e-mail with "[Gmail Address]" to avoid sharing them.

comment:8 Changed 10 years ago by deryni

XMPP servers, in an attempt to not let people tie up resources for ever, disconnect clients that hang too long during the initial connection steps. That is almost certainly what you are seeing here, the Google Talk server essentially saying "I'm tired of waiting for this person to get on with things, they can just connect again later if they want. Bye!".

comment:9 Changed 10 years ago by BladeOfLight16

If that's the case, then why doesn't Pidgin delay establishing the connection in the first place until it has a password? I would've thought that'd be Pidgin's behavior for any protocol that uses a password. Granted, this is a minor inconvenience, but I can't think of any reason why Pidgin would need to establish the connection prior to having a password.

If there is a good reason for that, then perhaps Pidgin should at least hide the password entering dialog when the error message appears. This would force the user to either click Reconnect or wait for an auto-reconnect. (In other words, the connection would get established). Then entering the password would result in a successful log in, rather than a failed log in and a second prompt for the password.

comment:10 Changed 10 years ago by deryni

Because pidgin can't know that it needs a password until you try to connect. There are a number of ways pidgin could connect that don't need passwords. Anonymous authentication, token authentication, etc.

Agreed, we should either dismiss the password dialog at that point (which would be incredibly confusing I thnk) or better notice that the connection attempt is gone and try again with the entered password.

comment:11 Changed 10 years ago by BladeOfLight16

Also agreed. After I sent that, I imagined a user wondering where the password dialog had gone, and after reading your comment, I realized it might vanish in the middle of the user's typing. Detecting that the connection has broken and establishing a new one does seem like a much better approach.

comment:12 Changed 10 years ago by darkrain42

Ticket #6765 has been marked as a duplicate of this ticket.

comment:13 Changed 8 years ago by darkrain42

Ticket #14587 has been marked as a duplicate of this ticket.

comment:14 Changed 6 years ago by bwo

This problem still exists in 2.10.7.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!